So you decided that you need some scaled agile approach.
Maybe you chose to implement the Scaled Agile Framework. Maybe Large Scale Scrum (LeSS). In any case, you have a new construct of a “Team of Agile Teams”.
You also listened during training and understood there’s a strong preference for feature teams over component teams in SAFe and that in LeSS, component teams are not even allowed in the door. So out of the eight teams on your “Team of Agile Teams”/“Program”/“Agile Release Train,” 7 are almost-feature-teams while the last team is a component team they often depend on.
But now something is troubling you…
Should all those Feature Teams be able to take on every Feature? Or does each team need deeper specialization/focus on the train? Is it even possible/realistic to expect complete flexibility? Is it a good idea from a “Respect People” perspective?
In this post, we will look at the question that comes up pretty often in my engagements.
Note: We will use the name “Agile Release Train” here for simplicity and because SAFe IS the more common thing out there. However, I also used the thinking in this blog for a LeSS context and other situations.
The case for flexibility
Why is flexibility so important?
We have one prioritized Backlog (a.k.a Program Backlog in SAFe) for the group of teams. We want to work according to the priorities in that backlog. And sometimes, the priorities are very focused on a particular area that we would like as many teams as possible to focus on/swarm to.
Chris Matts calls it Staff Liquidity.
The case for specialization — the technical aspects
What’s the case for specialization?
The main reason is that it is tough to overcome in most contexts. Creating flexible or even somewhat flexible teams is a long journey for most organizations.
In many cases, even when you’re a “Server-side” engineer, you can’t cover all the “Server-side” modules/systems/layers.
So, the natural tendency is to create feature teams where each team is able to deliver only a certain kind of feature. Every other feature would be tough for them to chew on.
Even if we could …
Even if we could create these fully flexible teams, some human aspects should be considered. Mastery and Purpose motivate people. Yes, we want them to connect to the bigger Purpose of the “Team of Teams”. Yes, we want them to be motivated by becoming “Full-stack” engineers or a “Jack of all trades”. But there’s a reason we call Jack a “Master of none”.
People both need to feel they have some Mastery of some area that makes them unique (even if they’re not the ONLY people with that Mastery).
They also need a tighter Purpose to connect to than the one that applies to the group.
The way forward — T-Shaped Teams
This is not a new problem with Agile. The same happens at the team level. We want a team to focus on the top things in the team backlog and we have practices like “Collective Ownership”, “Code Stewardship” that help us get from I shaped people towards T-shaped or even E-shaped people on the team.
So essentially, what we are looking for is the same across the “Team of Teams” — Instead of I-shaped teams, which can only do one thing, have T-shaped or E-shaped teams that specialize in one or a couple of areas and can also, in a crunch, do other things. This also means that they would be able to complete more features on their own.
We’re looking to let teams master a few areas at a technical and/or business/domain level. This means that while they can tackle many types of features — they have a “special” connection to a particular slice of the system/business domain. They would be the ones to nurture that area and take care of its Architectural Runway. They would be the ones to have a tighter relationship with stakeholders in that area. They would be the ones to lead the charge when there’s a tough time-critical feature in that area.
Visualizing flexibility/specialization to create Alignment/Transparency
What I’ve done with a couple of groups recently is use a scaled-up version of Chris Matts’s Skills Matrix (Henrik Kniberg’s “Is your team cross-functional enough” about this topic is very visual and instructive as usual) across the Team of Teams. This is what it might look like:
Team of Teams / Agile Release Train Skills Matrix
From this picture, we can very easily understand that we have several “semi-feature teams” and one clear component team.
Using the Flexibility/Specialization Program Matrix to Build the Flexibility Runway
This visualization helps the teams, as well as others, understand their current capabilities as well as their identified and chosen areas of growth — where they need and want to grow their mastery to improve flexibility.
This information can be used when discussing the program backlog and making high-level plans/capacity allocations for the different business themes the group is handling.
If there isn’t enough flexibility, assigning some capacity to enable that flexibility makes sense.
This can be thought of as the “Flexibility Runway,” where we invest in “Flexibility Enablers” to allow us to deliver more of the prioritized business features later on.
These “Flexibility Enablers” can be either pro-active learning or just a decision to let a team take on a feature that would require them to learn — incurring a certain “Flexibility Enabling Tax” onto the implementation cost for that feature.
Decentralizing Team Assignment Decisions
Left alone, teams will tend to pull features within their comfort zone. Managers/Leaders are nudging/pushing teams to act differently and feel they need to be part of the feature assignment.
With this visualization, as well as a certain capacity allocated to the flexibility runway, we can now let the teams pull features from the program backlog.
With this information in front of them and an alignment to the bigger purpose of improving our flexibility over time, even at the cost of some slowdown on the way there, we can trust them to look at the Features/Program Backlog, consider their options, and decide what each team should pull.
Check out “Managing the Top 2 Constraints in the Organization” by Chris Matts For another perspective on this topic and an introduction to an interesting planning technique inspired by the “Theory of Constraints”.
What if we DON’T want Flexibility?
I’ve also worked with Agile Release Trains/Groups that don’t want this flexibility.
They want feature teams, but they want them to be very focused on a particular product. They might have a Product Manager assigned to that product and that team with complete control of the backlog for his area.
I think that is legitimate.
But then we go back to why they need to scale. If their feature teams can deliver product features, what exactly do they need from other teams or from other product owners? Why incur the coordination overhead that comes with scaling?
For many of these situations, I recommend seriously considering breaking down to single agile teams or mini-agile-release-trains with minimal overhead/ceremony.
In other situations — e.g., when they have a shared component team they need to coordinate with — I would say go for a “Team of Teams,” but use your judgment to configure the framework to your needs.
I know SAFe has a supported mode of multiple value streams/products within one Agile Release Train. I think people should carefully consider what they’re getting out of it and what pain it solves for them before going in that direction. I understand the need to speak the same language across the Portfolio/Enterprise and for everybody to be on an “Agile Release Train”.
I urge us to look at “Mini /Lightweight ARTs” to accomplish that. Or look at ways to tweak the Agile Release Train to minimize unnecessary/wasteful coordination across teams that don’t need coordination.
Maybe their business context is the same. Maybe they share a business executive, a Product Manager, or both. Perhaps they should run the Business Briefing together. And then break out to teams as appropriate for a discussion of their Product. Or their Architecture. Or Development Practices. Maybe their plans review should be in breakout mode as well.
Look at the PI Planning and other SAFe program-level building blocks and experiment with what you do in breakout vs plenary mode.
Conclusion
Most people scaling agile, even those who manage to create feature teams, face the challenge of figuring out Team specialization vs flexibility.
I hope I convinced you that having a bit of both is essential.
You can try using the Program-level Skills Matrix with your teams/group leadership to look at where you stand and discuss your options.
You can try using the “Flexibility Runway” approach I suggested to help you drive investment in enabling flexibility.
And suppose you feel flexibility is not relevant. In that case, you can consider mini/lightweight approaches to the “Agile Release Train” to deal with the “overhead”/“boredom” that people experience when participating in activities that are not very relevant to them.
If you have any other experiences or ideas on how to deal with this challenge or any thoughts about my suggestions, feel free to comment here and let me know.