The team onion — Public Digital

By Emily Webber, agile delivery and organisation consultant.

In a previous role, I was working with an agile team delivering a crucial service. They were talking to users, had a mix of roles, a backlog that responded to change and a delivery rhythm. The problem was that they weren’t able to get anything live. I set about trying to understand why that was.

When I spoke to the team, they stated that it was because they were being blocked by other parts of the organisation. For example, security wouldn’t let them put anything live, and policy wouldn’t turn up to their workshops. When I spoke to the people they were pointing at, they said they didn’t really understand what the team were doing and were busy on other things, so why would they take part? It was no one’s fault, but everyone else’s fault. Classic siloed organisational behaviour.

Small teams

I’m a firm believer that teams need to be small to get anything done. Small teams are able to communicate and collaborate more effectively. Adding more people to a team makes communication a bigger overhead. Decision making becomes slower and the cognitive load of remembering how everyone engages with each other becomes harder.

Teams also need a breadth of experience and knowledge to get the best outcomes. Agile approaches encourage small multidisciplinary teams with all the roles needed to design, build and operate a service, working together to achieve an outcome, delivering value early and often.

This works well when an organisation is small and people play mixed roles, but what about large organisations, where there are whole functions dedicated to activities such as legal, policy and security? All roles needed could mean teams of fifty people or more. Certainly not small.

Early transformations often try to shield teams from existing processes to allow them to move fast. But when an organisation tries to scale up agile delivery and fit it into existing ways of working and decision-making processes, teams start to slow down. Sometimes, the work stalls.

If agile teams cannot deliver early and often then this leaves people wondering why they are using agile at all.

Us and them isn’t good for business

In a perfect world, everyone would be pulling together for a common organisational goal. The challenge comes when teams adopting new ways of working are at odds with the way that others have worked for many years. This puts everyone in a difficult position, they are all trying to do what they think is best, but the approaches clash and this leads to blaming. A siloed culture.

Silos are the antithesis of empathy. They make it hard for ideas and work to flow and can cause people to not share information with each other. When an organisation is trying to get everyone to pull in the same direction, this is far from ideal.

The problem is, how do we keep the benefits of small teams in large organisations, while still being able to deliver?

The team onion, understanding your wider team

One approach I have used with teams is the team onion. It is owned by the team level but needs backing from senior leaders to make it work. It flips the stakeholder map on its head and considers how to collaborate with people as wider team members working for a common outcome. It encourages face to face communication and co-location.

It breaks the team down as follows:

Core

The centre of the onion is the agile multidisciplinary team. They need high levels of communication and will work together every day. It is important that the teams have a mix of people within it and it may make sense to have full-time subject matter experts from the business in the core team.

Collaborators

The collaborators are vital to a team’s success. They bring in important specialist information, assurance as needed and reduce dependencies or blockers. They need regular communication and collaboration with the team and should spend time in the team area to build trust. They will need to understand how the team works and what it is trying to achieve.

Collaborators may be working on more than one team and will also have work outside of the team. This is a benefit, their knowledge will reach further than that of the core team and will help create a network of teams across the organisation.

Supporters

Supporters are more like stakeholders to keep informed, this relationship will help keep alignment with other parts of the organisation and feed into broader organisational priorities. They will have less contact with the core team, but are still a crucial part of it because they have an important impact on successful delivery.

It’s important to invite supporters to show and tells, and meet with them on an ad-hoc basis as needed.

Here are some practical steps to create the team onion

Map out your team into three layers, core team, collaborators and supporters For collaborators ask “Which people outside of the core team can have a big impact on successful delivery?”
Prioritise the collaborator and supporter ring: Who do you need to engage with early on, who has the biggest impact and who is the hardest to engage with.
What do you know about your collaborators and supporters? Do they know what you are doing? Do they understand how you work? How much time do you need? Are they empowered to make decisions? What will the impact be if they do or do not collaborate with you?
Agree who will speak to the top priority collaborators and how often and how you will keep your supporters up to date.
Revisit your team onion on a regular basis to check that it is still relevant, particularly at different stages of delivery.

Small teams networked through trust, communication and collaboration

Organisations are most effective when small teams are working together on a common larger goal, across organisational boundaries. It can be hard, but the only way that is going to happen is by people building trust, communicating and collaborating.