 | Request for Demo Session |
| Watch Our Intro Video |
Blog AuthorStarAgile
PublishedApr 25, 2024
Views2,866
Read Time15 mins
Table of Content
Spotify is one name that we all have heard with 286 million users presently. Among the many reasons for the company’s success is the company’s approach to team dynamics and organizational workflows. As sociological, political and economic pressure transformed the company's kinetics, the traditional structures and practices became outdated. As a result, this model was found and executed by Spotify’s engineers to fulfil the organizational goals. They found out the best practices that were working for them and documented them for the world to practice. With this blog, I will explain more about the Spotify Model and how teams can use it for scaling agility across organizations: inter and cross-functional teams. The company dynamics change as it is impacted by social, political, or economic factors.
As I discussed before, the Spotify model is developed by the Spotify team that works towards achieving agility across teams. It is a people-driven, autonomous approach that enhances innovation and productivity by focusing on factors like communication, accountability, and quality.
The Spotify model was introduced to the world in 2012, when Spotify coach, Henrik Kniberg published a whitepaper on how the company looks at agility and practices it through a very simple model. This model gained popularity immediately as it was different from all the other models that came into the market before. It majorly focused on organizing around the work rather than working as per the set of guidelines. The framework suggested that all the teams in the Spotify framework can choose the agile framework of their own choice and complete the work as per the guidelines set by it.
Henrik and Anders were part of the team that helped Spotify scale to a big company. They proposed the Spotify model in 2012 and shared the learning in a whitepaper. The Spotify model is based on the autonomous scaling agile at Spotify, it is primarily based on an agile model and specifications tailored to the needs of Spotify company. It became popular and was invented by Henrik Kniber. But later on, Henrik cleared the fog by mentioning he is not an inventor of the framework but merely a messenger for the same.
As I researched, I found out that in the article, published by Henrik himself he is stating how the internet is passing on wrong information and he did not invent the method. The Spotify model is the result of a lot of people collaborating and experimenting over time, and many aspects of the model were invented without my involvement at all. Mentioned Henrik
The model is built around simplicity and these are the elements figured out by Spotify to make the Spotify Agile Model a success. It is primarily based on three key elements which are: people, culture, and network keeping people first. These elements are used to make it scalable and feasible for complex and big organizations.
1. Squads: Similar to the scrum teams, the squads are also a compilation of 6-12 individuals who work for a particular feature area. They are assisted by an Agile coach and guided by a product owner. They are the ones who decide which agile framework will be used for the framework.
2. Tribes: When many squads work together for the same feature area they come together to form a tribe. It is typically a group of 40-50 individuals. Each tribe is headed by a Tribe head who is responsible for maintaining the sync between the work being done. They are responsible to improve collaboration and make sure every squad is working towards the same goal.
3. Chapter: Even though squads are autonomous groups, the specialists must get aligned for the best technical process. Chapters are defined as a family that every specialist has to maintain for the engineering standards. Chapters are led by a Senior technology lead who can be the manager for team members in a chapter.
4. Guild: Guild connects people with the same interests. People who are passionate about the same thing can join a guild and they can be from different tribes as well. Whereas chapters belong to tribes, guilds are completely independent and it doesn’t have a formal leader. If we want to keep things on track, having a guild coordinator will be a good idea.
5. Trio: The trio stands for Tribe Lead, Product Lead, and Design Lead. There is one trio in each tribe to make sure there is a proper sync in the work and continuous alignment between the feature areas.
6. Alliance:
In the short timeframe, the Spotify model was able to help the organization fulfil the tasks at hand. The method is proven to be helpful in many ways including:
1. Scalability: This model is scalable which means it can be implemented in any kind of team and project.
2. Cross-functional teams: The team helps the members to make quick decisions effectively which is essential for any project's success. Moreover, it helps in building cross-functional teams with a different set of skills and capabilities to accelerate collaboration and enhance productivity.
3. Scope for improvements: As the model is not rigid, it helps you to do experimentation. It allows you to fail and learn from the mistakes made allowing, imposing a growing environment.
Spotify currently doesn’t use the Spotify Agile Model and there have been controversies that it was never used. These are the primary reasons why the Spotify model was discarded by the company:
1. Relabaling of structures: It was believed, that the Spotify model was the renaming of most of the existing matrixes followed in an organization. This led to confusion among employees and demolishing of the model.
2. Challenging management: Each squad has different functional managers for the chapters. If any disagreements arise, it has to be resolved between multiple managers and then go to the tribe managers. It will create unnecessary complications within the team.
3. Team autonomy: Spotify works on the concept of team autonomy, it works well for the fast-moving startups but will be poor for big organizations. As the Spotify company grew, the company needed better alignment to manage rapid growth and avoid duplication and complexity.
4. Agile knowledge: There are agile coaches to guide the squads, but when there is a transition happening, there are not enough agile coaches to guide the team on how to implement agile into the workspace. These things collectively impacted the model negatively and were discarded by Spotify.
Here’s what you should learn from Spotify’s mistakes:
1. Lack of engineering managers: One of the major drawbacks of the Spotify model was the TDE team saw an absence of an engineer manager. The Spotify Agile model has chapter leads but they are not accountable for any work deliverables which sets unrest in the team dynamics.
2. Cross-team collaboration and autonomy are hard to balance: Different squads didn’t have the bandwidth to collaborate and contribute to other people's work. If there were some roadblocks, the team itself had to create tools and perform tasks efficiently.
3. Unnecessary complexities: The name structuring of the processes is only according to Spotify's requirements, it is not aligned with your company's requirements.
4. Shifting responsibilities: The model is criticized for shifting the responsibilities of the project to complete the targets.
5. No clear hierarchy: Another lacking issue in the Spotify model is no clear hierarchy and the projects fall apart without a clear leader. many believed as it was too rigid, it lacked innovation, responsiveness, and creativity.
6. Only for small-scale: The model is a complete flop for larger organizations as there is no hierarchy and without it is very difficult to keep large groups of people working efficiently.
Big companies like Lego and ING implemented the Spotify Model in their organization. The companies who opted for the Spotify Model are struggling and will continue to struggle due to the many loopholes the framework has. Leaving behind the Spotify Model, many companies moved forward to more detailed agile methodologies like those mentioned below to drive more success, better results, and also better productivity:
The primary difference between Spotify and SAFe is that Spotify is a lightweight framework. This means the framework is not considered as an extensive tool for Spotify's agile development rather the teams have to produce the details. Moreover, the Spotify model doesn't deliver any solutions to maintain portfolios like SAFe.
On the other hand, the SAFe framework gives more comprehensive and detailed solutions. It has the following advantages:
I will conclude by saying that If you’re looking for an agile framework that will suit a fast-moving environment, then the Spotify model can be a good choice. But copying and pasting the methodology as it is in your organization will do no good, you need to tailor it as per your requirements. Spotify is not a destination, it is more of a pathway to learn what suits the company best. Ironically, the Spotify company itself doesn’t use the Spotify Agile model right now, and not many companies follow it at present. You can start with the Spotify model and work your way up to agility further.
As the Agile Spotify Framework is refrained by the big names, people are switching to SAFe as a primary agile methodology. If you’re interested in learning SAFe and becoming an expert in it, then SAFe Certification should be an ideal choice for you. StarAgile’s SAFe Certification is chosen by 300k+ students to transition into a more successful career. You can also join fellow participants and take your career ahead.
professionals trained
countries
sucess rate
>4.5 ratings in Google
05 Jul 2019
15 mins
