Tonight we had Subha Manohran giving the Midlands Testers Meetup an overview of the Spotify Model of working,
How do Spotify scale their work and follow Agile prinicples to support their 14 millions users?
Henrik Kniberg and Anders Ivarsson published a paper on their Spotify Model in October 2012, inspiring many companies around the world to follow their model.
Squads are small, self-organised development teams, where they develop, own and maintain products and software.
They are made up of a mixture of skills, with a Product Owner, techincal lead, UX designer, a tester and developers. As such they have minimal handoff between teams.
Slogan for the team – “Think it, build it, ship it, tweak it” Keep evolving the work, trying news things, and not being afraid to do this.
To encourage this, 10% of their work time is allocated to supporting hack days to promote innovation within the teams.
They use collaborative working spaces instead of fixed meeting areas, to encourage more ideas and not feel restrictive.
A squad doesn’t have a formally appointed squad lead, with the team deciding between themselves. Often it is a PO due to having a wider view of the work coming through.
Has a “tribe lead” for providing the best habitat for each squad within that team.
The size of the tribes are based on the Dunbar number, which is the principle by Robin Dunbar that a social group can only comfortably maintain 150 relationships. By avoiding larger groups they avoid bureaucracy, office politics, extra layers of management and waste.
Chapters and Guilds
These are the glue that keep the company together.
They allow teams to not lose from economy of scale that comes from all the teams being autonomous.
This is done by grouping people together in a family of similar skills, who are all members of the same tribe.
They meet regularly to discuss their areas of expertise and their specific challenges.
They are more organic, wide-reaching “communities of interest”, which reach across the entire organisation, unlike just a tribe with chapters.
Some people can find it difficult to see the differences between the two. The key differences is Chapters are based on skill, what they CAN do, whereas a Guild is what they are interested in, but may not have the capacity to do.
How is this all working out?
Due to how autonomous the teams are, anyone in theory can edit the system. To mitigate this, they have a System Owner for each of their systems. They co-ordinate and guide people, squad members and chapter lead.
As with any organisation, today’s solutions give birth to tomorrow’s problems, so the story is not over yet…