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.
If you have ever tried to solve a complex problem, you probably discovered the benefits of working with someone else – whether that person had more experience than you or could just ask questions that challenged your thinking. Compare that to a time when you were handed a checklist and just ticked things off – which produced the better solution?
Let’s start with the basics: what is Agile?
It’s an umbrella term, coined in February 2001 when the Agile Manifesto was created. The manifesto starts by saying: We are uncovering better ways of developing software by doing it and helping others do it. It’s important to understand that it says uncovering – it doesn’t claim to be the definitive How To for software development. Sixteen years later, I think it’s safe to say we are still uncovering better ways.