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 require creating (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.
1. 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.
2. 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-versus-microservice architecture debate.
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 no-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: “Scrum has so many meetings; when am I supposed to finish my work? and “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.
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.
Align Scrum Teams by Moving to Autonomous Feature Teams
In the end, at least in 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, brains, 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.
- If you’re working on a monolith, consider moving to a microservice architecture if that is feasible.