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? When no one thought about how to align scrum teams?

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.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers.

Join more than 120 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.

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 the 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:

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

Cannot see the subscription form?
Please click here

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

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

Related Posts

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

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

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.