Difference between an agile workflow and a mini waterfall

Posted on Jun 29, 2019

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.

Consulting, coaching and interim management

Looking for an interim CTO to steer your software business to the next level? Or would you like to expand your team's knowhow with coaching or background research? I provide remote consulting to global software companies from US East Coast, UK, Central Europe and Nordics.

I’m an experienced entrepreneur and investor with a rapidly growing track record in SaaS, blockchains and decentralized applications. With over 20 years of work experience in software business I help companies to build better technology strategies, accelerate innovative development and drive product-led growth. My passion is to steer tech enterprises to create new innovations that are changing the way we work and live.

I write about software startups, Web3 and blockchain concepts. Join to receive these blog posts and occasional announcements via email: