Don’t they say a picture is better than a thousand words? Well then, here you go. This is the Spotify model in a nutshell, by Henrik Kniberg:
Oh and wait, that was only part 1. Ready for part 2?
Impressive eh? Inspiring even! That is exactly what we thought. And after playing and working with it for a few months – and by that we mean the whole shabam, IT, Marketing, Productmanagement, everybody – we extracted 4 main take aways that makes the magic work:
Understanding the Spotify principles: our 4 take aways
- Strive for the type of alignment that enables autonomy . How to get there? Through loosely coupled yet tightly aligned teams. At Spotify they call them squads… sounds like the World of Warcraft doesn’t it?
- Focus on trust instead of control. Empowering people to take their own destiny at hand. The famous quote “hire great people and get out of their way,” is on posters and hung up all over our floor in the office.
- Aim for frequent releases with customer value. To learn fast and spread the joy, and sometimes the pain. This principle can conflict with our perfectionism and tendency to postpone the hard stuff indefinitely. But, if you stick to it, you will get amazing results.
- Promote the community as the best practise of sharing. Everyone is part of a community (in the Spotify jargon a chapter) where the specific expertise for that domain is shared and cherished.
And one final insight to top it off. this alignment, trust sharing and releasing takes place within the cosiness of a tribe. We can hear you think, are we in the middle of Lion King musical or is this a serious blog? Well, the latter! In the tribe,everyone one finds a caring (professional) home.
Did we make you curious? All those new words and principles? Then eat your heart out, we will be sharing our experiences with all of them and many more in many blog posts to come!
Want to know more about the Spotify model? We highly recommend you to take a look at the great video’s of which the pictures above are a screenshot.
Cheers! Saloua & Marijke
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Yeah yeah, everybody is cloning the single Agile/LEAN/Scrum success-story of Spotify; I’d rather not copy a (relatively) small streaming-websites’ IT organisational-model to one of the biggest financial corps in the world. That’s like applying penny-shares logic to gold-bars. Bank-customers don’t want chapter-leads, squads or shamans; they want managers in suits that don’t drink hipster-coffees and waste money on crappy slogans, but simply look after their money.
Customers also don’t care about hipster innovations like voice-authentication, they want their money to be safe and secure and whenever possible 24/7 accessible (yeah you heart me !), not even touching the subject of interest here …
And DevOps and CD sounds fine, but in practice, it – regularly – hollows out to just focusing on burning down user-stories and the burn-down-rate, leading to a drop in quality, performance, and security, creating (more) technical debts and a false sense of maturity-level from both the dev as the ops-side. You’ll need senior techies that speak their mind to compensate for the pushy culture of business-leads that are used to always getting things done their way – which by the way SCRUM is actually promoting – but you never anyone talking about that; since it doesn’t match their happy-flow state of mind ….
Hi OverHyped
Thank you so much for taking the time to react on our post! We are actively looking for feedback. And also nice to see that you have the same strive as we do: namely the best to serve our customers.
We do understand your critical comments too as this a major change indeed for any organization, big or small.
We feel however, that these major changes (into agility) are necessary for exactly that one goal: to keep being able to adapt to customers changing needs at the pace of modern days. We think that moving towards a flexible organization with streamed, simple and safe processes and products is best for our customers. And most importantly, introducing a quick feedback loop to look back and take corrective actions when necessary so we can always change course.
Please keep providing us feedback and we will keep you posted on our journey!
Hello Overhyped,
Reading your comment and being a fan of scrum/agile I wonder whether “You’ll need senior techies that speak their mind to compensate for the pushy culture of business-leads that are used to always getting things done their way” could be solved by senior technical business-leads; wouldn’t that help? I think a lot of business nowadays is techie.
Regards
Fred
Hi Fred,
Totally agreed, a good team-/project-/program-lead/manager could make all the difference and is – imho – still absolutely necessary for success, but many organisations use management-trainees and/or swap-out project-managers/leads regurarly which usually leads to issues (for example when they don’t understand the technology enough or a simply no (experienced) people-managers.
The real issue here is that SCRUM as a methodology sometimes is misinterpreted/abused as a ‘modi operandi’ that will solve these ‘people dependencies’ unconditionally whilst in the end, imho, it’s always about the team and corporation, whatever methodology is used.
Not a single methodology solves the problem of not having the right people in the right place at the right time to delivery the stuff you want as a company for your customer.
What Agile does compared to the other (or older) ways of working is that it deliveres feedback really fast.
Not only about the product (or the quality of it), but also about the progress, the team and the impediments and the dependencies they have. Essential information. For the team, the management and all the stakeholders.
For someone who really had some question marks (earlier I had a earmark saying I was a test specialist) with the changed way of working (how do we ever going to assure quality if we have to do everything in such a short time in this complex environment?) I’ve experienced we can cut waste, building things sooner and better (first time right) and really focus on the customer experience for the whole process instead of a big program of x months on one system. And that various specialties (analist, programmer, tester, ops guy etc) in one team really gets the best out of everyone. I believe in a Agile way of working, and I would really have a difficult time if I need to go back to a ‘traditional waterfall’