The Team Onion. How many pizzas does it really take to feed your team?

Reading Time: 5 minutes

The Team Onion now has a new home at

**UPDATE** The Agile Team Onion is now the Team Onion, same model slightly new name. Because you don’t need to be an agile team to use it.

I’ve recently been playing with ways of explaining the extended team for large and largeish organisations. I get frustrated when I see Agile teams that are essentially siloed off from the wider business (for many reasons). This causes dependency and communication issues and means they just aren’t able to deliver anything very quickly. I don’t think the answer is just to throw everyone in together as it’s not always that practical and can cause its own communication issues as the team gets really big. I’ve been using the team onion to describe a model of how it might work.

I have just put this together into a slide deck for a talk at Agile Manchester, so I thought I’d share some of those slides with a few notes in a more blog-friendly format.

Here it is:


Amazon’s Jeff Bezos talks about a  solution for the problem of meetings that are too big. He calls it the “two pizza rule”: Never have a meeting where two pizzas couldn’t feed the entire group. Agile has adopted this to describe ideal team sizes of  7 +/- 2 people.

Agile frameworks promote multidisciplinary teams in the principle “Business people and developers must work together daily throughout the project”. To explain that a bit more, a multidisciplinary team is one that has all the roles it needs to design, build and operate a service. The team might look a bit like this:


It has a product owner, scrum master, developers, designers etc, that is, whoever you need in order to design, build and operate a service.

And that’s ok, as long as you live in a bubble of where you have no dependencies.


Most of us don’t, yet teams and organisations often act like they do.

Emily at Balanced Team London 2018
Photo by Martina Hodges-Schell

<this is where we did a fun game here to demonstrate how teams often interact with other functions and dependencies, which is not very well – meaning they can’t deliver anything.>

In large organisations, we have lots of other functions and people around the delivery teams.


Which are really lots of bubbles


and these bubbles manifest as silos, and silos are bad. You know you have silos when you hear (and say) this type of thing.


(this language is not good). It means you stop thinking of people as people and start thinking of them as a homogenous group and describing them as such. It makes communication difficult, and work doesn’t flow easily between them.

Enter the…


This onion is a format to help teams to understand who is in their wider team and inviting them in; while keeping the core team to an effective size. This isn’t just a stakeholder map; it is about bringing the right people in and creating a shared responsibility for what you are creating together.

These rings break down as:


Purpose: delivery of digital services
Communication: Daily (all stand-ups, retrospectives, planning, show and tells)
Co-located: daily, all day
Types of people: product owner, scrum master, developers, designers etc


These are the people that might be working on multiple teams

Purpose: bring in specialist information to assist the team, assurance as needed, reduce dependencies and blockers (open doors)
Communication: regularly, they come to some agile meetings
Co-located: on a regular basis (as a guide ~2 days a week) – this also depends on what is needed and the phase of project – but enough to be able to not block anything
Types of people: other delivery teams working within the same portfolio, security liaison, policy liaison, portfolio manager, operations, suppliers etc


Purpose: keep informed, feed into broad organisational priorities
Communication: every sprint/iteration (show and tells, ad-hoc when needed)
Co-located: monthly or as needed
Types of people: steering groups, other teams, the wider organisation

When thinking about It can be useful to relate it to Dunbar’s number of group size:

  • 5 confidants
  • 15 core support group
  • 50 close friends
  • up to 200 others

This is not about having 50 people in every retro

Bringing people into a project will make it easier: See this post from Pete Herlihy on working with legal teams to delivery UK online voting

What can you do with this model?

Map out your team onion, visit it regularly and invite people in. Let them understand why you need them and what the expectations should be (both ways). It might not be easy; you may have to deal with organisational or cultural blockers that create the silos exist in the first place.

Your organisation has lots of teams, so will have lots of these overlapping onions focused on services.


In answer to the question, “How many pizzas do you need to feed your team?”

You might need to start a dominos account.


  1. This is a very nice way to explain how to position for success. Silo’s are the root of all evil in my opinion. A lack of collective responsibility, accountability or stewardship for the business success can certainly lead to silos forming. Often the silo’s only see their sense of success being the things they are “on the hook for”.

    thanks for sharing !

  2. Love this from @ewebber –> The Agile Team Onion.

  3. Nice description Emily. I’ve never been sold on the pizza concept; they’d have to be bloody big pizzas!

  4. The Agile Team Onion. How many pizzas does it really take to feed your team? via @EWebber

  5. RT @lithespeed: The Agile Team Onion. How many pizzas does it really take to feed your team? via @EWebber https://t…

  6. The Agile Team Onion. How many pizzas does it really take to feed your team? via @ewebber

  7. Most agile teams don’t operate in a bubble of no dependencies, but we often act like they do by @ewebber

  8. @JanetHughes @educationgovuk I’d always include something about the team and how they work as part of discovery, as…

  9. I think there is good alignment between the Team Onion and the Management 3.0 Meddlers game. If we glue the Meddlers process for doing the mapping, with this concept, I think we’ve got most of a (dare I say it) new age RACI.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Verifying Mastodon