Agile has been around for decades now but really started to gather pace after the release of the Agile manifesto in 2001. Many companies have been using it for years now.
But looking ahead, is what is there beyond Agile? Agile does some wonderful things for the organisation:
1. Real prioritisation.
When you ask the customer what they want, they will say everything. Waterfall would then estimate to deliver everything. Agile doesn’t say you can’t have everything, but asks what we should start to work on first. What really is your top priority?
This gets around a key problem of the customer-delivery team game. The customer thinks that by not saying “everything is a top priority” the delivery team will use it as an excuse to under-deliver. Now they are just being asked to ask what they want the dev team to work on NOW. Likewise, the dev team is committed to delivering that small chunk.
2. Limited room for excuses.
Agile provides much better information early. This moves the delivery team away from having a “shock” that they are already 6 months into a project and suddenly something crops up that has the potential to cause a 2-month delay (for example a first round of testing reveals 40 critical defects that then need to be fixed and retested).
Of course in Agile you will get delays, but they are known about earlier and therefore the resultant damage is less. If the customer has 4 months to re-plan a launch that is far more acceptable than 4 days.
Information availability is never perfect. More information comes to light that change what people want and what priorities are. Waterfall projects often try to deal with this with “Change Request” processes which come with a management overhead. Agile simply accepts that change is inevitable.
One of the problems in looking beyond Agile though is that, in theory, most models work well. It just comes down to whether they do in practice. In theory, Waterfall with a great design, great implementation and great testing should all work brilliantly.
One type of ‘Agile’ implementation, SCRUM, should work perfectly, but often doesn’t. This can often be put down to the fact that it is misunderstood (largely) because it is not presented in terms that those who favour traditional models understand. So it is difficult for them to adjust. Agile is ‘principles and values’, not ‘processes’. I’m not saying one is necessarily better but when you try to implement one by trying to convert it into the other, there will be loss, and that’s what happens. Many firms think they are Agile because they have adopted some transformational process, but they are not.
Conversely though, the same could be said about Waterfall – maybe a project failed because the designer failed to write the perfect spec? Why didn’t this fool write the perfect spec!? If he had, everything would have been great.
The argument starts to become what way of working is most likely to work in the real world? It could be said that Agile puts the failure points into the people – are they performing as per the teams values and principles? And conversely that Waterfall puts the failure points into the process – how likely is it that the people are likely to execute the process to the letter?
Process failure, in my experience is much more common, but what is better may come down to the team you have.
The reason Agile is such a step forward is that it is not a tweak to process it is a paradigm shift to focus on people. But what is the next big thing? Where could the focus shift to? One answer would be “Product”. Perhaps there is a development methodology focusing predominantly on the product which would fit more contexts than either Agile or Waterfall. Time will tell.