I recently heard someone at my firm lodge the following complaint about Agile: ‘The trouble with developing software with Agile is that it tends to be very reactive as we build to satisfy the most recent requests; instead we need a more proactive and long-term approach to thinking about our software development priorities.’  To offer some context for this comment, this person has a much deeper familiarity with our company culture (which has often been reactive) than with either software development in general or the Agile approach in particular.  But even people who know more about creating software often have the misconception that Agile is anti-planning.  While the Agile Manifesto values responsiveness to new information more highly than holding fast to a predetermined plan, from my own experience Agile works best in the context of well-articulated plans that look at both short-term and long-term priorities.

As I plunge into this set of blog posts on Agile planning, it’s important to start with the picture that many Agile developers use to describe the different levels of planning employed in this approach.  You can find many discussions of this on the web, where it is alternately referred to as the planning onion or the planning flame.  You can check out one discussion here (http://bit.ly/1dUxGTo) and if you want a longer discussion and some interesting background music you can check out this presentation here (http://bit.ly/1m9gaiR).  The picture below comes from the following link that provides only a basic overview of each stage (http://bit.ly/1j9vm2q).

The idea of the Agile planning onion (or planning flame) is that planning actually involves multiple inter-related levels that go from the widest perspective to the most focused.  Corporate-level strategy informs the entire context for software development and provides a 3-5 year time horizon on the overall direction a company intends to follow.  Beneath that broader corporate strategy is a plan for a more targeted portfolio of products and services designed to reach a particular market or market segment; planning at this level extends 2-4 years as a company determines how it intends to reach and serve a set of customers.  These outer two layers of the planning onion set the general themes and broader context for the more detailed planning that comes below.

Within that broader vision there is a 12-24 month product plan that generally encompasses a product roadmap of key feature areas to be built or enhanced; this level of planning begins to become more specific and helps to inform plans for the product team to recruit and train the right set of people to design, develop, and deliver the product.  Product planning is also a key area of focus for the Product Manager who collaborates with other product managers in setting portfolio plans.  The Product Owner and the development team more broadly get more deeply involved at the level of release planning, where along with the Product Manager decisions are made about what features or feature sets will constitute a given release; this level of planning often encompasses one to two quarters.  At these middle two layers of the planning onion the broader corporate strategy takes more definite shape in reference to specific products and product features.

More granular planning happens at the iteration or the individual sprint level, where the work to be accomplished in a given 1-4 week time period is prioritized, estimated, and planned.  Finally, the deepest level of Agile planning focuses on a single day, where the team meets for a daily scrum (or comparable brief touch point) to reflect on the previous day’s work, the plans for the given day, and any obstacles the team faces in achieving its daily goals.  These inner-most layers of planning are where the strengths of the Agile approach most fully come to bear, as the team responds dynamically to both the direction from the outer layers and the complexities encountered in their development efforts. (Can’t resist putting in this bit about onions and layers: http://www.youtube.com/watch?v=v6CaGr1zgH8.)

Agile planning allows for flexibility in response to new information, but the amount and type of flexibility is different at each of these various planning levels.  If a company regularly pivots its 3-5 strategy then the entire firm is likely to have trouble succeeding.  The strategy level cannot be set in stone, but the fundamental direction of the company should not shift rapidly or regularly or else product development will lack a crucial foundation in corporate vision.  At the product and portfolio level, more flexibility will be visible; at this level there is greater responsiveness to market trends for both launching and retiring products.  Release planning walks a more delicate balance as certain features or feature sets may be promised for an upcoming release of the product; the need to make trade-offs on hitting deadlines versus adding functionality means release planning exhibits a greater degree of flexibility in Agile development than it often does in more traditional approaches.

The greatest levels of flexibility come in the iteration and daily planning that are the hallmark of effective Agile development; here the teams estimate and prioritize upcoming work and plans shift as new information emerges in the midst of the development process.  In this way the Agile approach to both planning and development maps well to Lean development (which is a topic I should probably write more about sometime soon).  One quote from a simple Wikipedia discussion of Lean helps to make this point: “As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system” (see this article for more on Lean: http://bit.ly/1fWmbli).

Agile planning is certainly designed to be flexible and responsive, but in the context of the planning onion it ought also to be proactive rather than reactive.  This flexible and responsive planning can be anxiety-producing for those who want defined product development timelines and Gantt charts; but in fact the multi-layered and iterative approach is actually more successful for developing complex software since so much learning will take place in the midst of the development process.  If the only type of planning that happens for an Agile development team is the daily- and sprint-level planning, my colleague’s misguided assessment of Agile can be unfortunately accurate.  But this is not how Agile is supposed to work; I will have lots more to say about effective Agile planning in the upcoming posts in this series, but hopefully it is clear already that strong Agile teams engage in a regular discipline of planning at multiple levels.  This is how it is supposed to work anyway; of course, in truth, it’s not that simple.