How to overcome friction between multiple agile teams (Part 1)

In this two-part blog series, we will explore two common sources of friction we see in organisations that have multiple agile squads set up. This friction may undermine the benefits of enabling agility across the organisation and requires coaching effort to resolve.

Common causes of friction

1. Agile but siloed teams: Squads of teams aligned around technology abstraction layers that are using agile delivery methods, but are siloed in their approach to end-to-end outcomes

2. Front-end focused product ownership: Individuals in product owner roles tend not to own the end-to-end outcome but focus mainly on design aspects. This is likely due to their skillset and level of comfort working in more technical areas.

This blog will focus on the first of these.

Agile but siloed teams

It is worth noting that in this example, we're not referring to specialised teams providing underlying infrastructure provisioning, framework building, or other enabling aspects. With that in mind, let’s imagine an organisation where several squads within technology have a high level of maturity in agile methods. In this scenario, the squads are executing Scrum and/or Kanban, learning and improving as they work. These teams are organised and delivering within one technology abstraction layer, as often occurs in larger organisations (e.g. business service APIs, or micro front-end components). Each team is individually running in a self-organising, end-to-end manner (including quality assurance activities, and maybe a DevOps approach, alongside the pure development skills). As each is aligned to a particular part of the technology landscape, they also have a clear ‘boundary’ of responsibility, knowledge, and required skills.

The result of this is that each team has a partial ownership of the end-to-end customer journey. As such, multiple teams need to work together for this new customer journey to be delivered.

What happens when there are multiple agile teams?

You will likely see 'polite dependency trading' coupled with a 'gentle ongoing tap-dance' for which team owns the whole solution design. In short, they become agile teams bound together by waterfall-style activities - passing requirements with 'will be done by' dates between each other.

Any additional skillset-based teams that are also working semi-independently, such as UX Design or a third-party vendor's back-end, compounds the problem. Perhaps the API team is expected to speak to the vendor to understand the back-end. They do so, and pass their findings, ideas, and options on to the front-end team, who provide comments such as, "Well, that's not what the UX Design team have specified to us."

Working time, and more importantly, elapsed time, is wasted as the polite arguments pass back and forth without clear direction and facilitation of decision making.

A tried and tested solution

On the face of it, the solution is straight forward: introduce a co-ordination individual who facilitates the conversations between the teams and helps the Product Owner drive for thinly sliced code demos. Usually, Scrum Masters are expected to perform the role of guiding, coaching, and facilitating good agile ways of working, including collaboration. Indeed, the Scrum Master role works very well where the Product Owner sits with one (or maybe two) squads, each owning a feature set end-to-end.

However, in the larger organisation example given above, a rarer individual is needed - at least until the teams mature their ways of working to become habitually collaborative. This person needs to be motivated by coaching and should focus on turning teams away from "nose-to-nose dependency arguments" towards "shoulder-to-shoulder solution sessions."

What does this person look like?

This person may well already be in your organisation. Typically, they are the glue between teams, often ‘on the side of their desk’ rather than formally as part of their role. They have a good understanding of a range of technical concepts and a business understanding of customer value.

They will need to become adept at working between different teams; be good listeners whilst actively facilitating conversations, allowing conflict or blockers to be surfaced; and, critically, movers that are able to ensure decisions are made.

They will either be skilled, or require coaching, in building bridges between different parts of the organisation. It is essential they learn to do this in a way that avoids blame and puts outcomes and the organisation’s value to customers first.

They look at conflict as an opportunity to help teams engage and resolve issues into solutions. They will increase their facilitation skills in running cross-team problem solving sessions; listening, advising, and conversing at all levels of the organisation.

Achieving the above is not likely to occur instantly and individuals need to grow into such a role in parallel with active coaching of key members of the teams. Specific and targeted training will complement, but not replace, on the job coaching and feedback. In many organisations this required approach is not recognised nor a specific role. We’ve found that external support is required to help the organisation and individuals mature these roles.

In a nutshell

Consider identifying a resource in your organisation that fulfil a range of co-operative behaviours and who can grow into such a role. Work out how to use them most effectively to ease the friction points. Are there organisational blockers that need working through in parallel? Reach out to us here at Credera for more ideas!