Like this article? read more in my book on Agile Organizational Design
In my last article, I stated that there can be very real structural challenges you can face when organizing into agile teams. I presented a few controversial statements and promised to elaborate. Ok, here goes my first one.
Stable Teams Erode Agility.
There, I said it.
This is a strong statement. And I admit I be trolling a bit to get your attention, while I have it I want to ask you think about what Agile is trying to address.
Uncertainty.
Complexity.
Change.
Agile provides us a means to deal gracefully with a world that is complex and constantly changing, and it does so through a mindset and methods based on using feedback to respond effectively to this constant change. Agile teams constantly shift in terms of what they are delivering and how they are delivering it.
I have seen a lot of organizations do a reasonable job of figuring out there agile team structure yet only succeed in creating a mess of dependencies. Hypothetically, lets say you have analyzed the demand for your organization, mapped it to capability, formed an ideal set of teams around those capabilities, and staffed those teams with people that possessed those capabilities. You can now sit back and let those teams deliver, right? You're done right?
Wrong
Now something changes, perhaps the market has evolved, priority has shifted, our understanding of the work has grown, or the competitive landscape has been altered. We uncovered the need for a new capability. We can no longer feed an outcome or an initiative to a single team within our structure.
We have two options here.
The first option is to keep our structure stable.
Perhaps some other team has those missing skills we need to deliver value? Couldn't we send that portion of the work over to the other team? We could, but now two team need to coordinate to deliver value, which interferes with each teams ability to independently self organize.
Maybe a piece of work involves more effort than we thought. Cant we keep the team the same size and take longer to deliver? We could, but we may delay feedback and learning, and depending on how important that feedback is to the team, we could deliver the wrong thing to the market.
Perhaps we have discovered a new opportunity, unlike anything we have done before as an organization, delivering it would require collaboration that spans across everyone of our teams. Couldn't we just coordinate the work across the teams? We could, but I think you get the idea.
Coordination requires classical, old school management. One that is now informed by agile backlogs, stories, visual flow, etc, but it is still old school management. The more teams become dependent on each other, the more they they will require dedicated people to manage this dependency, and the more they will lose their ability to self organize.
The reality is that stability and independence are concepts that contradict each other. You need stability, absolutely. Without stability people in teams do not have a chance to well, team.
But stable teams are not static team.
So let me rephrase my original sentence
Static Teams erode Agility.
Static teams don't flex when demand changes. Static teams mean you have hand offs across your teams as the cracks in your original team layout start to show. Static teams erode the independence of teams, and we need teams to have independence if we want self organization inside of teams.
The answer is an an evolutionary approach to designing team structure, conducted frequently
Be Agile About Your Agile Teams
Refinement of team design can be held at a cadence, done as part of the initial exploration of new opportunities. When we refine our make up of teams we need take care to minimize the impact that refinement has on team stability .
Better stated, we want minimize the changes we make to our team structure to those changes that allow us to minimize hand offs across those teams.
This is a balancing act, and not always an easy one, or even a possible one. Sometimes we end up sacrificing team independence for team stability, or vice versa.
It is a counter intuitive truth that team independence trumps team stability.
Visual backlogs, visual flow and other agile practices make it easier for people to self- organize around the work. This includes getting accommodated with a new team structure. But it takes courage, and it takes practice.
Refining team structures can be accomplished as part of an Agile style event, held at cadence, and dedicated to coordinating this type of planning. We can use flow visualization systems at the Initiative / MVP level to inform this cadence. We can facilitate informal, high level Epic /Feature analysis to inform our team structure. We can spot bottlenecks to inform where hand offs are acceptable and where they indicate a need for a structure with less hand offs. We will go through each of these techniques in the upcoming chapters in this book.
When demand fluctuates it tends to do so in a way that is recognizable to people that take the time to correctly observe it. Patterns start to form over time, patterns that not only leaders can see, but team members can recognize. Aided by a bit of Kanban style visual management, leaders and team members can observe changes in demand and participate in the deliberate and continuous evolution of team structure and how people are placed into teams.
Movement of people and change in team structure will start to become repetitive. This repetition reduces the social strain caused when people move across teams. Team members know when to expect people to come and go. People will start to form a collective understanding of when they need to move to a different team. In effect stable teams evolves to become stable social fabric. A fabric that gracefully flexes to take advantage of new opportunities.
Up next There is no such thing as an autonomous team
Like this article? read more in my book on Agile Organizational Design
