This is not one of those waterfall v agile posts. This is about debunking the mythology given to each. I’ve used both extensively and find more similarities than differences, and many things said are just not what I have experienced.
Waterfall
- Myths
- Only have one sequence throughout the entire project
- Customer cannot give feedback until the end of the project
- Changes cannot be included until the end
- Facts
- You can have several sequences overlapping at the same time
- Customer can provide feedback anytime
- Changes can be included anytime
I never once worked on a waterfall project with one sequence. I have worked on a waterfall project 30 months long with sequences 2 weeks long. Sequences overlapped so when sequence 1 was in implementation stage, sequence 2 was already being designed. The customer gave feedback at the end of each sequence and this was fed back into the project. Each sequence was iterative until complete.
Waterfall has a history in manufacturing/construction when things were be built in sequential order – basement, floors, then roof. This is probably where the myth comes from. When software came along a strict sequential order was no longer required. We divided into more than one component and joined digital products later. Manufacturing/construction also followed where many components are prefabricated long distance from where they are joined to together. Today a roof may be built in a factory before the foundations even laid.
Agile
- Myths
- Must use one of the recognized processes such as Scrum and Kanban
- Iterations must be of constant length
- You cannot change the contents of an iteration once it is in action
- Facts
- Adherence to the agile manifesto and principles and you can add your own simple process to be agile.
- Use a guide such as 2 weeks for iterations
- one of the promoted benefits of agile is that you encourage change at any time
The agile manifesto states individuals and interactions over processes and tools – but many of these processes are commercialized versions of agile putting their processes and tools over individuals and interactions – that is how they make money. I have worked on many agile products where we kept the process simple just using the manifesto and principles. You only need as simple process as you need. We should own the process not the process own us.
For consistency many argue that all iterations are of the same length but I only ever had a guide for iteration length. I would add as many user stories to that iteration without exceeding its length. If that makes the iteration useful then fine, else add more user-stories until it is useful and make that the length of the iteration. If iterations are constant then this requires the overhead of writing mocks and stubs, and feature switches to spread features over iterations. The alternative is to change the contents of an iteration. I always had the teams constantly monitoring progress so they could bring forward highest priority user stories into the current iteration, or push back the lowest priority user stories depending whether time was slack or tight.
Conclusion
Agile and waterfall are two different cultures that clash in software development by those looking for differences. When you focus on similarities not differences they are much closer to each other than you think.
Photo by Vera Arsic from Pexels
