Whenever we start a course, no matter how expert the people in the group are, or whenever we engage with a new client in consulting, we like to pose the following question: Why do we do this Agile ‘thing’?.
So, indeed, why do we do Agile? Let's have a closer look.
Traditional methods - Waterfall
Our traditional way of working (synonyms: waterfall, the defined process) has some inherent problems. It cannot cope with change or uncertainty, and it limits innovation.
Let’s think about how the traditional process works.
We start off by defining all the requirements. We give our customers one single opportunity to define all their requirements. Their reaction will be to spend as long as they can on defining all the possible things they could ever need.
Great. So we have defined everything that the customer could possibly imagine they might require. The output of this is a Detailed Requirements Specification, a document, which sometimes is hundreds of pages long. We get the customer to sign off that this is everything they want, and they can never change this, without being inflicted by the dreaded ‘Change Control’.
This tome of a Detailed Requirements Specification is then passed to the Analysis team. The analysis team doesn’t always have much context about the requirements. Instead, the information it has to hand is the DRS. So the team spends a long time analysing the DRS, and producing some large and lengthy Analysis Document. If the customer is really lucky, they will be forced to sign this off. They might not understand it, but it is important that we lock them down and threaten them with ‘Change Control’ again.
The same process might happen again between the Analysis and the Design, yet another document will have been created.
We all well know that documentation is not a very good communication method. It seems though that it is our preferred way to pass information around.
At the next stage, the document gets passed over to the Developers. By now, the customers requirements might be 3rd or 4th hand and have made a number of deviations in these documents, being several months in the making.
The developers will do their best, with the information given to them, and pass it on to the test team. The test team will use the same documents the developers had as input, but they might read them in a different way, and run tests with their understanding.
Never the twain shall meet, Developers will have one understanding of the requirements, and Testers another. Some toing and froing and, eventually (often very late), we will have something to show to the customer.
What we show to the customer is not fully tested. The next thing you know, testing is squeezed in, and presenting the product to the customer doesn't go as expected.
So, what next? How do you go around this, and how can you avoid presenting to the customer something that doesn't meet their expectations?
Download the 'Why Agile' white paper to find out more.