Is Agile Planning an Oxymoron?

agile-planning-oxymoron-1

Planning has a long history, but in the context of software, the biggest fillip that planning received was the advent of the waterfall method. The waterfall method formalized and simplified development for the fast growing software industry by defining 4-5 clear cut phases, and planning signaled a validation for the resource and cost management in each phase. Each phase had a clear beginning and an end, you began each phase when the previous was completed. Over time there were many variations added to this core technique, but without any fundamental redress to the problems inherent in the method.

Then advent of off-shore software development continued to maintain this marriage of bean counters and resource managers under the guise of controlled software delivery. The controls honed in on precisely those that would interest the client, viz. resource usage and cost. This was an exact fit for the off shore service industries needs, it provided for an easy and supposedly transparent way of measuring resource numbers, cost, with the aid of Gantt Chart, critical path, and what not.

The history of major software cost overruns followed by some spectacular failures stands as testimony against this marriage. In some cases there have been other contributory factors to the failures, but the major cause was this (unholy!) marriage. Two factors that stood were, the big bang approach, and the inability in managing change.

Big bang release and change management are precisely the two areas where Agile shines. It does so via the notion of MVP (Minimal Viable Product), controlled iterations, and small teams. Agile development assumes that there is never a complete stack of requirements ready-prepared to begin with. Agile uses the iterations to refine the product with the help of the feedback loop and the MVP constructs.

This is also ensured by fine tuning the duration of the iteration. This tuning is also dictated by the complexity of the domain (problem space), and that of the technology. This is particularly true when the choice is a bleeding edge technology. The iteration period also dictates how quickly you fail and correct. 

None of these pros and cons negate the need for planning. The question is, in the context of Agile software development, where does planning add value to the outcome.

  1. If you are working with a legacy project, either to extend or add a new feature, than it seems most sensible to use project plan. The simple reason is that you will have (or should have) much (if not all) of the information at hand to evaluate the resource and other requirements. In other words you must by now have buckets full of feedback about your product from your clients.
  2. This is contrary to the situation of a new product venture. Being in the dark is the norm, not an exception. The feature sets (and other requirements) are refined over the iterations and MVP release to the clients. Planning in this type of venture is performed at a high level by the product owner and or product manager. As the number of agile teams increases the project plan will have a greater pull for cost management. But, the teams themselves should be immune to this, they should be focused on their iteration, discuss, decide, and act on delivering the code, with the MVP goal in focus.
  3. Imagine telling a team of soldiers embarking on a mission, that under all circumstances they must only use the training and intelligence provided prior to the mission. This besides being idiotic is suicidal. No matter how thorough the training and intelligence, once on the mission the soldiers decision will be coloured by what they encounter in the field. Their actions will be dictated by their observations and constraints that are present at that instant. Their survival and the success of their mission is dependent on how well they adapt. They will execute the mission plan, but with a readiness to alter (the route to the goal) based on the local situation.

Conclusion

To paraphrase, please do plan, and when the execution starts throw away the plan. Once an iteration begins, the teams should be focused on delivering the code, they should not be diverted by project planning type tasks. This is the responsibility of the Product Owner/Manager, and perhaps the scrum master. The teams select the the feature tickets prioritized by the Product Owner/Manager according to the consensus of the MVP releases. Their goal for each iteration is to complete the selected tasks, and be mindful of the next iteration and the MVP.

Some wag once suggested that the agile way of working was akin to small waterfalls within the constraints of a large waterfall. Perhaps it was only meant to be a humorous off the cuff remark. Agile waters are muddied enough without any help to further muddy its meaning and purpose. One could also replace the term ‘waterfall’ with the term ‘plan’ or ‘hierarchy’ without any loss of humour.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in agile methodologies, Planned Design, team building. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s