This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives
In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.
In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.
Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.
Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows. The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage. However, the implementation of each objective with specific practices depends on the level. For each of the four objectives, there are four practices corresponding to four levels of planning. Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.
Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices
Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook: At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.
Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions: Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop). Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence. Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.
Objective 3 – Develop your agile plan: At each level of planning, several outputs must be produced to develop the Agile Plan at that level. Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning. Note that the agile plan also needs to specify how workflow against the plan will be monitored.
Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis: An agile plan is not an end-all in itself. As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning). The nature and method of re-planning change with the planning level. The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.
Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.
Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations
Figure 3 shows this relationship along with an explanatory legend. I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook. Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1. Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook. Four planning level-specific playbooks are part of the Agile Planning Playbook. Each level of planning provides the context for the next lower level of planning. Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.
Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook. As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.
If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook. Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level. Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level. An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes). This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.
Guidelines for customizing the Agile Planning Framework: For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.
Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums. As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.
For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive. A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints. Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.
For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums. Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.
For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified. Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.
You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation. Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible. If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.
From Agile Planning Framework to your customizable agile planning playbook: Agile champions owning the agile planning playbook have many important responsibilities:
- Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
- Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
- After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
- Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
- Improve the agile planning process and the playbook on an on-going basis.
The resulting agile planning playbook can be a brief document or a set of wiki pages. However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite. I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.
If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale. If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.
Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success. Excellence in agile project execution is also essential, in addition to be good at agile planning. However excellence in execution will not be effective in delivering business results without proper agile planning.
The first blog of this blog series:
- Blog 1: Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels
If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.