Where are we? And, what are we doing? No project is an island onto itself.
Module 1—Objectives
• Discuss and explain the need for agile planning, especially in the en- terprise context
• Familiarize readers with planning drivers and the need to adapt
It’s Agile! Why Plan? Why Schedule? Why Estimate?
Why plan, why schedule? Indeed, the question might even be: Why esti- mate? It’s all going to change anyway.
The answer is quite clear:
If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure. Without measurements, there will be no benchmarks, no
improvement, and no answer to the questions of where are we? And what are we doing? In fact, without a plan, anywhere and anything will do.
Planning Dominates Management
A few activities dominate almost every aspect of project management, whether for agile projects or others—planning and estimating on the one hand, communicating and executing on the other. Managed properly, the ideal project trajectory hits within reasonable error bounds of targeted cost and schedule while satisfying customers to the maximum extent possible. Taken together, planning, estimating, communicating, and executing are a big stage. This chapter concentrates on planning for cost and schedule.
Plans are not altogether objective, taking into account as they do values, conventions, and business imperatives of the enterprise. But even without complete objectivity, plans are an effective tool to provide the rationale and evidence that stakeholders require for committing resources. But to be cred- ible, evidence needs backup in the form of estimates. Estimates we define as the objective results of analysis and melding of historical performance with judgment about future achievement. Estimates are the subject of another chapter in this book, where they are discussed in detail.
Are We Done?
So the team needs a plan, but a plan consistent with the role of the project manager to facilitate and motivate performance—not to direct the team’s day-to-day activities.
But, just as we need plans to get started, we need a plan for when we are done. After all, one big theme of agile project management is to shift much—but certainly not all—of the management focus to outcomes, put rather less on managing inputs. The operative questions become:
Are we done? And, if so, what are the parameters of “done”?
Look back to Principle 5 of the Agile Principles given in Chapter 1.
Agile Principle 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get
the job done.
• It is the job described in the business plan and in subsequent project plans, albeit lean plans consistent with the Agile Manifesto
• It is the job estimated and scheduled
• It is the job as interpreted in near real-time by the functional user • It is the job that evolves over several iterations and is adapted to the
emergent value proposition
Trust them to get the job done. What is the definition of done? • Is it done when time/money runs out?
• Is it done when the backlog is fully exhausted?
• Or, is it done when the customer says it’s done, or someone else says it’s done?
To the first point, what job? The job is to be strategically predictable ac- cording to the business case, but tactically opportunistic according to Agile Principles. In practical terms, tactically opportunistic is best value—the most scope, and the most valuable scope from a business/mission perspective, that is affordable.
We’ve addressed this idea before, but for emphasis the job is to be as responsive to customer need as is practical in a best value sense, given a project narrative (the strategic aspect) which must be honored, while op- timizing tactical opportunities that have parameters like urgency, business priority, sequencing constraints, risk to project or business outcomes, invest- ment and financial return impacts, etc. All else goes in V2.0.
To the second point: are we done? Certainly agile is done when the money runs out; it may be done if all the best value backlog is achieved be- fore the money runs out (take note: better is the enemy of good, so release
good now). But, if you say it’s done when all the requirements are satisfied,
you’ll never finish, because all the requirements are never known.
Of course, done is not entirely in the hands of the customer. There are a myriad of requirements that are part of the project backlog that answer to others:
• Nonfunctional: The customer usually doesn’t have a say about non- functional requirements, yet they figure heavily into done.
• The release: Theoretically, an agile project is zero base after every re- lease and could be ended right then and there. A specific release could be the marker for done.
• Technical and functional debt: Debt is the myriad of punch list fixes and tuning that polish the deliverables for final delivery. Such debt could be small-scale tests that are incomplete, last minute look-and- feel changes, or small-scale functionality that needs to be tweaked.
• Undelivered backlog: There’s always another project to absorb the un- delivered backlog.
As the project goes along, note that the backlog may increase due to the accumulation of technical debt or added requirements, or we may abandon some of the backlog because we’ve come to understand, as things emerge, that they are no longer needed or necessary, thereby creating space and ca- pacity.
Agile Planning Portfolio
The thing about planning agile projects is that there is not one plan, but many plans—and the plans change frequently. By doctrine, plans are simple in structure and amenable to updating. The planning is distributed over time and among teams as the need arises. Plans will often be just spreadsheet or database templates with certain information filled in. Scorecard templates and a dashboard are lean and useful means to convey the information and support team planning meetings.
The need to create points of coordination and integration among projects in a portfolio, among work streams in a project, and among development teams within a large-scale project is what distinguishes a portfolio of plans useful in an enterprise context and those more limited plans needed to sup- port one project more or less in isolation.
At a scale that has impacts throughout the enterprise, plans are of ne- cessity more structured, less elastic, and more formal. However, even in the enterprise context when the planning is close to the work—at the iteration level for instance—plans, schedules, and estimates are more in the character expected of agile: all but informal, elastic and adaptive, and structured only insofar as the team finds value in the structure.
Agile Plans Adapt
Empirical process control, emergent solutions, nonlinear methods, customer- driven value—with all of these unplannables, is it possible to make a useful plan? Yes, the agile team can be coached to converge on an acceptable solu- tion within a reasonable range of possibilities. Some governance and project management are needed, just enough architecture is required, and a plan- ning framework called rolling wave planning is necessary for adaptive plans.2 Agile projects are expected to adapt repeatedly in close proximity to the need. The working assumption is that the complexities of intangible re- quirements and systems preclude knowing enough to write a complete plan at the outset. Much like the wicked problem, the solution will ultimately
define the need. Furthermore, the team is expected to modify practices ap- propriate to the evolving product, mentored by the project manager and other subject-matter experts.
Plans must adapt if for no other reason than because planning is the cre- ative and innovative part of management. Planning is thinking; planning re- quires thoughtful consideration about an intended course of action. And planning is where many of the discriminating ah-hahs emerge. Planning creates a focus, forces creativity to be committed, and adds order to what might otherwise be chaos.
In plan-driven project development lifecycle (PD-PDLC) methods, plan- ning absorbs many resources—it is hard to do in the first place, and once done, detailed plans are even more consuming to maintain so that they retain their relevance and value. In reaction to the experience of the PD-PDLC, the Agile Manifesto steers the other way. Discussion, debate, and conversa- tion are valued over documentation, but documentation is not absent, only minimized to improve effectiveness.
A project management tip
Plan sufficiently
Caution is advised—adopting too literal of an interpretation of the Agile Manifesto may lead to under-planning—insuf- ficient to properly represent the project to the stakeholders and provide guidance to the teams.
Work-stream Plans
Master plans for each work stream are derived from the business plan; mas- ter plans are adapted horizon-by-horizon. The planning horizon is a time box of sorts applied to the release schedule. All planning conforms to the concept of rolling waves from one horizon to the next. As one horizon is achieved and the next appears, another set of plans are cast.
The project manager maps major business milestones to the work streams. Work-stream milestones are the most important release dates. They frame the planning horizons for a product going live to production. Recall Figure 5.7 (Wave planning) which is adapted to the work-stream planning horizons and shown in Figure 6.1. It is evident from Figure 6.1 that the uncertainty of each work stream is not the same; the product development work stream has the most far future uncertainty, reflecting the uncertain influence of customers on the scope of delivered features and functions.
On the other hand, project management has relatively little uncertainty, reflecting that the work of project management is insensitive to variations in scope details.
A somewhat similar approach is followed to come up with a budget plan for each work stream. Developing the budget at the work-stream level is tantamount to developing the project balance sheet for each work stream. The left side of the balance sheet is developed first and is provided top- down by the business. Investment is usually allocated proportionately to the work streams according to a value judgment by the business.
As explained subsequently, other methods may also be appropriate. The right side of the balance sheet is usually built from estimates arrived at by looking at facts and forecasting future performance. Right–to–left side gaps are addressed between the project manager, team leads, and stakeholders.
Each work stream is planned for one planning horizon at a time, understanding that uncertainty increases in the far future, although the degree of uncertainty is different for each work stream
Product development
Project management work stream
Business Case Milestone 1 Milestone 2 Milestone 3
Outcomes Iterations Infrastructure Business preparation Planning horizon 2 Planning horizon 1
A project management tip
Plans for work streams and teams
• No project balance sheet, milestone plan, or budget is im-
posed on the project without consultation.
• Management by Agile Principles requires conversation, it-
eration, collaboration, and negotiation to make allocations and identify gap mitigation.
Release Plans
Agile Principle 1 demands frequent delivery of working product to satisfy customer needs. This requires a process for releasing completed objects into production or go-live. Usually there are these process steps to be planned in a release planning session:
• From the project backlog, select backlog for the next release based on velocity predictions for throughput, priorities, and sequencing de- mands
• Allocate the release backlog among iterations or sprints, allowing buf- fer space for working off debt, ensuring a sustainable pace, and ad- dressing unforeseen needs
• Plan a release buffer as an empty iteration to protect the release date and release process
• Establish the release protocol for sign-off, integration tests, user accep- tance tests, and the go-live play book—the order and nature of scripts that run to put new objects into a production state
Leading into the release there may be useful information gathered at retro- spective points as each iteration, sprint, or work-in-progress (WIP) group- ing is completed. Such lessons learned and other input into the release plan evolves and emerges as the iterations proceed. Thus, a second round of re- lease planning is appropriate to take these data into account.
Time-boxing Plans
Within work streams are teams, each working on iterations or sprints to develop and deliver some working scope to the product base. Time boxing is the main strategy for planning the schedule horizon-to-horizon instead of lower-level Gantt or network task and activity schedules.3 So a plan consists of some number of teams executing within time boxes, each team operat- ing at its own estimated velocity—throughput—and each team executing a portion of the business-case backlog as its scope.4
All things being otherwise fixed, the total duration of the work-stream timeline is the sum of the non-overlapping time-boxed iterations. By Agile Principle 4, every iteration ends with a working product that can be released to the product base. The project can end at the discretion of the sponsor and the project manager after almost any release.
Obviously, there must be points of coordination and reconciliation of team efforts. These points form a network with dependencies. The network can be simplified by having each team perform synchronously in time boxes of the same duration so that work products from one team are available to all teams when the next iteration cycle begins.5
Work-In-Progress Plans
WIP plans show the sequence and timing of WIP among all Kanban or pipe- line processes. Not all methodologies apply time boxes, as we read in Chap- ter 1. For instance, Kanban is not a time-boxed practice, though it could be a practice embedded in a time box. Thus, some other working plan is needed, often using a planning tool or practice that is visual. Kanban charts, burn-down charts, or some combination of a Gantt chart and a milestone chart is used. Elsewhere in this book we address the Kanban chart and the burn-down chart.
Labor Plans Team-by-Team
Given a time-boxed duration and a velocity benchmark team-by-team, a la- bor plan can be derived for each team and iteration within a planning hori- zon. These team-iteration labor plans identify individuals, skills, and time commitments. When there is more than one team, key individuals may have to be shared. Multiply the labor plan commitments by the chargeback rate6 for each resource to obtain the labor-cost plan.
When planning individual commitments, care must be exercised because each team’s velocity is sensitive to its cross-functional makeup, its experi- ence skill-by-skill, and its membership—not too few and not too many. The training and experience of the team as a self-organizing and collaborative body, as well as the environment and tools, also affects velocity.
Daily Plan
Each day begins by putting together a daily plan for the work to be done in the day ahead. Teams do this for themselves. The project manager provides facilitation. Each team member contributes a few simple sentences identi- fying what he or she will work on that day and what accomplishment he or she expects. The plan is reviewed at a morning daily stand-up meeting.
The meeting is time boxed to allow each member just a few minutes to talk about his or her personal plan. Every team member is expected to partici- pate and to speak to his or her day’s plan. Solutions are not discussed, but if there are needs for special-topic meetings, then these are arranged.
At the end of the day, the results of the day are checked into the product control system. The product base is rebuilt each day whenever practical.
On some teams, an end-of-day stand-up meeting is also held. It is simi- larly time boxed; it is not a solution meeting. Its purpose is to assess whether the daily plan was successful and to identify impediments and barriers for the project manager to address.
Summary of Planning Portfolio
Table 6.1 contains an abstract of the discussion.
Planning Drivers
A planning driver is a condition, circumstance, policy, or external influence that causes a plan to be written in the first place, or bears upon the scope and content of existing plans. Of course, this begs the questions: On whose
Table 6.1 Summary of plans
Plan Commentary
Work-stream plan • A flow down of the business plan milestones and budget limits to the
work stream according to the WBS
• Flow down is controlled by estimates made the project management staff and team leads
• Planning detail is rolling wave in style, reevaluated at each planning horizon
Release plan A plan for all the actions necessary to put into production, or go-live
with the backlog capabilities selected for a specific release
Time-boxing plan A plan of some number of teams executing within time boxes, each
team operating at its own estimated velocity—throughput—and each team executing a portion of the business-case backlog as its scope
WIP plan WIP plans show the sequence and timing of WIP among all Kanban or
pipeline processes
Labor plan A team-iteration work assignment plan to identify individuals, skills, and
time commitments
Daily plan The working plan for the day developed by each team member for their
shoulders do these drivers fall? Is it different in an agile project than it might be in a traditional project?
Principle of Subsidiary Function
The first question, on whose shoulders does planning drivers fall is answered by the Principle of Subsidiary Functions. Agile methods follow this prin- ciple, which holds that no central authority should do what a subordinate entity can best do for itself; authority that is not specifically enumerated is delegated to subsidiary or subordinate units. And, to authority please add
responsibility. Both march as a pair in the agile project domain.
There are rights and responsibilities that come with this principle. The central authority has a right to expect responsible behavior of its subordi- nate, but retains the right to verify performance—to trust, but with veri- fication—and intervene to impose corrective action. The subordinate unit has a right to expect a degree of autonomy with reasonable inspection and verification, so long as the subordinate acts responsibly. The subordinate has a responsibility to act in its own interests and in the interests of the central