The Team Onion now has a new home at teamonion.works
**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.
<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.
14 May 2016 at 12:14 pm
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 !
15 May 2016 at 4:58 pm
Love this from @ewebber –> The Agile Team Onion. https://t.co/i5cQSLVWbS https://t.co/XRh74a1qdE
7 June 2016 at 6:57 pm
Nice description Emily. I’ve never been sold on the pizza concept; they’d have to be bloody big pizzas!
5 November 2016 at 1:42 pm
The Agile Team Onion. How many pizzas does it really take to feed your team? via @EWebber https://t.co/Og9abk7zuS https://t.co/0xAYkTzUul
7 November 2016 at 8:25 pm
RT @lithespeed: The Agile Team Onion. How many pizzas does it really take to feed your team? via @EWebber https://t.co/Og9abk7zuS https://t…
22 March 2017 at 11:06 am
The Agile Team Onion. How many pizzas does it really take to feed your team? https://t.co/TWC7lHxQab via @ewebber
27 February 2018 at 5:53 pm
Most agile teams don’t operate in a bubble of no dependencies, but we often act like they do https://t.co/eGc5WvBpgC by @ewebber
1 August 2018 at 10:56 am
@JanetHughes @educationgovuk I’d always include something about the team and how they work as part of discovery, as… https://t.co/ELRIKOUB2g
7 July 2021 at 12:41 am
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.
7 July 2021 at 11:20 am
Ah cool, I will take a look, thanks.