6 things to consider when scaling agile teams

To put the record straight up-front, there are definitely more than 6 things to consider when scaling your agile teams. These are just 6 things to think about which, from experience, I’ve seen to be important and people miss.

Photo by Austin Distel on Unsplash

Using a scaled agile framework is always a good conversation starting point, but a scaled framework is not a silver bullet that maps cleanly to your organisation and current teams. Don’t forget to lose the things you’re currently doing, which a framework may make you do!

Scaling your teams should be personal to your organisation as there are people implications here to work through, which should always be front of mind when working through an exercise such as adding more teams or breaking apart existing teams.

Are people going to feel less empowered if they now have different accountabilities or their mission changes?

Are they going to feel less empowered if they get put in a different domain without consultation?

Are you clear on the reasons why you’re scaling (most commonly because of an increase in throughput needed or an overarching org growth strategy), and have you communicated this to everyone involved?

But anyway, on the assumption you’ve thought about the above and you’re now clear on why you’re scaling your teams; here are 6 things to consider to keep your agile teams agile:

1. Organise around value streams

• Firstly (if not done already) map out your current user journeys to understand where you gauge value from your customers; this will also help your analytics strategy!
• Create teams across this flow of initial customer touchpoints through to realisation of value by the customer.
• This exercise will also help to asses how much capacity you should put in each team, and which areas you want to create consistency across channels, products, etc to retain more centralised functions vs localised functions.

2. Consider the topology of your teams

• Agile teams have brought with them an emphasis on cross-functional teams as king — and they still are when scaling agile teams. However more often than not, one of the main reasons you’ve started to scale and create alignment wrappers is that there is more work to be done than is sufficient by a single accountable team. So rather than asking yourself ‘how do we carve this up the team?’ think about ‘how can we make teams deliver faster?’
• For this second question consider also creating ‘enabling’ teams whose mission it is to allow your cross-functional teams to deliver more efficiently, e.g. Platform teams creating more flexible and modern integrations to back-end platforms, or Cloud teams creating better ways to spin up environments or improving the CI/CD process.
• N.B. in these examples Platform and DevOps skills should also sit within cross-functional teams to allow the team to deliver features and outcomes autonomously.

3. Have a strategy for communication

• One of the biggest challenges for working in a scaled way is making sure things remain transparent, aligned and information is shared effectively; it shouldn’t feel like conversations and decisions are made in siloes.
• Therefore as well as drawing up what teams are going to be working on, and who is going to be within each team, draw up how and when you are going to communicate across teams (e.g. in tools, and forums).
• Take yourself through a working example of delivering a feature, or how multiple teams work through a Discovery to get to working software in Live; how are the teams going to be interacting? What needs to be shared, and when? How are key information points and decisions shared in a consistent way?

4. Consistently prioritise across all teams to keep autonomy AND create alignment

• A key factor of agile (and product-led) teams is that they are autonomous to decide what they work toward; which is something which we still want to retain when working in a scaled way. But now with multiple teams, we also want to ensure there is high alignment to common organisational goals.
• People think of ‘autonomy and alignment’ as a spectrum, you can either buy one or the other, but this is far from the truth. You want to create teams that are free to choose what they work on and how they work but are aligned to common goals as a business.
• Linked to the communication strategy point above, consider what are the lightweight touchpoints when your Product teams are going to share Goals and Roadmaps with one another; to make sure they aren’t all working toward different end locations which pull the organisation in different directions.

5. Map how you are going to visualise dependencies

• Hopefully, you’ve been skilled enough to carve out autonomous teams who can release code autonomously(!), but the more realistic situation is that you will still have dependencies between teams, e.g. delivering a checkout feature may be worked on by a ‘Buy’ team, but the ‘My Account’ team may also want to show your purchases within your account section.
• For those times when there will be dependencies, have a single place across all teams where dependencies are transparent for everyone to view, but keep teams accountable for managing their own dependencies in this place.
• Honing in on the last comment, having teams accountable for change is really important in your scaled agile transformation. If you have a ‘Command and Control PMO’ managing your dependencies lists, all your vast teams will lose a sense of responsibility for their work and are less inclined to fix those dependencies (and future dependencies) efficiently.
• Make your dependency list visual and easy to read — SAFe (although at times very un-agile — let’s pick this up in a separate article?) does a great job of visualising dependencies across teams in a Program Board. Consider stealing a Program Board approach.

6. Put automation at the heart of operations (and define what activities should not be automated)

• This is particularly helpful in the example of communication. Think about the information you want to push to various people, and allow automation to care of this; there is nothing more time-consuming than, for example, pulling together Roadmaps for 4 teams into a PowerPoint presentation to send out to the rest of the organisation, when an automated tool can do this for you.
• Tools such as Zapier, Make, IFTTT, and Microsoft Power Automate allows you to connect various systems across multiple teams into single places and automatically push information out. Make use of them!
• Likewise within your operating model think about where you don’t want automation, for example, having a bot connect with a stakeholder in the legal team may not be beneficial as you may miss the nuanced requirements that would be picked up on from a face-to-face conversation. Also, you want to provide a personal partnering feel from your Product team, which can’t be underestimated!

So they were just 6 things on my mind. Did I get it right? What is your biggest learning when scaling agile teams, to keep them agile?

Chris Alderson is a Principal Consultant at AND Digital. Chris provides digital expertise and leadership to teams in challenging circumstances, particularly as part of agile and digital transformations. He is a seasoned practitioner with 10+ years hands-on experience across a variety of roles across the full lifecycle of Digital and IT delivery, most recently supporting an AND Digital key client as their Interim Head of Digital. He is always open to chat about Delivery, Agile Transformations, Digital Operating Models and Digital x Business partnering; so reach out to him on LinkedIn or by email.