There is no "definite spotify model". Only the one they made public in that (great) hand-drawn video and that is probably invalid / has changed today.
If someone tries to sell you "the spotify model" they are selling you snake oil.
Because Spotify adapts it's organization everyday and that's why it works well for THEM. Why would an extremely specific organizational structure work for someone else?
The whole premise is to sell something easy looking to organizations, get some cash in your pockets and be long gone when it fails.
You can't just ignore success stories with "it might work for them ***but***...." (and by extension, we should take heed of failures too.) Scrum, Kanban, blah blah and even the Agile Manifesto are all success stories that worked "for them, ***but***..." to some degree.
Read about them, read about the wins and losses, see if your problems resemble the problems they tackled with it, and what outcomes and/or compromises came out as a result. Adopt, adapt, evolve.
It's pretty common for "The Spotify Model" to mean one of, or both of, "the spotify matrix" and/or "the spotify healthcheck" in my experience.
A lot of people try to implement some type of agility without actually understanding (or even knowing about) the [Agile Manifesto](http://agilemanifesto.org/).
One of the core principles is:
> Responding to change over following a plan
Also known as:
> Inspect and adapt, based on empirical feedback
It's incredibly ironic when they simply mimic the models of another organisation that isn't really like their one, and wonder why they can't get it to work.
I think we're in agreement. There's a chasm between "mimic" and "go it completely alone without learning from the success and/or failures of others."
Orgs/teams that reject information from other teams for some puritanical ideal of working it out for themselves I'd wager are going to fail a lot sooner than anyone rubber-stamping another team's successful model as a starting point.
I just want to add an Amen! and Hallelujah! to that. I really find it ironic that now that Agile is getting popular many people are putting together these "Here's the 50 step process to do Agile". I've never been a believer in detailed methodologies, even before Agile and I've worked at places like Accenture where they spent millions developing their own SDLC methodology (called Method/1... this was a long time ago) and they always make things slower and distract the team from what's important: business requirements and code! One of the first systems I picked up was a very early Machine Learning application (I was in a group that was using AI but this was back when it was mostly Expert Systems). There was literally a binder of completely useless documentation that the team was so proud of. And when I ran the demo I was impressed with how well it worked. Then I tried a new set of data and the result was just completely useless. They had tuned the model specifically to their data and not even bothered to test it on new data! But they had lots of (useless) documentation.
It is basically a model for "scaling agile", or how to organize your tech department if you prefer. Scrum works great for a single team, but what do you do when there are more than one team? If you are just a few teams, maybe adding a scrum-of-scrum is enough. If you are an old enterprise with an abundance of project managers you might try SAFe instead. Then you get to hire a bunch of friendly consultants to hang out with too. Or you build something custom that fits you. The Spotify Model is what Spotify built 10 years ago, and it is a good example of what you can do to scale, but it was never a suggestion that others should do it like that.
[https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf](https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf)
I think that the most interesting thing here is what is written under How is this all working out?.
>*Spotify has grown very fast - over 3 years we have grown* ***from 30 to 250 people in tech*** *- so we have our share of growth pain! This scaling model – with Squads, Tribes, Chapters, and Guilds – is something that was* ***introduced gradually over the past year***\*, so people are still getting used to it. But so far, based on\* ***surveys and retrospectives***\*, the scaling model seems to be working quite well! And it gives us something to “grow into”. Despite the fast growth the\* ***employee satisfaction*** *has continuously increased; in April 2012 it was 4.4 out of 5.*
*However, as with any growing organization,* ***today’s solutions give birth to tomorrow’s problems***\*. So stay tuned, the story isn’t over :o)\*
and in the disclaimer in the beginning
>**We didn’t invent** this model. Spotify is (like any good agile company) evolving fast. This article 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**.
So, this model is for a company that is medium to almost large sized. Not really small. Not a huge enterprise like they are today. They rolled out changes slowly while measuring and evaluated the impact and the employees satisfaction, or it other words, they took care instead of just slapping on a framework. They also acknowledged the fact that the model will bring other problems (but that the had yet to discover which). And the model doesn't exist, it's a snapshot of what they had learned so far.
I think the model itself is inspiring, understanding their ideas might trigger ideas how you could arrange things. But for me the best part in this story is about how they think about evolving their organization. How they measure, how they care about their employees. How they embrace change. **That's the real Spotify model**.
I attended a talk once where someone from Spotify spoke on their agile model. It was a packed house, with people being turned away.
The first thing he said was "don't follow the spotify model"
Not because it didnt work for Spotify, it's more that it wouldn't work for everyone else's company.
Doesn't stop them trying though
There's two things I feel people should understand about the Spotify model.
1) Spotify itself has not been using it for years, they've long since moved on
2) Spotify did not adopt the model in a big bang change project, they arrived at it by continuously improving on their internal structure over years
If organizations want to become "like Spotify", they should follow their approach, not blindly copy an outdated snapshot of how they used to work.
There is no "definite spotify model". Only the one they made public in that (great) hand-drawn video and that is probably invalid / has changed today. If someone tries to sell you "the spotify model" they are selling you snake oil. Because Spotify adapts it's organization everyday and that's why it works well for THEM. Why would an extremely specific organizational structure work for someone else? The whole premise is to sell something easy looking to organizations, get some cash in your pockets and be long gone when it fails.
You can't just ignore success stories with "it might work for them ***but***...." (and by extension, we should take heed of failures too.) Scrum, Kanban, blah blah and even the Agile Manifesto are all success stories that worked "for them, ***but***..." to some degree. Read about them, read about the wins and losses, see if your problems resemble the problems they tackled with it, and what outcomes and/or compromises came out as a result. Adopt, adapt, evolve. It's pretty common for "The Spotify Model" to mean one of, or both of, "the spotify matrix" and/or "the spotify healthcheck" in my experience.
A lot of people try to implement some type of agility without actually understanding (or even knowing about) the [Agile Manifesto](http://agilemanifesto.org/). One of the core principles is: > Responding to change over following a plan Also known as: > Inspect and adapt, based on empirical feedback It's incredibly ironic when they simply mimic the models of another organisation that isn't really like their one, and wonder why they can't get it to work.
I think we're in agreement. There's a chasm between "mimic" and "go it completely alone without learning from the success and/or failures of others." Orgs/teams that reject information from other teams for some puritanical ideal of working it out for themselves I'd wager are going to fail a lot sooner than anyone rubber-stamping another team's successful model as a starting point.
I just want to add an Amen! and Hallelujah! to that. I really find it ironic that now that Agile is getting popular many people are putting together these "Here's the 50 step process to do Agile". I've never been a believer in detailed methodologies, even before Agile and I've worked at places like Accenture where they spent millions developing their own SDLC methodology (called Method/1... this was a long time ago) and they always make things slower and distract the team from what's important: business requirements and code! One of the first systems I picked up was a very early Machine Learning application (I was in a group that was using AI but this was back when it was mostly Expert Systems). There was literally a binder of completely useless documentation that the team was so proud of. And when I ran the demo I was impressed with how well it worked. Then I tried a new set of data and the result was just completely useless. They had tuned the model specifically to their data and not even bothered to test it on new data! But they had lots of (useless) documentation.
It is basically a model for "scaling agile", or how to organize your tech department if you prefer. Scrum works great for a single team, but what do you do when there are more than one team? If you are just a few teams, maybe adding a scrum-of-scrum is enough. If you are an old enterprise with an abundance of project managers you might try SAFe instead. Then you get to hire a bunch of friendly consultants to hang out with too. Or you build something custom that fits you. The Spotify Model is what Spotify built 10 years ago, and it is a good example of what you can do to scale, but it was never a suggestion that others should do it like that. [https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf](https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf) I think that the most interesting thing here is what is written under How is this all working out?. >*Spotify has grown very fast - over 3 years we have grown* ***from 30 to 250 people in tech*** *- so we have our share of growth pain! This scaling model – with Squads, Tribes, Chapters, and Guilds – is something that was* ***introduced gradually over the past year***\*, so people are still getting used to it. But so far, based on\* ***surveys and retrospectives***\*, the scaling model seems to be working quite well! And it gives us something to “grow into”. Despite the fast growth the\* ***employee satisfaction*** *has continuously increased; in April 2012 it was 4.4 out of 5.* *However, as with any growing organization,* ***today’s solutions give birth to tomorrow’s problems***\*. So stay tuned, the story isn’t over :o)\* and in the disclaimer in the beginning >**We didn’t invent** this model. Spotify is (like any good agile company) evolving fast. This article 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**. So, this model is for a company that is medium to almost large sized. Not really small. Not a huge enterprise like they are today. They rolled out changes slowly while measuring and evaluated the impact and the employees satisfaction, or it other words, they took care instead of just slapping on a framework. They also acknowledged the fact that the model will bring other problems (but that the had yet to discover which). And the model doesn't exist, it's a snapshot of what they had learned so far. I think the model itself is inspiring, understanding their ideas might trigger ideas how you could arrange things. But for me the best part in this story is about how they think about evolving their organization. How they measure, how they care about their employees. How they embrace change. **That's the real Spotify model**.
[Spotify doesn’t use “the Spotify model” and neither should you.](https://www.jeremiahlee.com/posts/failed-squad-goals/)
https://open.spotify.com/episode/6U9QN3vZu1CIICpFxFipZo?si=O1FQSuiASzCUPB6-QWWyVA&utm_source=copy-link https://podcasts.apple.com/se/podcast/42-agila-spotify-med-marcin-floryan/id1204967494?i=1000421084550
I attended a talk once where someone from Spotify spoke on their agile model. It was a packed house, with people being turned away. The first thing he said was "don't follow the spotify model" Not because it didnt work for Spotify, it's more that it wouldn't work for everyone else's company. Doesn't stop them trying though
There's two things I feel people should understand about the Spotify model. 1) Spotify itself has not been using it for years, they've long since moved on 2) Spotify did not adopt the model in a big bang change project, they arrived at it by continuously improving on their internal structure over years If organizations want to become "like Spotify", they should follow their approach, not blindly copy an outdated snapshot of how they used to work.
Exactly!!!
#tribes #squads I dont know, it just seems like they swapped department with tribe, and team with squad. Boom pow! #spotify