Agility doesn't come from Agile Teams

The story so far:

1. Agile teams, rather than functional departments, should form the basis of any Organizational Design
2. But in many cases I see agile teams that operate in an environment of dysfunction and confusion
3. Team stability can actually reduce agility!
4. Team Independence is a myth!

Like this article? read more in my book on Agile Organizational Design

OK, now my final post on challenging Agile sacred cows...

Agility doesn't come from Agile Teams.

All right. Now I am sure some of you are going to come out with the pitch forks.

Ok, how can we say agility does not come from Agile Teams? Didn't I say previously that Agile Teams are awesome?

Hear me out. A lot of Agile thought-ware puts focus on the team. How is the team velocity? What are the team's practices? Can the team meet the teams's sprint commitments? How did the team retrospective go? Is the team blocked? What are team level impediments?

It's not that there is anything wrong with a strong team focus. We want a strong team focus. But a team view can be myopic, especially if you are working in a larger organization. We can optimize on team's health, but have no effect, or even cause harm to organizational outcomes.

Let's take an example, Team A is a software delivery team that works with Team B who delivers end user training to customers. Team A is rocking it! They deliver and they deliver quickly! Team B is not keeping up. They can't get users trained fast enough to keep pace with all the changes to software Team A is making. Worse, Team B starts to compromise quality to keep up. This leads to poorly trained users. These users make mistakes using the software, which causes further problems with customers. As a result customers stop using Team A's software, market share is loss and profitability goes down. None of this is apparent from team practices, team metrics, or a single team focus.

A lot of agile "scaling" frameworks attempt to address these and other scaling issue by adding a layer of processes to the mix. Some of the ideas coming from these frameworks are pretty decent, and some are frankly quite ridiculous. What the "more process is required to scale camp" does not always get is that Agile teams work because they create an environment of high social cohesion.

At scale we need social cohesion to present in more than just within an Agile Team

Fundamentally, agile teams are awesome because when they are functioning well are a social construct that results in a high degree of social cohesion. Niels Pflaegings calls it Social Density, and discusses the dynamics of social density in his book Organizing For Complexity.

If we want to scale agility beyond a single team, we need to look for ways to scale social cohesion across the team and the organization. We can use formal and informal structure for this very purpose.

So, in a similar vein to my last article, let me rephrase my original statement.

Agility doesn't come from (just) agile teams, we need other social constructs as well.

I discuss some of the formal structures that can increase organizational cohesion in my book on Agile Organizational Design. Specific topics of focus will include:

Fundamental agile organizing structures such as the Edge, Outer Cores, and Inner Cores. I'll discuss organizing team into Context Boundaries where multiple teams can share in a mission, outcomes or platform. These team can leverage common identifying artifacts, such as business models and overarching backlogs.

• Team Collaboration Patterns Different ways people can can collaborate across teams to create value. How concepts like Travelers, Enablers, CoPs, Swat teams etc can grow structures where people form around the work, rather than letting work scatter across the org.

Defining Jobs and Roles in an Agile Organization

Describing Jobs and Roles in terms of how individuals can interact and move across different roles. How can we turn what is the typical nightmare of inane job and position descriptions into something that better reflects our need to collaborate and grow in a social settings

Future chapters, to be written, will include

• Connecting the organizational design to the concept of domains, including how Domain Driven Design and Micro-Services play into organizational design at scale
• Illustrate how Visual flow systems ala Kanban can be used to help people form both stable and dynamic organizing structures

Agile Organizational Design, In a nutshell

So, Agile Organizational Design is about looking at your demand, your outcomes, your roadmap, whatever.

Asking your self "How can people form into self organizing social structures that can effectively deliver on the the things we want to deliver on next?" and refining those structures accordingly.

And then asking "What support structures need to be in place to help my teams operate at scale?" and standing them up.

And finally asking "What has changed in my context, and how does my organization need to flex in response?" and doing it all over again.