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:
- Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
- When you work in a short time boxed iterations you will be forced to work in smaller batches.
- To support working in small batches you will need to get used to cut and slice the work into small things.
- 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…
However, On the Cons side we should probably say that:
- Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
- Working in short iterations is just different than working in long cycles.
- If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
- And if it gets hard enough , most likely you will stop doing it.