The popular music streaming service Spotify is probably familiar to most of us, as the company is one of the most successful music streaming providers in the world. Although the service was launched back in 2008 1, its first really successful year was 2012, when it reached 20 million active users 2.
In that year, Spotify also published the white paper "Scaling Agile @ Spotify" 3, in which the so-called "Spotify Model" was presented to the world for the first time. In this paper, authors Henrik Kniberg and Anders Ivarsson described what the company's structure looked like at the time and how they pursued their own approach to agile working.
In short, the Spotify model is an adaptation of a matrix organization, but with different, fancier names for organizational units such as "tribes", "squads" or "guilds". If you want to go deeper, the Spotify model is a complete approach to an agile way of working.
Squads are meant to be self-organizing, complete business units that deal with a single long-term goal, such as the Spotify app or the media player in the desktop version. The focus within these squads is that they should act like a "mini startup" that can be completely decoupled from the company and therefore requires all the skills a team needs to be self-sufficient.
The next major business unit in the model is the chapters, which represent the job families. They are used for technical exchange outside the teams. For example, if developer X has a problem that he has just fixed in his squad, the same problem could occur in another squad. With the chapter structure, developer X could talk to developer Y in a knowledge sharing session to share their experience.
This leaves the remaining organizational units, tribes and guilds. Basically, tribes bundle several squads, which are usually used as one tribe per location, e.g. the Stockholm tribe, the Berlin tribe, etc. Guilds, on the other hand, unite like-minded people within the entire company. They can exist across tribes and, for example, connect all developers who work with Java.
Now that you know a little about the Spotify model, the question remains: What does tech11 have to do with it? The answer to this question is, of course, that we use this model for our collaboration at tech11, but there's more to it than that. So let's dive deeper!
1 https://newsroom.spotify.com/company-info/
2 https://soundiiz.com/blog/the-history-of-spotify/
3 https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
To understand why tech11 uses this model, let's take a look at what the requirements are in our company. Since tech11 offers an insurance platform for property insurance, there are some customers with different requirements on how our platform should work for their purposes. For us, this means that we have to adapt the platform in almost every project, sometimes more, sometimes less. And this means that we need teams that are very familiar with the requirements of that particular customer. To summarize, we have a dedicated project team for each customer that deals exclusively with the customization of their requirements.
Now, if you remember what we discussed in the first section of this blog, you may see a similarity to an organizational unit used by Spotify. Can you guess it?
Of course, it's like a Squad.
By using a Squad - that is, a team that has all the people to fulfill all customer requirements - we can establish an efficient way of working with that team to achieve the highest possible customer satisfaction. In addition, the squads can decide for themselves which agile method they want to choose, in the spirit of Spotify. We have squads that work according to Scrum, we have squads that work according to Kanban, and we have squads that do a bit of both. This creates a true agile environment where we empower teams to take an agile approach to project management.
In addition, tech11 has introduced chapters that go hand in hand with the squads. Similar to Spotify, the goal was to have a home for all developers of the same job category, e.g. the backend chapter. At tech11, we more or less refer to them as job families, or chapters.
What we don't really use at tech11 are tribes, as we don't separate the different locations thematically. Someone from Accra could work with someone from Würzburg in the same squad. Guilds, on the other hand, are used in open teams, e.g. in our DevOps team, where anyone can join.
That's all, isn't it? No, like Apple, we have one more thing...
If you've taken a closer look at the Spotify model, you may have noticed that a Product Owner is missing from this list. At tech11, we don't have a single PO who takes care of all our backlogs. Instead, we have a platform committee that sets four priorities and then passes them on to our so-called story owners.
These story owners are the functional managers of the micro squads and are supposed to prioritize and guide the other colleagues in the team. Typically at tech11, Business Analysts are the Story Owners for most of our Micro Squads, but we have also had some developers who have successfully taken on this role.
After the Micro Squad has completed the development of their feature and passed our internal review process, that team disbands and forms a new Micro Squad, usually made up of other combinations of team members.
As you can imagine, Micro Squads have not been all fun and success to date. Of course, there have been some difficulties and challenges, especially in the beginning. As with any other change in the world, people were a bit skeptical at first. We launched Micro Squads in June 2023 and started with the first ones a few weeks later.
Common problems in the beginning were server issues when setting up the dedicated Micro Squad development server. Initially, we wanted our operations team to set up each server, but we quickly realized that this would take up a lot of precious time.
Also, the Micro Squads were the first time that employees from different departments worked together cross-functionally in addition to the delivery teams. Of course, it takes time to get used to the way others work, especially when you may not have known the other person before.
A third and important aspect was our estimate of how long these Micro Squads would last. Originally, the Micro Squads were not supposed to take longer than three weeks. That's ambitious, but we wanted to create user stories that could be completed in that time. What we hadn't considered was that our existing stories weren't ready for this approach. Some are still not ready today. The result was that we started with micro squads that took weeks, if not months, to complete, all the while struggling to find a realistic due date for them.
Fortunately, we overcame most of these issues. The problems with setting up the server were eliminated by the infrastructure in the form of code pipelines that come with a nice readme file, so that anyone is able to set up the server without the OPS team having to intervene. After a while, more people got to know and like each other, so we're now at a point where teams sometimes want to stay in a team for several micro squads longer instead of disbanding. Also, we are now at a point where self-imposed deadlines are more realistic and the teams within the Micro Squads are more productive so that they can eventually fulfill that role successfully.
After the Micro Squad has completed the development of its function and passed our internal review process, that team disbands and forms a new Micro Squad, usually made up of other combinations of team members.
Now that it's been almost a year since our first Micro Squad was launched, we can give a nice summary of the last 12 months. The Micro Squads have evolved to a point where we can truly call them an efficiency booster for our company. The transition from our old system to the current organizational structure has been accompanied by a huge increase in development speed.
If we take an average ticket that we worked on in the past, for example, we needed 9 months for development and testing. This was because each team worked separately and sequentially, so waiting times were a big part of this long time span.
Today, we have development times of 3-4 weeks on average for most micro squads. Of course, there are still some outliers, but this is more related to the scope of the user story and not to waiting times or collaboration issues.
As already mentioned, our employees collaborate with many others outside their working group and gain many new perspectives and experiences as a result. This is something that is often mentioned in our retrospectives. In general, we have empowered the Micro Squads a lot and they benefit from it. The fact that our best success story was a Micro Squad with a developer as Story Owner shows how everyone can develop through this agile way of working.
Something we have also improved in the time the Micro Squads have existed is the quality assurance behind all these user stories. We have introduced an internal review process that involves multiple instances in order to achieve a really good result.
This is probably the most difficult question to answer in this whole article. As tech11 is a very agile company, we keep asking ourselves "is this still the right approach for us?". Similar to what Kniberg & Ivarsson write in their article "Scaling Agile @ Spotify", things might have already changed by the time you read this.
But one thing is for sure: we will continue to refine our processes, try new things and if they prove themselves, we will implement them for all Micro Squads. And the most important thing is that we listen to our colleagues, what they like about the processes, what they don't like and what they suggest for improvement. In this way, we try to find new ways of working together and improve our day-to-day work.