Is your SAFe Agile Release Train flexible enough?

Estimated Reading Time: 6 minutes

So you decided that you need some sort of scaled agile approach. (If you’re not sure yet maybe this can help).

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 actually listened in training and understood that there’s a strong preference to Feature Teams over Component Teams in SAFe and that in LeSS Component Teams are not even allowed in the door. So out of the 8 teams on your “Team of Agile Teams”/“Program”/“Agile Release Train” 7 are actually 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 to have some deeper specialisation/focus on the train? Is it even possible/realistic to expect full flexibility? Is it a good idea from a “Respect People” perspective?

In this post we will look at this question that comes up pretty often on my engagements.

Note: We will use the name “Agile Release Train” here for simplicity and because SAFe IS the more common thing out there. But I used the thinking in this blog for a LeSS context and other situations as well.

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 certain area that we would like as many teams as possible to focus on/swarm to.

Chris Matts calls it Staff Liquidity.

The case for specialisation – the technical aspects

What’s the case for specialisation?

The main reason is that for most contexts it is really hard to overcome it. Creating totally flexible time or even somewhat flexible teams is a long journey for most organisations.

In many cases even when you’re a “Server-side” guy you can’t really cover all the “Server-side” modules/systems/layers.

So the natural tendency is to create feature teams where each team is actually able to deliver only a certain kind of feature. Every other sort of feature would be very hard for them to chew on.

Even if we could …

Even if we could create these fully flexible teams there are some human aspects to consider. 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 special (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 level and/or a business/domain level. Which means that while they are able to tackle many types of features – they have a “special” connection to a certain 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.

Visualising flexibility/specialisation to create Alignment/Transparency

What I’ve done with a couple of groups recently is use a scaled up version of Chris Matts 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 / SAFe Agile Release Train Skills Matrix
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 is important information that  can be used when discussing the program backlog and making high level plans / capacity allocation to the different business themes the group is handling.

If it seems like there isn’t enough flexibility then it makes sense to assign some capacity to enable that flexibility.

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 find themselves 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 Contraints”.

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 very focused on a certain Product. They might actually have a Product Manager assigned to that product and that team with full control of the backlog for his area.

I think that is legitimate.

But then we go back to the question of why do they need to scale? If their feature teams can deliver product features, what exactly do they need from other teams? from other Product Owners? Why incur the coordination overhead that comes with scaling?

For many of these situations my recommendation is to actually seriously consider 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 judgement 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, what pain it solves for them, before going in that direction. I can 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” as a way to accomplish that. Or to look at ways to tweak the Agile Release Train to minimize unnecessary/wasteful coordination across teams that don’t really need to coordinate.

Maybe their business context is the same. Maybe they share a business executive; or Product Manager; or both. Maybe they should run the Business Briefing together. And then breakout 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 that manage to create feature teams, face this challenge of figuring out Team specialization vs flexibility.

I hope I convinced you that it is important to have a little bit of both.

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 if you feel flexibility is not relevant – 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 how to deal with this challenge or any thoughts about my suggestions, feel free to comment here and let me know.

Author: Yuval Yeret

Kanban/Agile Consultant at Agilesparks

Leave a Reply

Your email address will not be published. Required fields are marked *