The first book that I recommend anyone read about Agile is “Scrum and XP from the Trenches” by Henrik Kniberg.
Kniberg has a relaxed, informal and straight-forward way of explaining how to do Scrum, which leaves you in no doubt that the author has actually been a Scrum Master himself.
So naturally, when I heard that Kniberg was working at Spotify and was experimenting with some ideas to scale Agile beyond the team level, I was very interested in hearing what he had to say.
(Image courtesy of Spotify)
The squad is the central unit of Spotify’s scaled Agile approach. Squads are multi-functional, self-organising teams that focus on a particular aspect product.
Tribes are collections of squads which share a focus on a certain product area. They meet regularly to showcase what each of the squads within the tribe is doing – both product work and the result of hack days (see below).
Chapters are groups which are formed across squads made up of people with similar skillsets (e.g. web developers, testers, designers, UI developers). Each chapter has a senior member who, as well as being a member of one of the squads, acts as line manager to all the other members of that chapter.
Guilds may have membership across more than one tribe and are not necessarily restricted to one subject area. Examples of guilds given by Kniberg are web guilds – which may include web developers, designers and testers and an Agile coaches guild.
Squads, tribes, chapters and guilds might be the most obvious features of the Spotify approach to scaling Agile. But some of the others aspects of the scaled Agile set up – which might seem incidental – may well be the most important.
Tribes sit together and have good facilities
In Spotify, squads all sit together, and wherever possible, squads in the same tribe are together in the same building. The squads have control over their surroundings. They have kitchens and breakout rooms and most of the walls have whiteboards on them.
Each squad takes one day in ten as a “hack day”. The squads themselves can decide whether they take these singly or group them together to have a whole week. The purpose of this time is to give members of the squads the opportunity to learn about new technologies and communicate them to other members of the squad. It is also an opportunity for innovation.
The release team supports the Squads
Rather than having a separate release team which handles the release of software, the goal of the release team is to allow the development teams to release their own software.
What about architects?
The architecture of Spotify is service-oriented, with over a hundred systems making up the whole site. Each service has a system owner, and the most important systems have a developer/devops pair as system owner.
The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership.
What about product owners?
There is a product owner associated with each squad. As Kniberg says:
“The PO is the ‘entrepreneur’ or ‘product champion’, focusing on delivering a great product.”
Although this isn’t discussed explicitly in the articles on Spotify that I’ve read, it can be imagined that the product owners themselves would be organised into a chapter – with their own chapter lead.
What is your experience in scaling Agile? Leave a reply below, or contact me by email.