The Role of Agile Delivery — Cross Team Delivery in BBC Sounds

10 min readJun 25, 2021

This is the second part of a talk I did for Agile Roundabout in March 2021. You can read the first part on the role and responsibilities of the agile delivery discipline or watch the full video on YouTube.

Background — BBC Sounds

BBC Sounds is a live and on-demand audio service from the BBC that includes live radio, audio on demand content, music and podcasts.

BBC Sounds is available on a huge number of devices and platforms and to maintain consistency it follows an API first development strategy keeping most of the logic and layout in the API. This approach is really effective in reducing efforts in the client (platform) teams however it introduces dependencies to end to end feature delivery. This is what this case is about.(disclaimer: I left the BBC in June 2021)

The Challenge of Cross Team Delivery

The Problem

Without having a successful way to effectively work and collaborate across teams, this set up with its inevitable dependencies can cause some real headaches when it comes to product delivery.

The story starts in 2019 when we noticed a pattern in retro feedback across different teams describing issues with dependencies. Here are some quotes to give you an idea of the challenged teams faced;

“Our OKRs, from which we came up with tactics, did not align with the OKRs of teams we would be dependent on.”
“Once dependencies have been identified we sometimes shelve the work because it takes more than a quarter to drive that work through other teams.”
“Our Dev and test team members need to be involved when other teams shape their requirements — we need to mitigate the feasibility risks.”

Sounds painful! But what do they mean?

To validate the qualitative feedback we looked at data. We analysed a few cross team initiatives (initiatives where more than one teams’ contribution is needed to deliver value to users) and compared the Initiatives’ overall lead time (from commitment to release) to the individual teams’ discovery and build time of said Initiative. Still with me? Then this is what we saw;

Hmmm. This seems like something isn’t quite right. Why is the overall lead time so much higher than the longest team lead time? Let’s visualise the work on a roadmap view so see what is going on here.

Based on these views we made the following conclusions:

Priorities (or scheduling) within the different teams are not aligned
Work is happening consecutively not concurrently
As no user value is released until the last team is done this results in a long lead time for the Initiative overall

There is definitely an opportunity here to improve speed of delivery, but there is something else going wrong here as well.

If you scroll back up observe the discovery time for ‘Team1’ seemingly creating the upfront scope which is then “handed over” to other teams where discovery time is non-existent. While long lead time is a problem on its own, I was also alarmed by the appearance of a siloed scope upfront approach. This approach combined with the unaligned build times increases the risk of rework and undesirable technical an/or product compromises.

To explain why let’s see what what happens if something doesn’t go according to plan:

Let’s imagine the above case where Team 2 picks up the work and quickly reports something like:

The analytic logic in the API doesn’t work on the new mobile OS that was released recently
The UI design and business logic isn’t working on the smaller mobile screens
Low spec smart TVs can’t support the brand animation agreed
The smart speakers market moved on and user expectations changed

The likelihood of any these is high. so no one is really surprised but the impact of such things is significant. If any of the above happens we are faced with the following issues:

As Team 1 is done with their contribution and moved on to other high priority work that would need to be paused to remedy Team 2’s issue.
Team 3 is in advanced build and would have to go back and rework what they have already done delaying their roadmap and all following work.
The designers and product people have mentally moved on as the scope was created weeks ago. They need time to get back into context and amend the original approach — do we pause all their current work until that happens?

None of the above is desirable and they cause delays in not just this initiative but in all upcoming ones, leaving roadmaps messed up, and everyone — including stakeholders — frustrated.

Familiar? Then you can guess what happens…

To limit the (short term) impact we most likely decide to rush a scope change through in Team 2 leaving our technical estate suboptimal or the user experience misaligned. We spend some time looking for someone to blame for the chaos and our wasted efforts. Then we move on and dread the next time we have to work on something that is dependent on other teams.

As working across teams to deliver ambitious and complex cross team initiatives was slow, frustrating and resulting in not always great results, people tried to avoid embarking on big Sounds-wide Initiatives when possible. We only did if it was really necessary. The problem is that most bold, big ticket items tend to need more than one teams’ contribution.

The Solution

Without having a successful way to effectively work and collaborate across teams, delivering ambitious product-wide changes can be a real headache.

To find a solution the Delivery Team started with asking the question — What if we could change our approach and attitude towards working together?

What if we talk about cross team collaboration instead of cross team dependencies?

This mental shift seems small but it could allow us to align priorities and scheduling better and as a result reduce lead time. Closer working could also help in situations when something goes wrong or we are faced with a need to pivot due to market changes (did someone say agility?). Reacting to change could happened quickly if we collectively amend our approach.

This would look something like this:

When teams work together good things happen.

So what did Delivery do?

We spent a long time finding ways to make working across teams and across disciplines easier. We have done this by bringing disciplines closer together by introducing ‘quads’, creating a shared delivery life-cycle that teams could for routines around, and improving cross team communication by using visual roadmaps and a shared language. Easy!

Introducing Quads

When we work across teams in BBC Sounds each cross team initiative is supported by a cross discipline ‘quad’. The Quad should have members from different teams working on the Initiative, and at a minimum include product, engineering, delivery and UX with Architecture and Test being added as and when needed.

That is 4 people from different disciplines and teams whose role is to:

help communication and coordination across our teams
gather different perspectives
create a shared understanding of what we’re trying to do
work with teams to define the approach
ensure efficient decision making

The quad ensures that teams work together towards shared goals.

Quad — a cross discipline group helping teams deliver

Have a Shared Ways of Working

For Initiatives that are shared by multiple teams we introduced some improvements to our ways of working supporting effective delivery and alignment.

Teams need to know what to expect from each other and have a predictable set of routines to work effectively together.

To achieve this Sounds follow a shared delivery lifecycle for cross team (or as we called it Shared) initiatives that roughly looks like this:

First we set up a Quad who will be overseeing the cross team efforts and ensure alignment.
Then in Exploration we validate that the idea is worth spending effort on and will have the most impact. This is a collaborative process to help making the early parts of delivery and new incoming ideas visible.
If we commit to the idea based on the Exploration outcome, we get all teams together in a Kick off. This forum helps everyone involved to agree on what we are trying to achieve and how we will get there.
Cross team Initiatives rely on collaborative and transparent Discovery where across teams and across disciplines we discover the steps we will take to make the idea reality (more on this later).
Once the direction is identified we break it down to discrete units of work and thin slices together. This is specially important to aid short feedback loops and mitigate the risk cross team rework.
Once the fist slice is identified we do what we do best — Build it by creating releaseable chunks of well tested and engineered code that meet the requirements at hand whilst remaining extensible.
Finally we release slice-by-slice and measure impact to validate direction. Based on feedback we start thinking about the next iteration.

While the diagram seems linear, it is not a linear process by any means. We continually revisit and refine each step as we learn more and as needed.

The Roadmap

Having a shared language and a predictable way of working together is great. We now have a shared understanding on how we get work done from idea to release so working together and easy and predictable. But but we still need something to help minimise coordination costs and lower the need for constant cross team communication…At the end of the day when 4 teams are working together that is at least 40 people!

To help with communication and transparency this we use a highly effective and amazingly powerful visual communication tool — a simple roadmap.

Team Roadmaps:

Are owned by the teams and are for the teams to help with their planning efforts and communicate their intent.
Help teams align when needed by visualising each teams’ contribution to Sounds’ Initiatives and goals.
Creates transparency and allow everyone (team members, upstream teams, stakeholders and other departments) to understand what is happening at a glance.
Help us having better conversations around misalignment, priority changes, effort allocation and WIP when we catch up around it, which happens regularly

The Outcome

So what did all these changes achieve? Let’s revisit the graph a year later — they paint a very different picture.

More alignment around priorities

After introducing the above changes, the overall lead time in 2020 was essentially the longest team contribution time. This signals concurrent working over consequent working. Yay!

This was made possible by clarifying priorities so teams can align on what is important and thinking about working together instead of working with dependencies.

More visible discovery

Do you remember the long discovery time in blue for ‘Team1’ essentially creating the upfront scope to be “handed over” to other teams where discovery time is minimal? In 2019 teams spend very little on discovery and we can mostly see build effort. In 2020 however, discovery time grew exponentially across the teams. Does this mean we got slower in discovery?! Not quite.

As we introduced a shared lifecycle, quads ensuring cross discipline working, and better kick-offs involving everyone early, the discovery effort moved inside the teams rather than happening somewhere else, in a black box. This is the effort that now teams report on — discovery is happening with the right people involved and within the teams.

Discovery is exposed and is done together within the teams and team members involved rather than somewhere “else” in a black box.
Giving UX and product the tools break work down and build propositions working together with other disciplines.
Introducing better kick-offs to ensure everyone is starting from the same space and teams are working together to create a solution that works best for all.
Helping making decisions effectively together while considering multiple perspectives.

*Teams working together to discover the solution*

Down to Earth Reality

All this is great and all. But what does it mean?

What we really achieved by bringing all this together is a built up confidence when it comes to cross team working. But that means as lot. Why?

As I said big ticket items tend to involve multiple teams. By introducing these changes we are now less hesitant on taking on those big challenges so we are taking bold steps more regularly.

With these improvements working across teams became OK. And when working across teams is OK, you do it more often.

When working across teams is OK you do it more often.

In 2020 with these changes implemented BBS Sounds we have launched:

Sounds International — an app that is now used all around the world
Hero Promo for big events and special content on all platforms
The rethinking of our our Information Architecture with a new Music and Podcasts space within the product
And a new brand extension of Radio One called Radio One Dance

Alongside all other amazing work that teams do “independently” — for example launching BBC Sounds on smart TVs, or completely rethinking the schedule pages on the website. And all this during the pandemic!