When looking at the cumulative amount of time invested in agile planning, you may be surprised to find out there’s a lot more used than a waterfall project. How many times have you made a purchase only to find out that you could have spared some funds if you would have taken a few more minutes or hours of research to get the best deal. If only you would have taken some time to plan in advance. Sure you can just return it for that 30-day money back guarantee, but why waste the time and effort after the fact? The reason here, is lack of planning. Like all things we are interested in, we tend to reduce the amount of time between something that we want so that our brains can register that point of fulfillment. But what if you really got what you wanted and without remorse? Wouldn’t your fulfillment be much greater? The answer is YES. Instant gratification is not always the best route especially if it means that you will have issues to resolve right after.
How is it that projects get into trouble toward the end and not at the beginning? The answer might raise memories of regular finger-pointing that took place in more than one of many likely scenarios. Anywhere from blaming the customer, vendor, unforeseen events, or employee incompetency. This creates an awkward situation and all egos get the best of everyone, so that eventually it becomes a race to prove who is the least guilty in the whole process. If you’ve reached that point, it’s already too late to fix the problem, and the situation is probably already highly toxic.
Understanding Risk and Uncertainty
In order to undo our regular mind programming to get to the end of a project to guess if it was set for success, we need to implement processes that give us the best use of our time and will give long-lasting motivation, satisfaction and gratification. In a typical project management life cycle, we might think of uncertainty as a steady plateau of risks and issues, but in fact risk is highly concentrated at the beginning and much less at the end of the timeline. Visually, this is represented by the cone of uncertainty.
The representation of the cone indicates that you know significantly more as time goes by. But what does this mean for everyone on a project? Toward your client, you need to be sure no promises are made, especially not at the very beginning. For your client, it means that they are risking time and budget without knowing what product they are getting until the near end of the project.
One-time Planning vs Iterative Planning
Now imagine this is a one year project, and everyone suspects they are up for some big surprises at the end. Now we figure, “let’s plan everything at the beginning and everything will be fine.” To be honest, most projects aren’t even that fortunate. It would be a step in the right direction. But what if changes occur throughout our project, as almost all do? We figure, sure let’s create that “change request” and do it. That’s alright, but what happens to the rest of what we planned? We still have to do it, and therefore our efforts get crunched if we try to keep the same timeline.
In the agile project methodology we have events such as release planning and sprint planning, so we’ve already taken care of change as part of the process. As part of the iterative process the agile team is able to adjust as they go along. While we are building-in the planning at the beginning of each sprint (agile games such as planning poker included), we know more and more as we go along and as a result we are allowing ourselves to take on the benefit of progressive elaboration. What this means over time is that as we know more and more about everything in the project (literally), we can plan accordingly so that as we get to the end, the product we set out to develop is as close as possible to what is expected.
In the end, there’s a lot more planning in agile that both you and your client must do (if comparing waterfall vs agile), but it is a lot more of what you want, and a lot less time-wasting will result. It can be seen as a good investment since you will have more time at the end of your project giving and receiving praise. You will have also avoided all that time trying to justify to your customer why certain features that were identified at the very beginning of the project, were not included. Certainly there are other factors to make the end-result a success, such as considerable backlog management and necessary stakeholder involvement, but this is just a part of what you can expect.
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
