';

Who says there's no planning in Agile?

Is Agile a planning-free approach?

The introduction of Agile as a software product development approach is having a significant and positive impact upon the way IT projects are delivered. However, in our coaching interventions, we are finding some confusion among project managers. Some experienced project managers quickly learn how to adapt and integrate Agile practices into their toolset. It is just another approach, which used appropriately in the right projects increases their ability to deliver. Others move straight to denial; change-weary, they avoid or downplay the usefulness of the Agile framework– “It’s nothing new.” That is their loss! Of greater concern are the more junior project managers who, faced with Agilists, lose their bearings. “What is my role in this?” “How does the governance work?” “How do I plan?” And most worrying – “Do I need a plan?”.

We recently attended an Agile coaching session. Here, one of the coaches consistently contrasted Agile techniques against ‘plan-based’ techniques. This begs the question, “Do projects run under the Agile framework not need plans or planning?” According to Mike Cohn in his excellent book on Agile planning, while plans may be out-of-date by the time we commit them to paper, the process of planning is essential.

“Estimating and planning are critical to the success of any software development project of any size or consequence. Plans guide our investment decisions…Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect. Without plans, we open our projects to any number of problems.”

Planning in Agile projects

Today if you ask a project manager what the most important skill they require for their job is, they are likely to refer to several areas. This may be stakeholder management, communications, leadership, or behavioural competencies. Is this because it is assumed that planning is important and does not need to be mentioned? Or is it that project managers believe that with the right leadership style, communications and engagement they don’t need planning? Do approaches such as Agile, which expound people over process deliberately or inadvertently, promote this view of the obsolescence of planning?

Cohn describes planning in Agile projects as:

“Planning is an attempt to find an optimal solution to the overall product development question: What should we build? To answer this question, the team considers features, resources, and schedule. The question cannot be answered all at once.”

That “The question cannot be answered all at once.” is new and different. It’s not what a traditional project manager planner would think to say. What has Agile lighted on that makes this sensible? Many projects, and particularly software development projects have been plagued over the years by poor requirements. A particular strength of Agile, where its delivery is at its best, and traditional project management disciplines are distinctly less successful, is its use of techniques that allow requirements to emerge, and resources are then organised to find solutions.

This leads to some interesting insights from a planning point of view. In Agile approaches, change is not regarded as a failure. Rather it is a signal that a new approach needs to be taken if the desired result is to be achieved. To interpret this propensity and ready acceptance for change as an excuse not to plan is to misunderstand planning. Planning is about the management and containment of uncertainty, so it matters in Agile projects too. They also have to give answers to questions like “What will be tackled first?” and “Can we release the test rig in April?”

Any plan is only one forecasted view of the future. There are others, and with the passage of time, they may be more relevant. (Cohn, 2005)

That a plan is only a snapshot – valid at a point in time – has to be factored into the way planning is done, and plans are communicated. There are, necessarily, governance differences between Agile and more traditionally conducted projects. For a start, Agile planning activity is spread across the life of the project, rather than primarily focused at the front end. That leads to the need for planning documents to be easy to amend. That means structuring your plans to make the more volatile parts easier to change.

Planning should anticipate change, with change viewed as the positive consequence of having learned something and avoiding the mistake of doing something that is not wanted. As changes are discovered, plans are updated. In much the same way as innovation and other exploratory projects, the planning is carried out, not in one go, but tranche by tranche, as positions clarify and options become available.

So does planning matter in Agile? We argue, very much so. What is different is that how you go about planning and what is an acceptable output from planning, varies. What’s your view?

References

Cohn, M. (2005) Agile estimating and planning. Pearson Education.

logo