How to Align Scrum Teams

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 by 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.)

Agile Transition – A Manual from the Trenches

The latest, 212 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.

That went well! Please check your email to confirm your subscription to our weekly “Food for Agile Thought” newsletter and download your free ebook 'Agile Transition – A Hands-on Manual from the Trenches'! NOTE: If you do not receive the confirmation email within about 10 seconds, please also check the spam folder. Thank you!

There was an error submitting your subscription. Please try again.

First Name

Email Address

We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.

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.

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)

Related Posts

Receive a professionally curated summary of the best posts on the Internet about Agile, Lean Methodologies, and Product Management — delivered to your inbox every Sunday.

We've received your request — you're almost subscribed! Please check your email to confirm your subscription. We look forward to sharing the best Agile and Product news and insights with you! NOTE: If you do not receive the confirmation email within about 10 seconds, please also check the spam folder. Thank you!

There was an error submitting your subscription. Please try again.

Name

Email address

We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.

Published by

Stefan Wolpers

Stefan — based in Berlin, Germany — has been working for 12+ years as agile coach, ScrumMaster and Product Owner. He is an XSCALE Alliance XBA Coach (XBAC) as well as a member of Scrum Alliance (CSP, CSPO, CSM). He is also a certified LeSS practitioner (CLP). He has developed B2C as well as B2B software, mainly for startups, including a former Google subsidiary.

One thought on “How to Align Scrum Teams”

Very interesting article! Having parallel teams refactoring towards microservices in the transition from a monolithic system to feature teams is a technique working well in practice, provided that there is enough experience available! Through such a setup, a common reusable architectural platform can be created and knowledge successfully shared across feature teams in scrum of scrum meetings. Chapters also help spreading knowledge in different areas of interest, an important one being architectural patterns and practices that can be used by all feature teams.