How to Align Scrum Teams

This content is syndicated from Age of Product by Stefan Wolpers. To view the original post in full, click here.

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.

Agile Transition: How to Align Scrum Teams

How to Align Scrum Teams — Agile Transition
Click To Tweet

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

How to Align Scrum Teams: Alignment Anti-Patterns
Click To Tweet

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.


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

The post How to Align Scrum Teams appeared first on Age of Product.

Leave a Reply

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

3 × four =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”



To explore how we can help you, please get in touch