One of my favourite examples of an approach to scaling agile structures is detailed in this paper by Henrik Kniberg and Anders Ivarsson talking about Spotify's model of Tribes, Squads, Chapters and Guilds (in fact the guys at Undercurrent, whom I talk to below, link to it from their site). Spotify has scaled more rapidly than most businesses but this structure is specifically designed to maintain an admirable level of agility across 30 teams and 3 cities.
The basic unit of development at Spotify is the 'Squad', a small, nimble, multi-discplinary, automous self-organising team that is designed to feel like a mini-startup. Squads are co-located and focus on specific areas of the product or service, incorporating all the tools and skills they need to take an idea from design to test to release and production. Much like Amazon's Two-Pizza teams, Squads are clearly focused on a specific task and KPI.
Squads are grouped together into related product areas called 'Tribes'. Tribes are like the incubator for the squad mini-startups and designed to be no larger than 100 people. Specific processes help minimise the potential of dependencies to slow things down.
'Chapters' and 'Guilds' link Squads horizontally together, enabling some economies of scale without sacrificing autonomy, and acting like the glue that binds the company together. Chapters group together people with similar functional expertise and meet regularly to share learnings. The chapter lead is the line manager for chapter members and has more traditional man-management responsibilities, but is also a member of a Squad themselves so stays in touch with reality.
'Guilds' are looser, more organic and wide-reaching communities of interest that can stretch across the whole company (rather than just a Tribe like a Chapter does). They enable knowledge and tool sharing across a wider group.
As the paper describes it, it's like a matrix organisation but one that is weighted toward delivery. Rather than people being grouped into vertical silos defined by function, the vertical dimension is defined by those multi-disciplinary, self-organising, co-located Squads, and the horizontal dimension is all about sharing knowledge, learning and tools.
The danger of looser structures focused around small, nimble teams is the potential complexities created by dependenies, co-ordination issues, a possible lack of focus on developing vertical functional expertise, and the difficulty in effectively sharing learning horizontally across the organisation. What I really like about this is that it specifically finds ways to avoid those potential pitfalls and makes for a far more flexible structure and one that can be more adaptive at scale.
Leave a Reply