Creating a Mini-Waterfall

Some people refer to sprints as mini-waterfalls. Well that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
well its not very hard like anything else when you create a mini-X you start by taking the X for example:


and then you make the same thing just smaller. like this:

see where this is going?

I encountered several contexts in which a companies, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit inside short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well actually by itself no. Doing a mini-waterfall isn’t necessarily a bad idea.
on the Pros side we can say the following:

1. Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
3. To support working in small batches you will need to get used to cut and slice the work into small things.
4. and when you work in smaller batches, all kind of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side we should probably say that:

1. Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
2. Working in short iterations is just different than working in long cycles.
3. If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
4. And if it gets hard enough , most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations things that were comfortably hidden become  visible and painful.  and the natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile processes. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussion with people that experienced exactly that. (BTW trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well I don’t know. However, I’m not sure that’s even an interesting question. Personally I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First realize that by understanding the problem your are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and its really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn rom them.  Each and every pain is a place in which something new can be learnt, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they effect you team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes even a mini waterfall) require a new way of thinking to make it work. Most likely old solutions wont solve these new problems.

Read more »

Posted in: Agile Management