Agile Team Organization: A deep-dive on the Spotify Model

Building a product that is flexible, high-quality, and that can react to market demand quickly is essential, but having a process and an organization that emulate this is equally important.

Let’s start by taking a look at real-life examples of companies that have failed, coped with legacy technology, embraced change and innovated. The following image speaks for itself.

Why go Agile?

There are many reasons for that, but the key is all about scalability. As your company grows, you need to be in a position to expand and grow easily and painlessly. Especially in smaller companies, where usually roles are quite vague and people generally do whatever it takes to get things done. Early in the life of a company, this can be easily applied, because you need to move fast and deliver. But as the company grows, this is not a sustainable model.

It is then that assigning roles and responsibilities are needed, and Agile promotes that you have feature teams: fully autonomous teams that have end-to-end responsibility for what they build. Many companies utilize this model, Spotify being the most famous example, as they first introduced Scaling Agile @ Spotify white paper back in 2012. It covered the radically simple way that Spotify approached agility and since then, the Spotify model generated a lot of buzz and became popular in the agile transformation space. Spotify started applying a scrum model, but soon realized it would have to adapt to something else as it grew in size. Part of its appeal comes from the fact that it focuses on organizing around work rather than following a specific set of practices. In traditional scaling frameworks, specific practices (e.g. daily stand-ups) are how the framework is executed, whereas the Spotify model focuses on how businesses can structure an organization to enable agility.

There are so many ways one can form an Agile team in the world of project management. But before we deep-dive into the technicalities of the squads, tribes, chapters, and guilds, we must first get to the core of why these grouping terms exist in the first place.

Key elements of the Spotify model

The Spotify model is centred around simplicity. When Spotify began organizing around their work, they identified a handful of important elements on how people and teams should be structured. Their teams are split up into very small ones, that own a certain part of functionality end-to-end.

Squad

Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6–12 individuals) focusing on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. Squads determine which agile methodology/framework will be used.

Tribe

When multiple Squads coordinate with each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40–150 people in order to maintain alignment. Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.

Chapter

Even though Squads are autonomous, it’s important that specialists (e.g., JavaScript Developers, DBAs) align on best practices. Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology leader, who may also be the manager of the team members in that Chapter.

Guild

Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and it is completely voluntary to do so. Whereas Chapters belong to a Tribe, Guilds can cross different Tribes. There is no formal leader of a Guild. Rather, someone raises their hand to be the Guild Coordinator and help bring people together.

Benefits and challenges of the Spotify Model

Spotify changed the way they scaled agile, to enable Squads to move fast, ship software quickly, and do so all with minimum pain and overhead. They realized these benefits and more as they took their model and evolved it. The organizational benefits of implementing the Spotify model include:

• Less formal process and ceremony
  The Spotify model focuses on organizing around work and not necessarily processes and ceremonies. This gives an organization greater flexibility when it comes to how Squads work. Instead of requiring Squads to change how they do their work (“you must do scrum”), it focuses on aligning them with each other and driving towards individual team outcomes.
• More self-management and autonomy
  The Spotify model encourages autonomy and creativity by trusting people to complete the work they are doing in the way they see fit. Do you need to ship software? That’s up to the Squad. Do you need to change direction? That’s also up to the Squad. The Spotify model focuses on decentralizing decision-making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.

The Spotify model was based on one organization’s way of working. Many organizations desire the same benefits of the Spotify model, so they attempt to emulate what Spotify did. Some organizations experienced more success than others, but it’s likely no organization experienced the same success as Spotify. The reason? Like any way of working, an organization’s current culture and structure need to be taken into account. The model is simple, but the environment it’s implemented is complex.

Time to scale

Let’s say that your organization has implemented the first steps in agile, and has already set up some initial teams working according to the aforementioned principles. You’ve started witnessing the benefits of agile but you’re only limited to the teams already working within this framework — and that’s where the scaling part comes into play.

Scaled Agile Frameworks enable managers to spread agile working to every team at every level and in every department, including top management, and reduce coordination and control to a minimum. Obviously, from organization to organization, there will be different issues while spreading agile to one or more teams, and that’s why there is also a big variety in scaled agile frameworks.

The most popular one, SAFe®, combines Lean, Agile, and DevOps practices for business agility and its prescriptive nature provides concrete guidance without forcing management to overhaul the organizational structure. It is largely adopted by organizations around the world that vary in size — a startup with 5 people can use SAFe® just like a conglomerate with thousands of employees.

Fitbit for example combines both attributes (startup, but with more than 1.700 employees) and is implementing SAFe® with major success as the company has grown significantly since the start of the adoption. The company could not meet the deadlines of consumer holidays and was struggling to keep up the pace, implementing basic Scrum.

With major consumer holidays as deadlines, target dates are immovable. Early Scrum efforts could not keep pace with company growth. By implementing SAFe®, Fitbit delivered the highest number of products in a year and overall increased its velocity by 33%. Since then, Fitbit has been implementing the specific framework in various products and operation lines, and proceeds to different iterations each year to match the needs and scope of the business.

Don’t copy — get inspired

If you want to scale Agile in your organization, the Spotify model is a good source of inspiration. Its appeal lies in its simplicity, offering an easily accessible path for teams to organize their work in a way that suits their culture. It is an informal approach that encourages self-management and innovation. It also aligns well with the principal benefits of Agile itself, including customer satisfaction, improved quality, and greater adaptability.

However, there has been some concern among Agile professionals about the practice of directly implementing the Spotify model and treating it as an established organizational framework. The model was not intended to be a generic framework, but rather a snapshot of how Spotify was working. The overall message here is that the Spotify model is just that — a model for Spotify. For your organization, you may need something more.

In Spotify’s own words: “We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This is only a snapshot of our current way of working a journey in progress, not a journey completed. By the time you read this, things have already changed.”

Also, do remember the value of autonomy. The Spotify model is admirable because it creates a positive atmosphere where teams can self-organize effectively and foster their individual creativity. If you are creating a hybrid approach where you incorporate practices from various models and methodologies, make sure you don’t make it too prescriptive — give your teams the freedom to work the way they want.

Finally, focus on your culture. What makes your organization unique? Prioritize the cultural elements you don’t want to lose and figure out how to build them into your Agile team model.

Rethink your business structure today and become agile. Learn how or reach out to us for a tailored solution: thefoundation.gr.