Difference between an agile workflow and a mini waterfall
Posted on Jun 29, 2018
Agile team leading is full of small but nasty pitfalls. One of them is a mini waterfall: A process that creates high dependencies to development and is difficult to execute within an agile sprint. We of course need software development processes on top of agile frameworks to manage the production. But this also takes us to situations where the team easily refines an agile development workflow into something much more difficult to manage.
An agile workflow consists of steps that need to be completed before a story or item is fully done. Often it starts already on product backlog, where item might be for example in “Draft", “Scoping" or “Ready" state. During sprint the workflow tightens and items are pushed from “Ready / To-Do" to “In Progress" and “Review", until it’s finally “Done".
The further we refine an agile workflow with developers, more requirements it faces. This typically creates more steps around the fairly simple workflow - by adding elements such as “Deployment" or “Merging". But what shouldn’t happen is that “In Progress" should never be split into “Design", “Development" or other similar phases.
Developing a story should always be a collaborative effort. One story might require more than one task on a sprint, but developers should rather work together in parallel than in a sequence. If sequences with dependencies are really needed, it means that your team is not cross-functional and it should be perhaps rebuilt with different skills. It’s always good to have at least one or two full-stack developers whom can tackle these multilayer features.
Another way to create a mini-waterfall is in sequences of stories or tasks. When story content is split so that in the first activity developers initiate the design and in second activity developers focus on development, that already isolates designers and developers into two different groups. Instead, there should be a small story with design and development execute parallel during the first iteration, and then another story with some more design and development adding details to the outcome of the first iteration.
The problem with the mini waterfall is that It makes your teamwork vulnerable to delays, bugs or absences. A good way to identify if you have a mini waterfalls existing in your agile teamwork is to follow the development outcomes: Does every iteration bring you a fully functioning piece of software from the features that team decided to build - or are some of those features half-done and waiting for the second iteration? The latter should be avoided whenever possible.