**UPDATE** The Agile Team Onion is now the Team Onion, same model, slightly new name.
I’ve recently been playing with ways of explaining the extended Agile team for large and largeish organisations. I get frustration 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 to just throw everyone in together as it’s not always that practical and can cause communication issues as the team gets really big. I’ve been using the Agile 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 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 no dependence.
Which 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 what other functions that teams interact with and what dependencies do to a project – they mean you can’t deliver anything>
In large organisations, we have lots of other functions and people around the core Agile team that are involved in delivery.
There are 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 the wider team and inviting them into the team; while keeping the core team to an effective size.This isn’t just a stakeholder map, it is about bringing the organisation in and having 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, 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.
**UPDATE** you can now download a free ebook about the Team Onion here