How to Align Scrum Teams

Published in

The Startup

6 min readJan 29, 2017

TL;DR: How to Align Scrum Teams

Do you remember the good old days when the organization started with its first Scrum team? And the new engineering kid on the block was “merely” supposed to deliver a potentially shippable product increment at the end of a sprint?

The first team was to sound the bell for the upcoming change towards a learning organization. Little did we know back then about the challenges along that route. When teams 2, 3 and 4 joined, shipping a product increment at the end of a sprint became first complicated, and then complex.

It turns out that becoming agile does not only required to create (Scrum) teams. Reaping the full benefits of becoming agile, of becoming a learning organization built around software also requires changing engineering practices. Nowadays, it is all about continuous value delivery.

Why it Is Beneficial to Align Scrum Teams

There are two levels of alignment that a product delivery organization needs to address when scaling Scrum:

Alignment at Product and Process Level:

Which team builds what? The alignment at product level is required to avoid delivery optimization at the individual team level. This form of local optimization is a familiar pattern with component teams, as they are specializing in a particular technical area.

Working in this field of expertise, however, may not always deliver the most value to customers or the organization at a given moment. A task from another team that this team cannot attend to might be much more valuable by comparison.

Alignment at Technical Level:

This level is addressing engineering practices such as continuous integration as well as continuous delivery. It is also relevant concerning the software architecture. In most cases, it is the monolith v. micro-service architecture debate. (Read more: REST in Peace: Microservices vs monoliths in real-life examples.)

Signs That Your Efforts to Align Scrum Teams Are Failing

If the experiment with the first Scrum team proves successful, organizations will often start creating more Scrum teams.

No matter your engineering practices, you will quickly discover that the communication overhead will grow by comparison exponentially. This overhead growth is particularly visible to organizations that create component teams and that are working on a monolithic application.

Though the need for better communication among the Scrum teams is a low-brainer to everyone, it is interesting to observe the communication inertia between teams — even if located next to each other.

Some of the typically resulting alignment anti-patterns at the beginning are:

‘They’ — meaning another Scrum team — touched ‘our code.’ (Without approval from us: a perceived on even encouraged code ownership at the team level.)
Deployments by individual Scrum teams happen without prior communication to the other teams, thus breaking things. (‘Was working on our staging system’ syndrome.)
There is no regular sharing of knowledge among teams, for example, training colleagues on new code if not ordered by the management.
Scrum of Scrums meetings are not attended. (Common excuses: a) “Scrum has so many meetings, when am I supposed to finish my work?” and b) “Our issues are not affecting any other Scrum team.”)

The Necessity to Improve Inter-Team Communication

The cause for the resulting communication overhead is dependencies between teams resulting in creating queues, waste and, thus, costs of delay.

To reduce the number of dependencies between Scrum teams, they need to be autonomous. However, autonomy without accountability equals anarchy. The process of aligning Scrum teams, therefore, needs to start at the organization’s cultural level.

Improving the culture cannot be ordered by edict from the C-level. It needs to be a journey that includes everyone affected. If Scrum teams are to move out of their comfort zones and accept accountability, failure must be a safe experience, and radical transparency needs to be embraced.

The cultural change which is required to align Scrum teams at the process level is ideally backed by a simultaneous transition to an anti-fragile or resilient system architecture.

Technical failure — no matter the effort invested upfront — will be inevitable during this change process. The effective way to deal with failure at a system level is, therefore, not to focus on preventing it from happening at all. The effective way is to create a fault-tolerant environment that excels at rolling back hazardous deploys. (More on high-performing teams in agile organizations from Jez Humble: GOTO 2015 • Why Scaling Agile Doesn’t Work.)

Please hit the “heart button” 💚 below, if you found this post useful–it would mean a lot to me!

If you prefer a notification by email, please sign-up for my weekly newsletter and join 6,369 peers…

First Improvised Steps to Align Scrum Teams

Changing engineering processes as well as probably the architecture of an application will take time. There are some preliminary steps, though, to start the alignment process immediately:

First of all, avoid individual sprint lengths, and start-dates, but align the sprints of all teams instead.
Establish a ‘Scrum of Scrums’ ceremony, as well as a dependency board. (Both measures are temporary training wheels on the way to fully autonomous and aligned Scrum teams.)
Apply the LGTM (‘looks good to me’) process before releases: This sounds like bureaucracy but is unavoidable if otherwise disaster is lurking around the corner. (Interesting question on the side: Will the Scrum teams address this issue themselves, or wait for management to ‘solve’ it?)
Establish a peer teaching and coaching program. A simple pair programming board — who wants to learn what from whom — can be a good start.
Track technical debt with a repository of issues that need to be fixed, shared and maintained by all Scrum teams.

Agile Transition — A Manual from the Trenches

The latest, 94 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches” is available right here, and it is FREE!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly ‘Food for Agile Thought’ newsletter if you aren’t already subscribed. You may of course unsubscribe at any time.

Ultimately, Align Scrum Teams by Moving to Autonomous Feature Teams

In the end, at least this is my opinion, aligning Scrum teams will only work based on autonomous feature teams. Any other set-up will create too many dependencies, thus wasting money, brain, and time. It will also prevent the organization from becoming a learning one.

If you cannot move to features teams yet, here are some observations that might ease the transition:

Continuous integration is a prerequisite for feature teams. This process needs to work flawlessly
You build it, ship it, and run it: Everyone on a feature team needs to do “QA,” avoid siloing quality assurance or delegating it to an individual team member
If you continue using feature branches, make tasks as small as possible and try to merge all branches back to master in the evening. This practice will provide everyone with instant feedback, and fixes will be less expensive (and painful)
Start measuring lead and cycle time to identify queues. (Read more: Agile Transition: Agile Metrics — the Good, the Bad, and the Ugly.)
If you’re working on a monolith, consider moving to a micro-service architecture if that is feasible.

Conclusion

How do you align Scrum teams? Please share your experience in the comments.

How to Kick-off Your Agile Transition (Part 1)

The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders

Please hit the “heart button” 💚 below, if you found this post useful–it would mean a lot to me!

Do you want to read more like this? Well:

📰 Join 6,369 peers and sign-up for this weekly newsletter
🐦 Follow me on Twitter and subscribe to my blog Age of Product
💬 Or, join my brand new Slack team “Hands-on Agile” for free…