Member Article

Principle #2 of capacity planning: Roughly right

In the first principle of capacity planning—using the team as a resource unit – we thought about different kinds of teams, such as feature and component teams, which become the “currency” for capacity planning. Now we’re going to focus on the second principle of capacity planning: “roughly right.”

When we consider Agile at scale, with larger sets of teams, capacity planning becomes much more complicated than it is when managing a handful of teams. The reason we spend effort and time creating estimates, forecasts, or projections is that it lets us peer into the future, make predictions, consider alternatives, and choose the best options. Then we can steer the organization towards highest-value returns for customers and the business alike.

Except in the simplest of cases, all these efforts contain inherent uncertainty. As we attempt to predict outcomes further into the future, uncertainty increases exponentially. At the business level, we have to learn to feel comfortable with uncertainty instead of fighting it, and remember that we can never completely do away with it.

It is better to be roughly right than precisely wrong.

—John Maynard Keynes

Roughly right is the opposite of precisely wrong. Traditional techniques often force us to detail work packages until all things are known and capacity can be 100 percent utilized through work assignments. This is precisely wrong! The Rally team once worked with a CFO who would recite this Keynes quote whenever corporate budget reconciliation was yielding unrealistic scenarios and overly risk-averse plans.

Roughly right reminds us to match accuracy and confidence with planning horizons. People waste precious weeks, months, and years in the pursuit of too much accuracy. One particularly expensive planning horizon is annual planning: we cannot afford to involve all teams in early levels of estimation. This may sound anti-Agile to some, until it becomes clear that estimates for something that’s not selected and never worked on are wasted time and effort. The best way to manage uncertainty is to compare supply and demand at a level appropriate for the planning timeframe, and then distribute the results to teams who need both the authority and accountability to plan at a more refined level, within a shorter planning timeframe.

For example, you might plan for a year and predict that increasing the number of teams by three in specific component areas will improve throughput and reduce technical debt. These initiatives can then be handed to the existing teams to determine how best to achieve the desired outcomes. The existing teams are best equipped to figure out the details of how they absorb the new teams and how to plan the initiatives. The teams can disaggregate and prioritize into more fine-grained initiatives that fit within smaller timeframes, such as a quarter (shorter timeframes are typically less uncertain than longer ones.) With proper feedback loops, we can all ascertain whether the initiatives are meeting the objectives. If not, we can adjust early.

Roughly right capacity planning is performed differently depending on the planning cadences under consideration: whether the cadence is a year, half a year, or a quarter (mid-range.) Because talent is scarce and software systems have grown complex, you cannot hire fast enough to make a difference in the next three to six months (from a planning perspective.) Thus we must accept the assumption of a fixed capacity at mid-range planning, which means we resort to “robbing Peter to pay Paul” in order to tune a portfolio for maximum value delivery.

You might wonder, then, What unit should I use for roughly right? Recognize that empirical estimates, like velocity, are best; but estimated effort (LOE or “Level of Effort”) may be the only one available at a rough level. This can happen for many reasons, for example if are considering hiring new teams who have no empirical data to use. For this reason, capacity planning units should be the same across the entire organization. This decouples the high-level plans and emphasizes team level authority and accountability with alignment into the rest of the organization.

Two things in Agile are not iterative—the time used up and the money that was spent—and are gone forever. As Agile scales to larger and larger pursuits, capacity planning requires special attention. Getting the right people working on the right things requires planning ahead of taking action—sometimes far ahead, if you hope to align to a business strategy. The precision by which we can plan is far less than most executives or business leaders are comfortable with. This is not caused by agility; this is caused by increased complexity and the need to move faster. This is why we have to get good at being roughly right.

This was posted in Bdaily's Members' News section by Rally Software .