This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Tug of War: Big Up-Front Planning Versus Just-in-Time Elaboration
Big up-front multi-year plans should not be necessary to develop a ‘roughly right’ program plan to request budget approval on government programs when following Agile approaches.
The Challenge of Traditional Budget Determination in Government/Public Sector
The traditional funding request approach often seen in Government/Public sectors seeks to identify all program requirements up front, denoting work needed to deliver project requirements down to the hour so that a funding model can be run to determine budget. Since new development programs are full of uncertainties, budget numbers tend to be inflated to account for potential unknowns and “just in case” items when using a traditional funding approach. That approach adds risks and makes accurate long-range planning futile, misleading, and inaccurate.
Up-Front Planning Risks
Government tries to be risk averse by taking an approach of over specifying requirements when requesting budget for future development programs. Big up-front planning has been a perceived means to mitigate risk by locking down the requirements and associated budget estimates when allocating funds on a 1- or 2-year program before authorizing work to begin.
These estimates are based on a false assumption that all of the requirements are known up front when they are not.
Teams also tend to pad requirements with all of the things they think the program may need in the future because this may be the only time to get them into an approved plan. This padding adds unnecessary complexity, cost, and subsequent risk to a program, all while creating a false sense of risk reduction. It has been documented that big up-front planning of requirements and the rigor of that process bring no value to programs1. It has been shown that people are poor at detailed plans2 especially with emergent design when they don’t know what they don’t know.
The Importance of Agile in Government/Public Sector
Agile approaches are most applicable to development efforts on mission requirements where there is uncertainty in what the stakeholders need and when quick feedback loops are useful. Agile is about just-in-time elaboration as knowledge is gained in the problem space during the course of a plan development. Both the development group and the stakeholder communicate through quick feedback loops to enhance plan design and implementation.
Given this planning uncertainty, consider adopting a lean budget approach3. Detailed plans more than 2 quarters forward are a poor use of people’s time since those plans will often be overcome by events as the understanding of the problem space evolves and stakeholders gain further insights. Capabilities and features perceived to be important in the beginning may become unnecessary as development evolves and stakeholder needs evolve. Teams should not waste time and resources on detailed plans for work that may never be executed. Locking a program into a long-term detailed plan prevents the program from evolving organically to address the new emergent needs of the mission.
Ultimately, a team may execute the plan flawlessly, but, miss the needs of the mission. This is where an Agile approach prevails! An Agile approach provides visibility at all levels of planning from strategy through execution and delivery. Portfolio and program plans are broad brush cuts at high level needs that are captured in a high-level backlog. Detailed planning at the story and task levels is deferred until the last possible moment during mid-range release and short-term sprint planning when the stakeholder and delivery team have better situational awareness of the operational needs at that point in time. This approach works well for emergent designs.
Estimating Budget for Just-in-Time Elaboration
First, one needs to establish stable delivery teams that can develop predictable delivery flow/work item throughput. This is the basis for a solid delivery pipeline that work can feed into
from a prioritized list of roughly estimated Epics and Features, e.g., requirements using a point scale relative to a mid-range planning time box and defining the scope of work that will flow to the delivery teams for just-in-time detailed planning. Uncertainty will exist in this list, but limited time is spent on detailing that uncertain work.
Instead, Epics and Features are slotted into long and midrange planning time boxes based on the delivery teams’ historical rates of value delivered, points per time box, and cycles of planning. Knowing the cost for the delivery teams per planning/delivery cycle and the number of planning/delivery cycles required to deliver the Epic and Feature backlog, one now has a ‘roughly right’ estimate of what the program will cost and how long it may take. Beyond 1 or 2 quarters, the plan and budget will be uncertain, but when stakeholder value is determined at the end of each mid-range plan, teams are able to communicate via quick feedback loops during delivery cycles to provide proof that this effort is worth continuing. This just-in-time elaboration method allows for pivots as delivery teams and stakeholders become more informed.
Agile Training and Coaching Are Critical When Starting an Agile Adoption
Proper training and ongoing coaching are necessary to get delivery teams working and delivering value on a regular cadence. The goal is to have predictable delivery teams able to consistently deliver against their commitments. This occurs when delivery team members remain constant, measure their say/do, and inspect and adapt planning cycle over planning cycle with input from program management and stakeholders. This state of predictability does not happen in 1 or 2 quarters. It requires discipline—discipline through proper process training and use of on-site coaches to help teams avoid reverting to process status quo when delivery pressures mount.
An Agile Planning Tool is Necessary to Plan, Manage, and Measure
Agile planning and tracking tools, such as VersionOne, support strategic planning/tracking as well as team level planning/tracking and are vital to enforce the Agile process. These tools provide objective evidence of progress against plan, alleviating the dreaded data-call to satisfy the monthly program status reports. VersionOne provides the measurements needed by delivery teams to inspect and adapt their estimation process and delivery commitments for future planning while applying appropriate guardrails to the process.
Figure 1: PI/Release Scorecard
VersionOne provides Program Management a means to steer development groups from a portfolio and program perspective, allowing the delivery teams to focus on the details at the appropriate time. This gives Agile teams visibility to the higher-level objectives, so they know they are working on the right elements that add value to a plan. This also gives program managers and stakeholders the situational awareness they need to ensure value delivery is on track.
Figure 2: Budget by Planning Level
In order to secure budget appropriations, long range detailed planning is not necessary if adopting a roughly-right Agile planning approach. Given a prioritized portfolio and program backlog of Epics and Features roughly estimated in points, teams can predict how long it will take to deliver to a given depth in the backlog once a predictable delivery cadence has been established. By slotting that work into the fixed duration planning cycles and knowing the cost of the development teams per planning cycle, budget appropriations can be determined.
Visit CollabNet VersionOne’s website at www.collab.net to learn more about coaching services and product offerings to support your Enterprise Agile initiatives.
1. Lapham, Mary Ann; Garcia-Miller, Suzanne; Adams, Lorraine; Brown, Nanette; Hackemack, Bart; Hammons, Charles (Bud); Levine, Linda; & Schenker, Alfred. Agile Methods: Selected DoD Management and Acquisition Concerns. CMU/SEI-2011-TN-002. Software Engineering Institute, Carnegie Mellon University. 2011. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9769, page 20, paragraph 2