Key Principle: Plan Based on Measured Team Capacity

An effective organization views each team and the organization overall as having a particular amount of capacity for software development work. This capacity is a function of individual productivity, team productivity, staff additions and losses, and gradual, measured productivity improvements over time.

An effective organization measures its capacity and makes plans based on its measured, empirical performance history— typically based on each team’s velocity. This approach contrasts with a more visceral approach in which an organization bases its plans on the expectation that its teams will demonstrate abrupt increases in capacity (that is, “insert miracle here”).

The difference in approaches to self-assessed capacity for technical work comes into play in project-portfolio planning and in setting project deadlines. If the organization views its own capacity clearly, it will distribute work and assign deadlines that can be met by the teams. If the organization bases its plans on the assumption of abrupt increases in capacity or on unknown capacity, it will overload its teams and set up the teams and the overall organization for failure. Aggressive views of organizational capacity—and the project pressure that ensues—give rise to several unintended, ultimately destructive consequences:

• Teams aren’t able to meet their commitments (sprint goals), which in turn means the organization isn’t able to meet its commitments.

• Because teams aren’t able to meet their commitments, team members do not feel a sense of Mastery over their work, and their motivation suffers.

• Excessive loading on teams competes with the Growth Mindset, which undermines the ability of the team and organization to improve over time.

• Excessive loading also results in burnt-out teams, higher turnover, and reduced capacity.

As I wrote in Rapid Development more than 20 years ago, leaders apply pressure to their teams in the belief that the pressure will create a sense of business urgency and force useful prioritization. In practice, the attempt to instill business urgency most often has the effect of sending teams into full-scale, counterproductive panic—even when the leaders perceive themselves as applying only a tiny amount of pressure (McConnell, 1996).

Agile development today offers useful tools for prioritizing work at both the team level and organization level. Use those tools instead of applying pressure.

Establish communities of practice

Organizations we’ve worked with have found that establishing communities of practice to support the Agile roles accelerates effective performance of the roles. Composed of people who share an interest in what they do and want to get better at it, each community defines the kind of interaction that works best for its members. For example, meetings can be in-person in real-time, or they can be online.

The focus of community-of-practice discussions can be any or all of the following:

• Share knowledge generally; coach junior members

• Discuss common problem scenarios and solutions

• Share experiences with tools

• Share lessons learned from retrospectives (and invite feedback)

• Identify areas of weak performance in the organization

• Network

• Identify best practices within the organization

• Share frustrations, vent, and support one another

You can set up communities of practice for Scrum Masters, Product Owners, Architects, QA staff, SAFe Program Consultants (SPCs), Agile Coaches, DevOps staff, and other specialties. Participation is usually voluntary and self-selected so that only people who are interested participate.

The role of the organization in supporting more effective agile

Some attributes that support successful teams are under the teams’ control; many are controlled at the organizational level.

Agile teams cannot be successful if their organizations undermine their efforts. Organizations do this by blaming teams for mistakes, not supporting the teams’ Autonomy, not adequately communicating the teams’ Purpose, and not allowing for growth of the teams over time. Of course, this is not unique to Agile teams; it’s true of teams in general.

Teams can be most successful if their organizations support them by establishing a blame-free culture organization-wide, staffing the teams with the full skill set needed, loading the teams with appropriate workloads, regularly communicating the teams’ purposes, and supporting the teams’ growth over time.

Depending on where you are in your Agile journey, other leaders in your organization might need to take this journey with you. If you refer back to the Agile boundary you drew in the (“What’s Really Different About Agile?”) chapter, you can identify those other leaders and make plans for how to work with them.