Member Article

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

When Agile teams 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 this series, we’ll be talking about the principles of capacity planning for the modern era: how should strategic planners— portfolio, product, and engineering leaders—create realistic and adaptable action plans from their business strategy? Let’s start by focusing on the first principle of capacity planning: thinking of the team as a resource unit.

We’ve interviewed many senior-level strategic planners tasked with determining how to plan their company’s future for the best outcomes possible, given their real-world constraints. One of these constraints is an industry-wide “talent management crisis.” In this knowledge worker era, planners no longer have the luxury of hiring any number of 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 emphasise 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.

More and more companies recognise the need for a new mindset. Rethinking resource management actually starts with rethinking capacity planning: how do you plan your ability to deliver value without impacting teams’ productivity?

The traditional approach to resource management and capacity planning- which relies on individual resource roles, temporary assignment of individuals to teams, and maximising resource utilisation-breaks down as companies rush to keep up with the accelerated pace of business. This accelerated pace calls for new concepts like decentralised decision-making, faster feedback loops, reduced task-switching, and ramp-up time for teams to become high-performing.

Unfortunately, most portfolio managers are ill-equipped to reap the benefits of their Agile delivery groups. The thinking must evolve from, “Which roles do I select for the virtual team I will assign to a project, and when do those roles free up to work on the next project?” to “Which teams are the best fit to work on strategic initiatives, and how do I balance my teams to be more innovative while sustaining current applications and products in the market?”

We’ve known for a while now that stable teams perform better; dismantling and re-forming teams for specific projects takes a toll on both quality and productivity. To those still skeptical, Rally’s data and metrics have proved the value of stable teams for software productivity, predictability, and responsiveness.

As more companies leverage stable teams to organise their resources, teams are superseding individual roles as the unit of resource for capacity planning. But what is a “team”? It seems like a simplistic question, but there are key nuances that influence how you go about doing effective team-based capacity planning.

When we think about a team in the Agile community, we often think of a cross-functional team- one with the recommended 7±2 members, doing Scrum or Kanban, and including developer, tester, and product owner expertise. It would be nice if all resources could be organised this way, but today’s product 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’- teams that can deliver entire features without dependencies on other teams- are recommended, as more companies create platforms to deliver products, component teams are still necessary for Agile at scale. 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 when necessary so that features can meet market delivery dates.

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

To summarise principle #1 of capacity planning: modern capacity planning needs to focus on the team as the basic unit of resources, yet model various types of “teams” in order to balance their use and best serve the needs of the business.

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