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

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:

agileteamoniontalk.001

agileteamoniontalk.002

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:agileteamoniontalk.004

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

agileteamoniontalk.005

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.

agileteamoniontalk.006

There are lots of bubbles

agileteamoniontalk.007

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

agileteamoniontalk.008

(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…

agileteamoniontalk.009

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:

agileteamoniontalk.010

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

agileteamoniontalk.011

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

agileteamoniontalk.012

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.

agileteamoniontalk.015

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 Agile Team Onion here

5 thoughts on “The Agile Team Onion. How many pizzas does it really take to feed your team?

  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. Nice description Emily. I’ve never been sold on the pizza concept; they’d have to be bloody big pizzas!

Leave a Reply

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