Why an Iteration is Not A Mini Waterfall
When I am working with Project Managers who are in the throws of trying to learn Agile, there are certain discussions (debates), which can indicate that the person is going to have more of a struggle with making the change. These are usually the PMs who quickly grasp the flow of the process, but immediately begin second-guessing the system, and all of this usually happens without the PM even realizing it. After all, if you have been around a bit, and you are a halfway decent PM, you look at everything that enters your path as a potential threat to your project and start working out how you are going to get around it. This is what we are taught to do – find a workaround.
I think the bigger issue though, usually stems from the fact that the PM often does not recognize how their own expertise can be the obstacle. One of the ways this often manifests itself is through a question or declarative statement/argument about how the PMBOK is clearly, already Agile and these iterations or sprints we are talking about are nothing more than mini-waterfall projects.
Just in case any of the mini-waterfall people happen upon this… I mean you mo harm. I spent about 8 years inside that argument. Please bear with me a few minutes and this will make more sense.
I have learned my lesson about trying to engage in an argument against the perception that a sprint (or iteration) is just a mini-waterfall. I don’t agree with it, but it is perception, and my experience has been that getting pulled into this one kind of like trying to debate whether Sammy Hagar was a better front man than David Lee Roth.
To me, the real issue comes down to something completely outside the steps of the process itself. A traditional PM can make all the arguments they need to in order to maintain their death grip on the belief that everything in the world can be broken down into a traditional (waterfall) project. But, no matter how much Kool-Aid they’ve consumed, there is one thing which cannot be avoided, and which they cannot deny…
A waterfall project schedule is nothing more than a guess.
"…But little Mouse, you are not alone,
In proving foresight may be vain:
The best laid schemes of mice and men
Go often askew,
And leave us nothing but grief and pain,
For promised joy!"
(from "To A Mouse" by Robert Burns)
Yes, it is an educated guess and yes, there is usually math involved and we all know that if there is math, it must be true. Math aside, a traditional project schedule is just a guess based on what we think we know will happen, made at a point where we think we know enough to predict the future. (And I think we all know how good we project managers) are at predicting the future.
So, in managing a project, a significant part of the PMs gig is to come up with this educated guess and then do his/her very best to make sure to bend the very fabric of reality to match the guess. The idea is to manage to the plan.
In Agile, we focus more on the team and what we can do in order to better support and enable them, because it goes (Theory Y Alert!) that if you’ve got a bunch of smart, motivated people, you give them what they need, a clear objective and the power to make smart decisions, that the rest will take care of itself. (Remember – it says Theory Y above, not Theory X).
So, regardless of the steps in the process, the whole value system is completely different. A PM who is looking at the world through a waterfall will see the steps in the process as the thing that exists to make sure everyone stays on schedule as planned. An Agile PM is one who looks at the process as something their to support the team’s ability to perform. At the end of the day, both sides need to get stuff done, but a traditional PM uses the schedule to do this, an Agile PM enables the team to do this.
To me, if a PM is locked into the vice-grip of trying to prove that Agile is something that is already covered in the PMBOK, working their way out of that Gordian knot is usually something they will have to work through on their own, but if they can see the variance in the structure of the value system, and how that vantage point impacts their actions on the project, it is definitely a step in the right direction.
(And yeah, I’m willing to throw down for Hagar any time, anywhere.)
