Why Spotify is not working
Let me start with my opinion that the Spotify way of working sucks. It worked very well for Spotify but over the years they have changed their way of working, but somehow most companies keep copy/pasting the original model. Don’t get me wrong, it was nicely structured back then. It had the companies best interest in there and also the best interest of the people working at Spotify. But it was designed for Spotify. Nowadays we see large companies who copy it and try to get it to work and most of the times with a lot of frustration. So lets stop with this horror model.
For those who are still unaware of the way they used to work. The way Spotify works is with the use of Tribes, Squads, Guilds and Chapters. And this worked fine. Worked, not works and only for Spotify. But somehow, we started to copy it, and to get it to work on a large scale we came up with Squad leads, Tribe guiders, Chapter coaches and so on. We made it complex again. I even see companies that have Tribe lead leaders, Chapter Coach Team Leads and even Certified Guild masters. Really? I often get powerpoints loaded with a lot of wireframes, drawings and solutions to get it to work. And these are drenched in frustration because most people don’t understand it anymore but are expected to make it work. It looks great on that one powerpoint slide but in the real world, it's a nightmare. So let’s look a little closer at the different parts for what they are and maybe come up with a more sound way of working with Spotify (if you must).
But wait! That’s how I would have liked to start my story. But there is a challenge. The Spotify model in itself in empty. It’s very nice to have all these cool names but there is no actual description in how they work. Spotify knew because they were already doing it and simply molded their way of working into something that was great for them. The Spotify way of working and there was nothing before that so they could do whatever they wanted (hint: so can you). But when you don’t already have a way of working and you simply copy something, then you will end up with a empty shell. It’s like having a CD in a nice CD case without any music. You can spin it all you like but nothing will happen. So let’s forget that model and start with something that might work.
Basically it starts with what we want. Or better, what do stakeholders want. Stakeholder or the customers want something or think they want something and it is up to product owners (let’s use a few scrum terms) to gather it all. These product owners have to work together as a team (yes all of them). They devise an overall and transparent Product Backlog or overview of what is wanted. They talk with each other every so often and prioritise everything. Yes even if it is a lot of stuff. If it is more than you can deliver than this might mean that you have too much to deliver. If needed use the quartile Program Increment (PI) Planning from SAFe or the Large planning sessions from LeSS (Sorry, I don’t do Nexus but feel free if you have something there that you can use) to do some prioritization. The PO’s can gather the stakeholders to these sessions to get a clear view every quarter. No excuse not to be there. It is only four dates in a year. And if you cannot free your agenda for that, then don’t even bother in showing up. The PI is also a very good moment for some budget allocation. Nothing wrong with that.
Next step is to bring it to the teams, Squads, troops or whatever you like. Just use your normal planning for this or use the LeSS overall planning if it gets to big. If you can get everybody in one room, than do that. Feedback is provided to the PO’s and they can talk to each other and if really needed, have a Central Product Owner (i don’t like a chief) to keep the overview. You can see this one as a tribe lead. Don't forget that a Spotify tribe is nothing more then an product group, theme or a part of what you produce or provide. (also do not forget that you are not Apache or Cherokee).
The team start to organize themselves and do the work. To reduce the risk of not working on the most prioritizes stuff or not seeing the overall risks or dependencies, then have members from the teams that do the work, join a System team (yes that’s a SAFe thing but really works). They will inform the PO’s about risks, dependencies and so on and do a little deep delving in needs and future stuff. The System team also connects between the teams. A circle of information if you like (hey isn't that a Sociocracy 3.0 thing?)
From here on it is just simply Scrum. Al the stuff that is needed. Stand Ups every day and at the end the Review. At the review the PO’s join and take back to the PO team all the feedback. The System team has it’s representatives to also take back information and Stakeholders are more than welcome. You can use stuff from Scrum if it is nice and small, or borrow a bit more from scaling models. Pick one model, or just pick what you like. Hell, even come up with some new cool things as long as it fits in the right way of working and everybody is happy with it.
Recommended by LinkedIn
Basically that is it. So where is the Spotify model. It is not there. Spotify, as I said, in itself is an empty vessel. It does not tell you anything about how you could or should work. You might say, yeah right. You just described a possible way that this Spotify way of working might be. That could be the case. But I just provided you with a idea from my own experience not from an existing model. And there are more ways to get things done. Most of it is just logical thinking and trial and error.
So where does that leave stuff like the chapters and the guilds. Well basically a chapter nothing more then a sort of Human Capital coaching or People who help and keep tabs on personal growth and competence of people. But don't mix this with the guilds. A Guild is nothing more than a knowledge group. A community of practises. A group about knowledge sharing and learning. They come together every once in a while to share what they know or want to learn.
So you have some parts from SAFe and LeSS. Just mixed up and taking the best of both (trust me, they are almost the same). Do structurization around the product. A Product Backlog and if needed cut it up in smaller parts so you can distribute it amongst the teams. Do Scrum but also let people move and change between teams. I love Dynamic Reteaming and you have to get really good at onboarding. There is no such thing as a fixed team. Use the travelers from Less to move between the teams, architects, designers, UX and even OPS. And let OPS also be part of the System team and let them be flexible.
Knowledge will be shared in sessions and you don’t need a guild master for that just focus on a way of getting information flowing. Maybe a little coaching at the beginning but Guilds or Community of Practices can very well organize themselves. The same goes for the information sharing of the System Team. They can organize themselves and use the product backlog and the communication with the PO’s.
So chapter movers, guild masters, competence managers, tribe coaches, squad masters and so on. Do you really need them? Maybe, but don’t just copy or even worse, try to keep working like you did and only change the names (same shit, different name). And you need to pay extra attention when they start to organize themselves into new special teams. Before you know it you have a new department made out of guild masters that doesn’t do anything and needs to be coached. It is a great idea by the way to get a change team together when you start a new way of working. But basically it is made of people from the entire organisation. Anyone can join, it’s not a coach or management party.
And are there stakeholders for the change? No. Absolutely not. Don't even use that idea. The mindset of a stakeholder in this is that these are particular people who have a certain stake in the change. As if they are outside of the entire program and just let others do their bidding and you have to report to them. You are either a part of the entire change and work together with everybody to make it work or you don't. Use a clear vision for the change and experiment a lot. Keep in mind that change is not something that you can plan, never! It is not something you can programme in a iterative way. Coaches can help but they are nothing more than facilitators and challengers (I personally like the idea of a disruptor). Try to get rid of them as soon as they want to go and you confident enough to let them leave.
And is this everything? Hell no but it's a good start. Trust me you will have your hands full with this and it will not be easy (i never said it would). Change comes from within and it is not a plug and play, copy/paste or shove it down their throats. You can steal and mix from frameworks as long as you know why. Don’t just copy without knowing why or because the picture you found on Google looks nice or the neighbors are also doing it. And it is still to my opinion that the only way that Spotify works for you is to turn it on, crank up the volume really loud and dance. Together.
Business & IT consultancy | Informatie analyse | Scrum master | Agile PM | ZZP
1yGoed verhaal, daar kan ik wel wat mee. Thnx.