the team onion - tacitlondon.com · agile transformation efforts often mean bringing new people and...

THE TEAM ONION A model for collaborating beyond the agile teamEmily WebberVersion 1.3

First published in the UK in July 2016 as “The Agile Team Onion”

© 2016 Emily Webber

Published by Tacit London Ltd.

All rights reserved. No part of this publication may be reproduced, sorted in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without the prior permission of the copyright owner and the publisher of this book.

Share this book If you enjoyed this free book, please help Emily by sharing with others on social networks using the tag #teamonion and tweet her at @ewebber to let her know.

If someone you know wants a copy, please ask them to sign up for their own copy at tacit.pub/teamonion

Version numberThis is version 1.3 of the book

To see the latest version of the book, please go to tacit.pub/teamonion

-o0o-

For more reading from Emily Webber and Tacit, please see

Building Successful Communities of Practice at tacit.pub/tacitbooks

4The Team Onion | Emily Webber

ContentsShare this book 3

Version number 3

Introduction 5

Team size and the two pizza rule 6

The multidisciplinary Agile team and organisational silos 9

The Agile Team Onion model 11

Creating your Agile Team Onion (a workshop) 16

When should you create your team onion? 16

The collaborators workshop 17

Who should you invite? 17

Bringing collaborators into the team 19

Conclusion 21

References 22


IntroductionI work with large organisations who are adopting Agile ways of working, many of them are experiencing the pain of change. A new way of working throws everything up in the air, processes, procedures and ways of interacting are all changing and becoming unfamiliar. This can lead to confusion and resistance to working in “the new way”.

Agile Transformation efforts often mean bringing new people and teams with Agile skills into the organisation. Although the goal here is to help transform the organisation, too often the new teams sit in silos. This leaves everyone else out, causing friction and communication issues, which in turn makes it harder to get anything done.

One of the fundamental principles of Agile is delivering value early and often. But when communication breaks down between Agile teams and other crucial parts of the organisation, nothing is delivered early, leaving people wondering why they are using Agile at all.

This is where the Team Onion comes in. It is a mental model that helps Agile teams work within large organisations, particularly where some of it is not practicing Agile. It is not a stakeholder map and shouldn’t replace one, but rather sit beside it as an extended Agile team map. It is a tool that helps to: bring the right people together; foster good communication and collaboration; build trust, and create shared ownership and responsibility for success.

Agile teams that use the model will find that delivering value gets easier, as they build their extended team. Those outside of the core Agile team will have the opportunity to get involved and add real value when it’s most needed.


Team size and the two pizza ruleIn Agile we often refer to the two-pizza team, this phrase derives from Jeff Bezos (former Amazon CEO) who famously talks about the two pizza rule as a solution for the problem of meetings that are too big and non-productive.

The rule is that you should:

“never have a meeting where two pizzas couldn’t feed the entire group.” [1]

As well as this, the Scrum guide – which is the guide to one of the most ubiquitous Agile frameworks – says that teams should be no fewer than three and no greater than nine people.

“Fewer than three Development Team members decrease interaction and results in smaller productivity gains ... Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.” [2]

Both Bezos and the Scrum guide recommend that team size remains small so that it can function well. A small team can communicate more easily than a large one and are quicker at solving problems, they reduce the possibility of in-team silos forming and encourage the exchange of skills.

The issue of large teams is not in the amount of people in the team, but the amount of links between those people. J. Richard Hackman, Edgar Pierce Professor of Social and Organisational Psychology at Harvard University says:

“as a team gets bigger, the number of links that need to be managed among members goes up at an accelerating, almost exponential rate. It’s managing the links between members that gets teams into trouble.” [3]


Links between team membersIt’s those links that we should look at if we want to consider the impact of the team size. As an example, if there are two people in a team, then there is one link:

Person A to person B

If we add another person, a total three people, then there are three links between them:

Person A to person B Person A to person C Person B to person C

For four people, this becomes six links.

Person A to person B Person A to person C Person A to person D Person B to person C Person B to person D Person C to person D

Links between people in teams

The number of links can be calculated using the formula n(n-1)/2, these links become more difficult to manage the larger the team gets

This theory of team size is closely related to Robin Dunbar’s work on human group sizes, Dunbar’s number is well cited [4] as saying that we can only have around 150 friends in a group. It also breaks down further than that into types of friends, which are inner core (5), best friends (15), good friends (50) and friends (150).


Dunbar says:

“each layer is three times bigger than the other; so you have an inner, inner core of intimate friends and relations, of about five, and then there’s the next layer out, it’s about 15. If you like to think of those as best friends, perhaps, they’re the people you might do most of your social Saturday evening barbeques with, and that of course, includes the five inside. And then this next layer out is 50 (you might think of those as good friends), and the 150, your friends.” [5]

Dunbar’s number representation

I’ll reference Dunbar’s number a little later on when I talk about the Team Onion model.


The multidisciplinary Agile team and organisational silosAn Agile team is a multidisciplinary team, that is a team that has all the skills and experience that it needs to design, build and operate a service. This can include developers, designers, researchers, an Agile team lead (also known as a delivery manager or scrum master), a product lead (also known as a product owner or product manager), as well as any other roles needed. The multidisciplinary team can deliver value quickly, without dependencies external to the team.

In the Agile Manifesto [6] , which sets out the basis of Agile, there is a principle that speaks about teams in organisations, this is:

“Business people and developers must work together daily throughout the project”

Agile teams need to be integrated into the wider organisation so that they can deliver the most value and align with any overarching goals of that organisation. In small organisations where teams have easy access to most people they need to talk to, it is mostly managed through the product lead. They have the role of coordinating user and stakeholder needs. But where services are more complex and the organisation more distributed there needs to be more effort made to ensure collaboration between team members and other parts of the organisation.

In large organisations, every role needed to design, build and maintain a service could mean adding an extra 20 people to the team. As we have already learnt, large teams are not a good solution.

I’ve seen many organisations respond to this by shielding the Agile team from the rest of the organisation. Or, they create boards and “authorities” to sign off work and assure that it fits with organisational standards and policies. This can create silos, slow down delivery and worse lead to blame culture.


Organisational silosI haven’t met anyone from a large organisation that doesn’t recognise that it has silos. You know you have silos when colleagues stop talking about individuals by name and start referring to homogeneous groups. I’ve heard Agile teams say things like “procurement are so difficult” or “marketing make promises without us”. Conversely, those outside the teams might be saying “the Agile team is chaotic” or “we don’t know what’s going on”.

Most of us have used this kind of language before.

Silos cause dependencies, breakdowns in communication and make it painfully slow to get anything delivered. This frustrates everyone involved. Removing these silos can help a team move really quickly.

The problem is, how do we keep the benefits of a small team, whilst reducing organisational silos?

I have been pondering this question and have created the Team Onion as a mental model to help do that.


The Team Onion modelThis model is a way to help retain the benefits that come from teams staying small, whilst connecting with the wider organisation.

The Team Onion helps teams to:

• understand the organisational environment they work within

• increase communication and break down organisational silos

• understand who they need to work with to deliver

• creates a shared responsibility for success

• reduce external delivery dependencies

• bring much needed knowledge into delivery


The Onion Rings

The Team Onion diagram

Each of the onion rings is a different type of team member, each member type has a different purpose, communication frequency, co-location needs and Agile activities.

When you are considering the amount of people in each ring, it’s worth remembering the numbers that Dunbar talks about for inner core, best friends, good friends and friends.

Dunbar’s number and the Team Onion

These could be compared as:

Core: inner core and best friends between 5 and 15 people

Collaborators: best friends, up to 35 additional people (between 15-50)

Supporters = friends, up to 100 additional people (between 50 - 150)


Core teamAt the centre of the onion is the core team. This is the Agile multidisciplinary team as we understand it in most organisations. They need high levels of communication and will work together every day.

Purpose: Delivering a product, service or solution.

Communication frequency: Continuous

Agile activities: All stand-ups, team retrospectives, planning, show and tells and other activities as needed.

Co-located: Daily, all day

Example team members

• Agile team lead (delivery manager / scrum master)

• product lead (product owner / product manager)

• business analyst

• tester

• developer

• user researcher

• content designer

• designer


CollaboratorsThe collaborators are vital to a team’s success, they are where most of the effort in creating your Team Onion will be. Collaborators may be working on more than one team and will also have work outside of the Agile team deliverables. This is an added benefit, it means that their knowledge will reach further than that of the core team and will help with communication between teams and functions.

Purpose: Bring in specialist information to assist delivery, provide assurance as needed, reduce external dependencies and organisational blockers, represent and make decisions when needed.

Communication frequency: Often

Agile activities: Some stand-ups (often as an observer), collaborator specific retrospective, show and tells, planning if needed and other activities as needed.

Co-located: On a regular basis, around two days a week. It will depend on what input they need to give, and may change depending on the stage of delivery


• service manager

• security and risk manager

• legal and policy representatives

• members of other Agile teams working within the same portfolio

• business operations manager

• supplier teams

• subject matter experts


SupportersSupporters are more like project stakeholders. They are not as close to the centre of the Team onion and will have less contact with the core team. They are still a crucial part of the team as they have an important impact on successful delivery.

Purpose: Alignment and reporting to other parts of the organisation, keeping up to date, feeding into broad organisational priorities.

Communication frequency: ad-hoc

Agile activities show and tells (every couple of weeks) and other team meetings as needed.

Co-located: ad-hoc, as needed.


• portfolio managers

• organisation sponsor

• the senior leadership team

• other interested people in the organisation


Creating your Team Onion (a workshop)The Team Onion focuses on the collaborator ring. The assumption here is that you already have a good understanding of who is in your core team and have identified roles and responsibilities within it. If you don’t have that understanding, then you will need a core team roles and responsibilities workshop before creating your Team Onion. The core team workshop should focus on identifying what skills you need in the team and what is missing.

This book doesn’t specifically cover supporters as they should be easier to bring the into the team. Although you can use a similar workshop to the one below to identify who they are, make sure they understand the value of being involved then make sure that they are invited to show and tells.

When should you create your team onion?The team onion workshop is an exercise that you can do at the discovery phase or initial formation of a team. This will help to highlight where external dependencies lie and bring collaborators in from the start to set the team up well for success.

You should revisit your team onion on a regular basis to check that it is still relevant, particularly at different stages of delivery.


The collaborators workshopYou can download a Team Onion template from tacit.pub/teamonion

Who should you invite?The exercise should be undertaken with the core team, as well as any collaborators that you have already identified and are already on board.

The steps for the workshop are:

• introduce the concept of the onion and why it’s important

• identify who the collaborators are

• prioritise the list of collaborators

• agree on the questions for collaborators

• agree who will speak to the top priority collaborators

Introduce the concept of the onion and why it’s importantStart with explaining the concept of the team onion. I often use a game or diagram that shows how work flows (or how it doesn’t) when lots of external dependencies are added. It’s also a good time to introduce the detail of the different member types.

Identify who the collaborators areThis part of the exercise is where the team get involved. Together they should list out all the people or functions that they consider to be collaborators, either now or in the future.

To help the team, it’s useful to ask the question:

“Which people / function outside of the core team can have a big impact on the successful delivery of this product or service”


If you have them, then you should put names against them as well as their role. If you don’t have names, that will be one of the first things you find out after the workshop.

Prioritise the list of collaboratorsNow it’s time to prioritise your collaborators. The team need to agree who they should be engaging with first.

You should decide the right approach to prioritisation between your team. As a guide, in the past I have used:

‘Impact’ — the ability to have the most impact on the team and

‘Ease to engage with’ — how easy the team thinks engaging with them will be.

With this approach, those collaborators with the highest impact and who are the easier to engage with are the highest priority.

Agree on the questions you need to answerNow you have a prioritised list, you can start to agree what questions you need to know the answers to before you talk to the collaborators. This list will be personal to your team, although I have put some starter questions to get you going:

• which person do we need to engage?

• what’s the impact of them not collaborating with us?

• how much of their time do we need?

• what do we need from them / what decisions will they need to make?

• are they empowered to make those decisions?

• do they know that the team exists and its purpose?

• what will they get out of collaborating?

• what training do they need to understand how the team works?

• are they available?

• how will you know it’s working?


Agree who will speak to the top priority collaborators Once you have a prioritised list, you should agree who will be talking to the collaborators at the top of that list. You will often find that someone on the team already has some connection to a collaborator, which makes it easy to identify who should talk to them. Others may require more discussion.

You don’t need to cover off the entire list at this point. Keep it manageable and come back to it when you have started getting the top priority collaborators onto the team.

Bringing collaborators into the teamWhen inviting people into your extended team there are a few important principles:

• face to face communication is best

• be considerate of their challenges and time

• be mindful of any other team onions

Face to face communication is bestFace to face communication is a must when talking to your collaborators if you want to build a trusting relationship with them. The best way to do that is in person. Emails can be misread, particularly if the person you are talking to is unsure of the changes that are happening.

Be considerate of their challenges and timeYour collaborators are generally people that already have a lot of work to do already and are managing multiple priorities. You may have to be flexible about how you work with them. If they don’t have enough time to dedicate to working with you, then you might need to find someone else or make the case to free up their time.


Be mindful of any other team onionsIf you have multiple Agile teams, you may find that you have overlapping team onions and collaborators may be on more than one team. This can be hugely beneficial as it can help with external dependencies and information flow between teams and can create some efficiencies. Although it also means more complexity for those collaborators.

Be aware of other Team Onions that your collaborators are on. You may need some coordination to make sure that collaborators aren’t overloaded and everyone is getting the most out of the team onion model.

Multiple onions may overlap


ConclusionAgile teams need to remain small to get the benefit of close working. In large organisations there is added complexity and the need to explicitly set up communication channels with other parts of the organisation. The Team Onion is a mental model that defines core team, collaborators and supports to help this happen. Using it will create an extended Agile team that has a shared focus on delivering successful products and services.

This short book gives Agile teams the framework you need to start the conversations with the wider organisation and start creating your own Team Onion.


References1. Alan Deutschman (2004). ‘Inside the Mind of Jeff Bezos’; Fast

Company; fastcompany.com/50106/inside-mind-jeff-bezos [Accessed 1st July 2016]

2. ‘The Scrum Guide’: scrumguides.org/scrum-guide.html [Accessed 1st July 2016]

3. Aleks Krotoski (2010). ‘Robin Dunbar: we can only ever have 150 friends at most… ‘: The Guardian; theguardian.com/technology/2010/mar/14/my-bright-idea-robin-dunbar [Accessed 1st July 2016]

4. Social Science Bites (2013). ‘Robin Dunbar on Dunbar Numbers’: Social Science Space socialsciencespace.com/2013/11/robin-dunbar-on-dunbar-numbers [Accessed 1st July 2016]

5. Diane Coutu (2009). ‘Why Teams Don’t Work’: Harvard Business Review; hbr.org/2009/05/why-teams-dont-work [Accessed 1st July 2016]

6. ‘The Agile Manifesto’: agilemanifesto.org The Agile Manifesto [Accessed 1st July 2016]

the team onion - tacitlondon.com · agile transformation efforts often mean bringing new people and...

Documents