Many organizations find that when they start to adopt agile at scale (i.e., agile with more than a single team), their team structures need to change. In particular, companies that have historically relied on a large number of component teams as opposed to feature teams soon realize that doing so is typically highly disruptive to the fast, flexible flow of work desired when adopting agile. Once companies recognize that their teams are structured poorly for doing agile at scale they need to decide what to do about it and when to do it.
Some companies and consultants favor a “magical restructuring of teams” at the very start of an agile transition. In this posting I want to point out the realities that make this approach less than ideal while emphasizing a more iterative and incremental approach as a better choice.
Agile at Scale: An Example
Let’s start with an example. Last year I was helping a company adopt agile at scale. I trained about 700 people across approximately 90 teams and worked with the executive team on how best to organize for success.
The diagram below provides an approximation of how the teams where organized. A majority of the teams (all of the non “Applications” teams) were component teams.
It was fairly obvious to everyone involved in this agile transition that there was going to be a large number of asynchronous dependencies on the component teams when each of the geographies (Geo 1, Geo 2, etc.) did its planning. The issue was what to do about it and when to do it.
The Magical Approach
The magical approach, and the one that I frequently hear consultants recommend and observe some companies pursue, is to immediately transform (on day one) all of the existing teams to feature teams. This is, in my experience, a form of magical thinking: the belief that thinking that an approach is good is the equivalent of it actually being a practical, implementable strategy for solving a real problem.
In the rest of this posting I want to describe the realities that illustrate why a magical approach won’t work in practice and how successful companies actually deal with their team restructurings.
Reality 1: We Can’t Assume All Teams Should Be Feature Teams
The dogma in the agile world is: “Feature teams good, component teams bad.” In other words, organizations should eliminate all component teams and replace them with feature teams.
This approach assumes that all companies, in all the different industries, across all of the different types of products should use exactly one way of structuring their agile teams at scale. Of course, this is unrealistic.
As a general rule, I believe that at scale companies should have most of their teams be feature teams and occasionally have some component teams. The decision on how best to blend the two types of teams, however, should be made based on the economics of the choices with a focus on the fast, flexible flow of the work.
As a general rule, within a company most teams should be feature teams and occasionally there should be some component teams
So the magical approach that on the first day we should immediately restructure all of our teams to be feature teams could, and probably would, lead to a suboptimal solution.
Reality 2: We Won’t Know the Proper Team Structure on Day One
This leads me to the second reality: Since there isn’t a known universal team structure pattern to adopt (e.g., make all teams feature teams), if a company were to attempt a team restructuring on the first day, exactly what structure should it adopt?
Remember, the first day of any new effort (e.g., software development project, organizational restructuring), is the day we will have the least amount of information we will ever have about the project we are about to undertake. So, on the very day when we have the worst possible knowledge about what our future team structure should be, let’s make all the organizationally difficult, painful, hard-to-unwind decisions about how to structure our teams! How would that be any different than trying to determine the complete, correct, and unchanging set of requirements for a large new product on the first day?
A more agile-like approach to restructuring teams is to do it iteratively and incrementally. I’m not suggesting that a company should make no team restructuring decisions on the first day. However, as a general rule, if you don’t know what you’re doing, then don’t do it on a large scale.
If you don’t know what you’re doing, then don’t do it on a large scale
When adapting a team structure, it would be better to do so as iteratively as is practical within a given company. In other words, make a (team structure) change and then measure the results to see if there is an improvement (e.g., have we improved fast, flexible flow). Based on my experience, when is comes to structuring teams, there is no perfect answer; there are, however, good answers with compromises. We need to iterate ourselves towards those good answers while making the compromises we are prepared to make.
There is no perfect team structure at scale; but there are good team structures with compromises
So, it is magical thinking to believe that on the first day we could restructure our teams to some unknown desired future structure, especially since we are unlikely on that day to know what would really make for a good structure for our teams.
Reality 3: Change Is Associated with Real Emotional Entanglement
Making structural changes to teams is often fraught with emotional entanglement. Many companies I have worked with have done multiple reorgs over the past several years and the employees really don’t have an appetite for yet another restructuring effort. I’m not suggesting that we shouldn’t make changes because of previous activities. I am however sensitive to the fact people in these situations can become demoralized and at times proactively work against making such changes.
I have found that we can often ratchet down the emotional entanglement by being clear on what we are doing and why we are doing it, and then making changes in reasonable increments. This approach lines up well with an iterative and incremental approach to changing the team structures. We begin by making the case for why team structures need to change by establishing baseline measures for how well (or not) work is flowing today. Then, as we start to incrementally make changes, we measure how we are improving against the baseline measures.
Remember too that there are many other people-related issues that must be addressed in the presence of an emotionally charged decision. So, companies looking to adopt agile at scale would be well served to be thoughtful about when and how to make team-structure changes. I have observed that emotional entanglement is not well addressed when the solution is based on assumptions that are either hard to believe or viewed as unsubstantiated.
Reality 4: Restructuring Teams Could Disrupt Current Development Efforts
The magical approach assumes that an immediate restructuring of teams would not materially impact products under development. In the example diagram I presented early in the blog, the 90 teams that needed to transition to agile were already on tight deadlines to get major new releases of several products out the door. Additionally, this public company’s revenue projections for the current fiscal year could only be met by getting the products under development completed and released.
Do you think that senior management wanted to put at risk several critical development efforts that were well underway by instituting a major team restructuring? Absolutely not! Management was certainly willing to entertain some initial team restructuring. However, the risk of disrupting current work in process governed the extent of such initial changes.
So, it is magical thinking to believe that a major restructuring will not impact existing work in process and that somehow this impact can be ignored!
Conclusion
When a company is transitioning to use agile at scale with multiple teams it will likely have to restructure some or many of its teams. However, assuming a magical restructuring of the teams on the first day to an unknown structure, in the presence of an emotionally charged environment, potentially putting in jeopardy in-process development efforts is not a viable approach. Instead, companies should approach restructuring of their teams in an iterative and incremental approach, just like other aspects of their transition to agile.