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 the coming weeks, 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 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.
Last month I attended the PMI Symposium in Denver, Colorado, to present, “Think Differently: Re-imagining Resource Management in a Disruptive Age”.
More than 100 folks came ready to hear about how to think differently when it comes to knowledge workers: building stable teams, filling the product manager role. and limiting work in process. This was a great sign that more and more companies recognize 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 maximizing resource utilization -- breaks down as companies rush to keep up with the accelerated pace of business. This accelerated pace calls for new concepts like decentralized 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.
The most dedicated teams complete nearly twice as many user stories as the least dedicated.
As more companies leverage stable teams to organize 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 organized 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. Chris Sterling, Director of Engineering at Rally’s Kirkland office, has written a great book on the topic of feature teams and component teams, Managing Software Debt: Building for Inevitable Change.
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 summarize 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.
Continue Reading: Principle #2 of Capacity Planning
Interested in learning more about team-based capacity planning? You can reach us at firstname.lastname@example.org (most of our team is located in Rally’s beautiful Kirkland, WA office, close to Orcas island, and we happen to love big animals,).