Spotify @ tech11

What’s the Spotify model and what does tech11 have to do with it?

Spotify is probably well known by most of us, since they are one of the most successful music streaming providers worldwide. Even though the service was launched back in 2008[1], their first real successful year was 2012, when they reached 20 million active users[2].

Also, in this year Spotify released their “Scaling Agile @ Spotify”[3] whitepaper, which first introduced the so-called “Spotify model” to the world. Within this paper the authors, Henrik Kniberg and Anders Ivarsson, described how the company’s structure looked like at that time and how they had their own approach of working agile.

In short, the Spotify model is an adaptation of a matrix organization but with different, more fancy naming for organizational entities like “Tribes”, “Squads” or “Guilds”. If you chose to dig deeper, the Spotify model is a complete approach to an agile way of working.

Squads are thought of as self-organizing, complete business units, that are concerned with a single long-term goal such as Spotify’s App or the media player in the desktop version. The focus inside those Squad is that they should act like a “mini startup” that could completely be decoupled off the company and therefore needs all the skills required in a team to be self-sufficient.

The next major business unit in the model are the Chapters, which depict the job families. They are used to have technical exchanges outside of the squads. For example, if Developer X has an issue that he just fixed in his Squad, that same problem might occur in another Squad. With the Chapter structure, developer X could talk to developer Y in a knowledge exchange meeting to share his experience.

This leaves us with the remaining organizational units, Tribes and Guilds. Basically, Tribes bundle multiple Squads together, mostly used as one Tribe per location, e.g. Stockholm Tribe, Berlin Tribe, etc. Guilds on the other hand combine likeminded people inside the whole company. They can exist across Tribes and can for example connect all developers who work with Java.

Now that you know a bit about the Spotify model, the question remains: what does tech11 have to do with it? Obviously, the answer to this question is that we’re using this model for our collaboration at tech11, but there is more to it. 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

Why does tech11 use this model?

To understand why tech11 uses this model, we should have a look on how the preconditions in our company are looking like. Since tech11 provides a core insurance platform for P&C insurances, there are some customers with different requirements on how our platform should work for their purposes. That means on our side we need to customize the platform in almost every project, sometimes more, sometimes less. And that leads us to having the need for teams that are deeply familiar with the requirements of this specific customer. To sum that up: for each customer, we have a dedicated project team that solely customizes their requirements.

Now if you look back to what we discussed in the first section of this Blog, you might see a similarity to an organizational unit that was used by Spotify. Can you guess it?

Of course, it’s like a Squad.

By using a Squad - so a team that has all the people available to fulfill all customer requirements - we can establish an efficient way of working with that team, to achieve the highest customer satisfaction possible. Also, in the spirit of Spotify, the Squads are enabled to decide for whatever agile methodology they want to choose. We have Squads that do Scrum, we have Squads that do Kanban, and we have Squads that do a bit of both. This establishes a real agile environment where we empower the teams to follow an agile project management approach.

Additionally, tech11 introduced Chapters going along with the Squads. Similar to Spotify, the goal was to have a home for all developers in the same job category, e.g. the Backend Chapter. At tech11 we more or less refer to them as job families or Chapters alike.

What we don’t really use at tech11 are Tribes, since we don’t separate the different locations thematically. Someone from Accra could collaborate with someone from Würzburg in the same Squad. Guilds on the other hand are used in open teams, e.g. our DevOps team, where everyone can join in.

That’s all, isn’t it? No, like Apple we have one more thing…

Micro Squads

Until this point you’ve heard about Squads, which were initially designed by Spotify, but now we’re talking about Micro Squads? Again, we have to take a step back to understand where this concept of tech11 is coming from.

?As we build our core insurance platform our goal is to create a standard of our product that is ideally usable out of the box for every new customer. To achieve this, we must improve the basis of the platform on a daily basis. We simply can’t only work on customized parts but need to find ways to build something that fulfills multiple needs.

?Here our Platform Squad comes in. The first special thing about our Platform Squad is that almost every developer, business analyst and even our content team is included in this very big team.

?Probably the question “How does this work out? You can’t have a team of 50 people collaborating” arises. That is what the Micro Squads are for.

?In the same sense as the Squads, Micro Squads aim towards having a team that consists of all necessary skills to deliver a new feature. Exactly that is the scope of a Micro Squad, to only develop one new feature based on a user story. The Micro Squad team itself looks like this:

·????? 1 Agile Coach

·????? 2 Business Analysts

·????? 2 Backend Developers

·????? 2 Frontend Developers

·????? 1 Tester

·????? 1 Technical Writer

If you did some further research on the Spotify model, then you might have noticed that a Product Owner is missing from this list. At tech11 we don’t have that single PO that is handling all our Backlogs, instead we have a platform committee that prioritizes as four and then hands over to our so-called Story Owners.

These Story Owners are the functional Managers of the Micro Squads and should give prioritization and guidance to the other colleagues in the team. Typically, at tech11 Business Analysts tend to be Story Owners for most of our Micro Squads, but we also had some Developers that took over that role successfully.

After the Micro Squad completed the development of their feature and passed our internal review process, this team disbands and forms in a new Micro Squads that usually consist of other combinations of team members.

History and Challenges of Micro Squads

You can imagine that Micro Squads haven’t been all fun and success up until today. Of course, there were some difficulties and challenges, especially in the beginning. Like with every other change in the world, people were a little skeptical at first. We introduced Micro Squads in June 2023 and started with the first one a couple of weeks later.

?Common problems at the beginning were server issues while setting up the Micro Squad dedicated development server. We started with the intention that our Operations team would set up every server, but quickly realized that this would take a lot of precious time off them.

Additionally, Micro Squads were the first time besides delivery teams, where employees of different departments started collaborating in a cross functional manner. Obviously, it takes some time to get used to how others work, especially if you maybe haven’t even known the other person at all before.

A third and major issue were our estimations on how long these Micro Squads will take. The initial idea was that Micro Squad shouldn’t take longer than three weeks to complete. Ambitious, but we wanted to create user stories that would be manageable in that time. What we didn’t consider was, that our existing stories weren’t ready for that approach. Some aren’t up until today. The result was that we started Micro Squads, that took weeks if not even months to complete, while struggling to find a realistic due date to set themselves.

Luckily, we overcame most of those issues. Server setup issues are removed by infrastructure as code pipelines that come with a nice readme, so that everyone is able to set the server up and there is no need for the OPS team to jump in. After some time more people got to know each other and started to like each other, so now we’re at a point where the teams sometimes want to stay in a team longer for multiple Micro Squads instead of disbanding. And we’re currently at a point where self-set due dates are more realistic and teams are more productive within the Micro Squads, so that they can eventually reach them.

Benefits of Micro Squads (so far)

Since it’s almost been a year now since our first Micro Squad kicked off, we can now draw a nice summary of the past 12 months. Micro Squads developed to a point where we can really call them an efficiency improvement for our company. The transformation from our old system to the current organizational structure came with a huge increase in development speed.

If we take an average ticket that we worked on in the past, for instance we took 9 months for development and testing. That was because every team worked separately and in a sequential way, so waiting times were a huge factor in this long duration time.

Today we have development times of 3-4 weeks on average for most Micro Squads. Of course there are still some outliers, but then that’s more related to the size of the user story not to waiting or collaboration issues.

As mentioned, our employees collaborate with a lot of others outside their job families and gain a lot of new perspectives and experiences through that. That’s something that often gets mentioned inside our Retrospectives. In general, we gave a lot of empowerments to the Micro Squads, and they benefit from it. The fact that our best success story of a Micro Squad was with a Developer as Story Owner shows how everyone can evolve through this agile way of working.

Something we also improved during the time while Micro Squads were existing is the quality assurance behind all those user stories. We introduced an internal review process that has multiple instances of checks to really deliver a great result.

What’s the future of the Spotify model at tech11?

This is probably the hardest question to answer in this whole article. Since tech11 is a very agile company, we repeatedly ask ourselves the question “is this still the correct approach for us?”. Similar to what Kniberg & Ivarsson wrote in the “Scaling Agile @ Spotify” paper, once you’re reading this, things might have already changed.

But one thing is for sure and that is that we’re going to further refine our processes, try new things and if they work out, we implement them for all Micro Squads. And most importantly we listen to our colleagues, what they like about the processes, what they dislike and what they suggest for improvement. This considered, we try to invent new ways of collaborating and improving our daily work life.

Article written by Simon Reim