The Spotify Squad Framework — Part II
Continuing the post about Spotify Product Development, I will write about Part II of their video and why I felt completely in love with Spotify again (!). They’re a 100% Agile company and in the beginning they followed the Scrum framework then they switched to Squad. At Spotify, all the engineering teams work in Squads, where they try to be loosely coupled and tightly aligned.
I wrote a post based on the Spotify Product Development video Part I, where I explained more about their culture. If you didn’t have the opportunity to watch the video or the post, check it out here!
Failure
We aim to make mistakes faster than anyone else — Daniel Ek*, Spotify founder. The idea behind it is that along with the product development cycle, we’re going to make mistakes and this is inevitable. So, why not fail faster when we do fail? Each failure is also an opportunity to learn and validade our learnings! It’s a strategy for long-term success.
*Daniel Ek, Spotify founder grew up in Rågsved, Stockholm, Sweden. He graduated from the Royal Institute of Technology (sv) in Sundbyberg in 2002, and subsequently studied engineering at the KTH Royal Institute of Technology before dropping out to focus on his IT career.
Spotify is more interested in fast failure recovery than failure avoidance because failure without learning is just failure and they’re not interested in that. They are so super serious about it that some Squads have a “Fail Wall” to share their failures, which gives everyone the opportunity to learn from other failures.
Spotify: Fail-friendly Environment
- It’s never about who’s fault is it; t’s about what happened.
- What did we learn?
- It’s about what will we change?
Fail fast > Learn fast > Improve fast!
Postmortem Documentation
It’s a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that were successful or unsuccessful. It’s a process of lessons learned and improvements which mitigate future risks.
“Fix the process not just the product”
The ticket is not closed when the problem is solved. It’s really just closed when they capture the learnings to avoid having the same problem in the future.
Continuous Improvement
The Squads have retrospectives every few weeks to talk about what went well and what to improve next. The continuous improvement is driven from below and supported from above.
Limited Blasted Radius
The limited blasted radius gives Squads courage to do lots of small experiments and learn fast from them, instead of wasting time predicting and controlling all risks in advance.
- Via decoupled architecture: Using decoupled architecture, if any Squad makes a mistake, the only area impacted will be a small part of the system. It won’t break everything down. Since every Squad has end-to-end responsibility for their stuff without handouts, they can fix the problem very fast.
If everything is under control, you’re going too slow! Mario Andretti
- Via gradual rollout: Using gradual rollout, most of the new features are rolled out gradually. It starts with a tiny percent of users and is closely monitored. Once the feature proves to be stable, Spotify will gradually roll it out to the rest of the world. So if something goes wrong, it normally affects very few end-users for very short periods of time.
Product Development
The biggest risk is always building the wrong thing, so before deciding to build a new product or mature feature, they try to inform themselves with research if people actually want this product, and if this solves a real problem for them. Then they find a narrative, press-release or elevator pitch showing off all the benefits and later on they build a prototype. When people try the prototype, they get a sense of how this feature should feel and then people react to it.
Think it, build it, ship it, tweak it! — Lean Startup
Once Spotify feels comfortable with that thing and feel it is worth moving forward, they go ahead and build an MVP (minimum viable product) just enough to feel the narrative, but far enough for the feature to be complete. The next stage of learning happens when they put the product into production, to get it as soon as possible, to release the MVP to a few percent of the final users, using techniques like A/B test to measure the impact and then test the hypothesis. This process is called Analyze Data. They continue monitoring the data and tweak it until they see the desired impact. Then they gradually rollout to the rest of the world. Or take the time needed to sort out practical issues like operational issues and scaling.
How do they know if it will be a success?
The answer is super simple; if it isn’t a success they won’t roll it out! Smart, huh?
Impact > Velocity
How does Spotify Plan?
They don’t have a lot of planning and usually, they care more about innovation than predictability, and they feel 100% of predictability means 0% of innovation. Of course, this isn’t fixed, and sometimes Spotify needs to do some delivery commitments to partner integration or marketing events.
Value Delivery > Plan Fulfillment
If they have to make a commitment they prefer not to promise a date, instead, they prefer to do the commitment when the feature is already proven and close to be ready. Minimizing the need for predictability, Squads can focus on delivering value instead of being slaves of someone arbitrary plan.
“I think of my Squad as a group of volunteers that are here to work on something they are super-passionate about” — Spotify employee.
Hack time
An amazing product idea starts with a person and an inspiration. It only becomes real if the person is allowed to play around and try things out. So Spotify encourages everyone to spend 10% of their time doing hack days or hack weeks playing around and experimenting.
Hack week mantra: make cool things real!
It doesn’t matter if the idea is useful, the point is, if you try enough ideas, you’re bound to strike gold to time to time. The knowledge is worth more than the hack itself.
Build whatever you want. Do whatever! With whomever! In whatever way! Spotify has a Demo + Party on Fridays and they’re always surprised by how much cool stuff can be done in just a week. Innovation isn’t that hard. People are natural innovators so just get out of their way and let them try things out!
Experiment-Friendly Culture
With an experiment-friendly culture, people are allowed to test and experiment new things, and this creates an environment based on data-driven decisions instead of an opinion-drive, ego-driven or authority-driven environment.
Waste Repellent Culture
People will quickly stop to do anything that doesn’t add value at Spotify. They also avoid big projects and anything that needs a lot of Squads tightly coordinated for many months. Big projects also mean big risks, so they’re organized to minimize the need for big projects. Instead, they try hard to break the big projects into smaller efforts.
“If it works, keep it. Otherwise, dump it!”
Of course, there are exceptions and they are aware of it! Spotify uses some practices to minimize the risks of a big project.
- Visual progress in a physical or electronic board like Kanban;
- Daily sync meeting with all Squads involved meeting up to resolve dependencies;
- Weekly demo where all the pieces come together to evaluate integrated product together with stakeholders.
These practices reduce risks and waste because of their improvement collaboration in a short feedback loop.
Leadership Group
Spotify also felt a need for a small type of leadership group to keep an eye on the big picture with a tech, product, and a design lead.
Growth Pain
What’s the minimal viable bureaucracy? Their goal is to get the least structure and bureaucracy in place to get away from total chaos. Both sides, bureaucracy and chaos, cause waste in different ways. The waste repels culture, and Agile mindset helps them to stay balanced.
Improvement Boards
The key to reducing waste is to visualize it and talk about it. What’s blocking? What are they going to do about it? These are some common questions to ask.
Definition of Awesome
Being awesome helps improve their focus efforts and track progress Each Squad has a definition of awesome that can be built, tested, and shipped quickly, sometimes within a week. It doesn’t have to be realistic, it can be what they agree awesome looks like.
Failing is perfectly OK as long as we learn and validate our learnings! Healthy culture heals broken processes. Grow fast, change fast, be brilliant Spotify!
Want to learn more about agile? Check this website Agile Videos, they have a great collection of videos covering the main aspects of Agile.
Books to Read
Additional Resources
Update, June 8, 2020:
I learned about this article and I wanted to share it with you too:
👋 Feel Free to Clap and Share your Thoughts!
Find more at our LinkedIn, Instagram, and Twitter. Check our podcast. Follow our LinkedIn page and Newsletter!
Disclosure: At PM101, we strive to provide our readers with valuable and honest information on Product and Program Management. As a way to support the blog and continue providing valuable content, some blog posts may contain affiliate links or promotional content. By clicking on these links and making a purchase, the writer may receive a small commission at no additional cost to you. This commission helps to keep the blog running and allows the writer to continue providing valuable content and increasing her coffee and kombucha consumption. Rest assured, we will always provide honest and informative content and use affiliate links and promotional content only as a means to generate revenue to support the blog.
