Recently I’ve been mulling over the Spotify model for organisation of software teams and how widely it could be applied within the software industry. For those of you newer to the concept I’ll give you a quick description here but I also suggest that you read the original paper.
- Squad – A multi-functional team which owns an area of functionality. They work directly with the product owner and are self-managing. The team is responsible for end to end delivery of software changes.
- Tribe – A collection of squads which are responsible for a particular product or subset of a product. There is a tribe leader.
- Chapter – A group of people from various squads which all have similar skillsets, such as web developers. There is a leader for the chapter who is also the line manager for the members of the chapter. The chapter leads report to the tribe lead.
- Guild – A group of people across all tribes who are interested in a particular practice, such as automated testing, system testing or agile coaching.
The squads are autonomous and set up to take advantage of the innovation which comes from taking a lean startup approach (minimum viable product, experimentation, measuring results, early feedback, validated learning).
I really like the ideas behind this model.
- It’s scalable; new tribes can be created of needed due to growth and squads can be added to existing tribes as appropriate
- It’s flexible; squad structures can be changed over time without affecting reporting lines
- The reporting lines allow for the good bits of line management without impacting the self-management of the squads, as the line managers do not have responsibility for a squad
I wonder how the model can be applied to those companies for whom their product is not their software; organisations which produce physical or financial products, for example, and which have internal development teams. Those teams are still under pressure to be flexible, scalable and deliver early but there are some cultural aspects which could cause problems in using this model.
- How acceptable would it be in a traditional organisation to talk about squads, chapters, guilds and tribes? It depends on the culture of the organisation but I suspect that using such names could be problematic in how the department is viewed within the rest of the business and from the cynicism of the team members themselves.
- Achieving self-managing teams could be difficult in a hierarchical organisation, both because of middle management reluctance and/or some team members not wishing to be empowered. This is a problem which would be faced in an agile world irrespective of whether ir not we wished to use the Spotify model and would need to be addressed as part of any agile transformation.
- How active would people be in guilds? I suspect that this depends on whether the guilds are defined by management or created as needed by the squad members themselves.
- How would you deal with a situation where there are many smaller products rather than one large one? What if there wasn’t enough work for a single squad to focus on a single product? Would you form and re-form squads as the work changed or would you have each squad owning multiple smaller products? What if you have quite a bit of high value work in one product? Do you only have one squad working on it whilst another squad is working on their own product, but all of the work is of lower business value?
- How would we ensure consistency in the handling of live incidents if they were handled by different teams?
In the best lean startup approach I wonder whether it would be worth running an experiment; setting up a trial with some people working in this manner and measuring the results as well as better understanding the issues.
If you have any experience of working in a Spotify type environment or are interested in the subject I’d love to hear from you. Please feel free to leave a comment, or contact me on Twitter or LinkedIn.