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.
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.