A few people (aside from those I work with) have contacted me recently asking “where do I start?” or “is there an Agile 101?”
The first thing to note is that it’s not as simple as watching a video, reading a book, or attending a course. Yes, those can be useful introductions, but the most important thing to understand about Agile is that it isn’t a series of checklists or processes to follow – it isn’t a silver bullet to solve your organisation’s problems. In fact, some people dislike/distrust Agile because it can shine a light on problems that they’ve happily swept under the carpet for many years; transparency and honesty are not things every organisation values because it can be a threat to the status quo.
Overview: coaching multiple development teams and product management.
Life would be so much simpler if our customer would just tell us exactly what they want the product to do. I wonder why they don’t just write it all down, then we can go off and build it?
In my experience, the customer can’t do this because they don’t know exactly what they want. They have a feel for what they would like, but they don’t always know what is technically feasible given the time & budget constraints. There’s almost always a trade-off between what they would like and what they can afford; maybe Feature A could be a little more robust if a couple of bells and whistles are dropped from Feature B, for example.
Somehow this myth persists: Agile means we no longer have to produce any documentation, right? Sorry to disappoint you, but that’s just not true.
If we revisit the Agile Manifesto and read it carefully, what it says is “we have come to value working software over comprehensive documentation“. It says there is more value in working software, but it does not say that there is no value in documentation – there is some value in documentation, and more importantly there is value in the right documentation.