The Agile Team Onion

I really liked Emily Webber's thoughts about Agile team onions. I've talked a lot over the past few years about the power of small multi-disciplinary teams to drive big change, and retain agility as you scale – and concepts like Amazon's two-pizza teams.

Although as this piece adeptly describes, the point of two pizza teams isn't only about their size – it's about accountability and autonomy. Each one of those small teams has (or at least had) a 'fitness function', a key business metric agreed between the senior leadership and the team lead that is the teams' focus and accountability:

'Once approved, the team is then free to execute relatively autonomously to maximize its fitness function—to pursue creative strategies and to set its own internal priorities'.

This autonomy enables greater entrepreneurialism, the opportunity for greater ownership and growth. Amazon had effectively taken a divisional organisational structure to it's extreme.

Anyways, Emily's post talks about the composition of such a team or unit in terms of having all the roles needed in order to design, build and operate a service (like a product owner, scrum master, designers, developers etc – my own version of this is a combination of business, technology and creatively focused roles). But in a large organisation there will inevitably be some level of dependencies – other functions (perhaps ops, legal, finance etc) around the core team that are involved in some way in delivery but which are situated in silos. So the onion is, says Emily, a way of creating understanding about who is in the wider team, and inviting them in without disrupting the small (and effective) size of the core team:

'This isn’t just a stakeholder map, it is about bringing the organisation in and having shared responsibility for what you are creating together.'

Worth reading the whole thing, but she classifies it thus:

Core team:

• 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

Collaborators (who 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

Supporters

• 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

Although the numbers may be slightly different Emily suggests that it may be useful to relate this to Dunbar's number of group size (5 confidents, 15 core support group, 50 close friends, upto 200 others). Mapping out your team onion, inviting people in, agreeing expectations and protocols establishes the right footing for it all to work. So ultimately, an organisation may consist of many overlapping onions.

There's lots to like about this. It enables autonomy whilst acknowledging and providing a structure for dependencies. Nicely done.