The other day, one of the project managers posed an interesting question: If we plan well in ahead, are we still agile? And the subsequent reasoning was: In Agile, we don’t need to plan in the real sense.
I resolved his doubts and also thought of sharing the wisdom with the world.
First of all, when we talk of Agile, people have a general misconception that one has the freedom to be so flexible as to really not care about planning. Agile does not mean that we avoid planning completely, it means we have minimum and sufficient level of planning in place and are flexible enough to adapt to the changes.
Now, the key issue is how we define the minimum and especially sufficient level of planning. There is no specific set of rules or any magic formula that you can just apply and have the plan ready. It normally comes through experience. But then, there are cases when the program manager can get too minimalistic in his planning and forget to look at the big picture or the overall release goals. He may be too centric towards each sprint. And the result is that it may lead to myopic vision of the project and release. This can in turn lead to many issues arising at the fag end of the release.
The other case is when the program manager goes overboard. He sets up not only the complete release goals and sprint plans, but also meticulously plans out when the Epics need to be frozen, when the features need to be scoped out clearly, what is developed in each sprint across the various projects going on in parallel for the release.
Again, here too, I really don’t see a problem in the above set-up and approach unless the dates are hard coded and there is no scope for adapting to change in the program. If there is no scope for changes and realignment, it is as good as a waterfall model set in one of the previous decades.
A good balance can be obtained when the overall release plan is set to help guide the project managers well in advance on the approach of the release. The scope is allowed to be changed in between sprints when there are changes in scope observed by the higher executives that are crucial for the project success. The Epics defined at the high level have room for deciding what goes as minimum shipment and what goes as stretch goals, and most importantly how much of the scope suffices to make the release deliverables valid and successful.
Finally, it’s not about planning alone; it’s more to do with adapting to changes. Fundamentally, we should also remember the adage – Failing to plan is planning to fail, unless the very plan becomes suffocating and goes against the very purpose of delivering a successful group of projects in the real sense.
This is a very common question in almost all the team members. Thanks for sharing the wisdom. The content is well written and organized. PMBOK also has answer to this in terms of 'rolling wave planning'. Plan the near future (current sprint) to a greater detail and later future (product backlog) to a lesser detail so that team can respond to change effectively. This enables to maintain the bigger picture as well as required details.ThanksSrinivas
Well said Srinivasa. Thanks for your comments