Principle #1 of capacity planning: the team as a resource unit

When teams use agile methodology to deliver value faster, they open up new opportunities at the strategic level for companies to respond and adapt quickly to changes in the market or business. 

In the coming weeks, I’ll discuss the principles of capacity planning for the modern era: how strategic planners create realistic and adaptable action plans from their business strategy. Let’s start by focusing on the first principle of capacity planning: the team as a resource unit.

Based on interviews with senior-level strategic planners, a major real-world constraint today is an industry-wide talent management crisis. Planners no longer have the luxury of hiring unlimited ready-to-go resources. This drives value-based analysis from traditional risk and return to capacity and time to market. We call this “capacity management,” to emphasize this shift from traditional resource management. Capacity planning then becomes focused on people first, as hardware costs are becoming less significant compared to the cost of hiring and retaining talent.

At a recent PMI Symposium I presented “Think Differently: Re-imagining Resource Management in a Disruptive Age”. The theme of my presentation was rethinking resource management starting with rethinking capacity planning: how do you plan to deliver value without impacting teams’ productivity?

The traditional approach to resource management and capacity planning breaks down as companies rush to keep up with the accelerated pace of business. This calls for new concepts like decentralized decision making, faster feedback loops, reduced task-switching and ramp-up time for teams to become high-performing.

We’ve known for a while now that stable teams perform better. Dismantling and reforming teams for specific projects takes a toll on quality and productivity. CA Technologies data and metrics have proven the value of stable teams for software productivity, predictability and responsiveness.The most dedicated agile development teams complete nearly twice as many user stories as the least dedicated.

As more companies use stable teams to organize their resources, teams are superseding individual roles as the resource unit for capacity planning. But what is a “team”?

In agile methodology, we often think of a cross-functional team–7±2 members, doing agile Scrum or Kanban agile with agile developer, tester, and product owner expertise. It would be nice if we could organize all resources this way, but today’s agile development world is not so simple. I have yet to talk to a customer whose entire delivery group is comprised only of cross-functional teams.

Although feature teams that deliver entire features without dependencies on other teams are recommended, as more companies create platforms to deliver products, component teams are still necessary for scaling agile. Component teams build domain services and tools in support of feature teams. Accounting for these component teams in capacity planning is key to making sure the components can be delivered on time so that features can meet market delivery dates. I recommend this great book on the topic, “Managing Software Debt: Building for Inevitable Change.”

Many companies have specialists or experts but too few to embed one in each cross-functional team. These experts tend to be tracked as a team of experts, which lends expertise to cross-functional teams when needed. When it comes to capacity planning, these experts create a bottleneck because their supply cannot usually meet demand.

To summarize principle #1 of capacity planning: capacity planning must focus on the team as the basic resource unit, yet model various types of “teams” in order to balance their use and best serve the business needs. Read about Capacity Planning principle #2: Roughly Right.

Catherine is an Agile Solutions Specialist at CA Technologies where she focuses on bringing the…



Insights from the app driven world
Subscribe Now >
Rewrite Rewind: APIs, Disruption and Cosmic Radiation >The Enterprise Gives Google Glass a Second Look >Real DevOps Practitioners Eat Quiche >