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 do the same thing just smaller. Like this:

See where this is going?

I encountered several contexts in which a company, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what is 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 in 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 now. Doing a mini-waterfall isn’t necessarily a bad idea.
On the Pro side, we can say the following:

  1. Mini-Waterfalls are 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 kinds 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 are some kind of an iterative cycle so you will get more feedback.
  2. Working in short iterations has been just different than working in long cycles.
  3. If you don’t do the needed mind shift, working with 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.  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 process. 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 discussions 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 you are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and it’s 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 from them. Each and every pain is a place in which something new can be learned, 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 affect your 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) requires a new way of thinking to make it work. Most likely old solutions won’t solve these new problems.

Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email