Hole in one at 1000 yards
Hole in one at 1000 yards
Even Tiger Woods cannot make such a shot at 1000 yards. Yet many software companies still try to deliver software under the delusion that this is possible. There are many software companies busy making waterfall project plans that promise the impossible: delivering a complicated software project with astonishing detail one year from now. These plans are just as delusional as trying to hit a hole in one at a distance of 1000 yards. Just because it looks good on paper, does not mean it will stop reality from eventually kicking in.
Why Most Software Projects Fail
Waterfall projects closely resemble the traditional mindset of corporate organisations. Each phase of a waterfall project is a silo that is sealed off from the other phases. This approach leaves little room for error or adjustments afterwards.
You first describe what you want in excruciating detail. You get it signed off and then you hand it over to the engineering team. The engineers obsess over how to build it and only start coding once the complete plan is distilled. Testers only start testing when all coding has been completed, and so on. Everything comes together at the end. You only know whether you you nailed it when time is up.
Handling Uncertainty In Software Development
When you realise you do not know exactly what you want or how to build, it is better to acknowledge this in your development approach. When you do not know what to build, the end uncertainty is high. When you do not know how to build it, the means uncertainty is high. At a start of a project generally both means and end uncertainty are high.
In waterfall you first focus on reducing end uncertainty, and afterwards on reducing means uncertainty. When you do Scrum you reduce both simultaneously. Each sprint you figure out what to do and how you best can realise this. This approach ensures that uncertainty is reduced more gradually and spread out over time.
Scrum is more like playing mini-golf. Instead of going for one big stroke, you split it up in little strokes. Each stroke is called a sprint. Each sprint has their own goal. After each stroke you evaluate if you are going in the right direction and you adjust if necessary. You do not put all your eggs in one basket and bet on a single strike.
There are very specific conditions where doing a waterfall project makes sense: you know exactly what you want and how to build it. Otherwise as each phase progresses you may stray away further from the end goal. You will only realise this at the end of the project, just like when the ball stops rolling after the first strike. Only in this case it will be game over.
Conclusion
Waterfall is great when you need to build simple things. Then you can describe what you want perfectly and building it will be trouble-free. The moment things start getting more complicated, it is better to pick a development approach that handles uncertainty better. After all, you do not want to find out at the end that the path you took was completely wrong.