Dealing With Agile Team Dependencies

As agile scales across an organisation, how can you manage interdependencies to ensure that you stay moving fast?

neilperkin
Building The Agile Business
3 min readJun 9, 2020

--

When scaling agile working and small multi-functional teams through the organisation we need to remove the barriers that prevent teams from progressing and learning quickly. An important part of this is being ruthless about keeping the team small. But we also need to ensure that teams have the necessary support and input that they require, and that they can access what they need when they need it in order to generate and maintain real momentum.

Agile Team Onions

The model of Agile team onions, originated by Agile practitioner Emily Webber, is a way of structuring dependencies which in a large organisation might include necessary functional inputs (perhaps ops, legal, analytics, compliance, finance etc) that are involved in some way in delivery but which are still situated in vertical silos, around the core team. The onion is 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. As Emily describes it:

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

The onion is classified 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 with 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, senior leaders, wider organisation

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.

In this way, the core team is kept at a suitable size to maintain velocity, collaborators provide necessary inputs to maintain momentum, and supporters remove barriers and provide direction to empower agility.

For more like this, you can order your copy of Building the Agile Business Through Digital Transformation and the new book from Neil Perkin ‘Agile Transformation: Structures, Processes and Mindsets for the Digital Age’. You can also join our community to access exclusive content related to the book.

--

--

neilperkin
Building The Agile Business

Author of ‘Building the Agile Business’, ‘Agile Transformation’ and ‘Agile Marketing’. Founder of Only Dead Fish. Curator of Google Firestarters.