When does it make sense to use the Spotify model for your software engineering project?
This article will explore the concept of Squad-based product development (a.k.a. the Spotify model) and seek answers to the questions of when it makes and doesn’t make sense to use it.
Waterfall is a very linear approach to building products. Much of the work is done upfront, with product managers working in a clear sequence of steps. First, they plan, design, and document just about anything they can think of concerning software product development. When done, they pass this documentation on to their developers for execution.
And while it is still a popular methodology in some large software development organizations, primarily because it allows for fixed scope, strict deadlines, and close managerial control, waterfall has a few drawbacks. Lack of change-making flexibility, poor focus on the end-user, delayed testing, and QA are just some of them. Therefore, in many software development organizations, waterfall product development has given way to agile development.
Agile development methodology emphasizes people over processes and communication and testing over documentation. When it comes to flexible thinking, this model encourages cooperation and proactivity. Within this model, success is defined by a working product and the user, not strict adherence to documentation and stages of development.
This is where the concept of product squads comes in as a relatively novel way of Agile method optimization.
Spotify is the world’s largest and most popular audio streaming subscription service, with around 286 million users. A key part of its success is due to the company’s unique approach to organizing teamwork and increasing team agility. As Spotify’s engineering teams went down the path of increased agility, they documented their experiences, shared them with the world, and ultimately influenced how many tech companies organize their work today.
In some ways, Spotify’s approach to product development teams is the next logical step in further optimizing the agile method.
Just like a Scrum team, a Squad is a cross-functional, autonomous team (usually 6-12 people) that focuses on a single functional area. Each squad has a unique mission to focus on, an assigned agile coach to support them, and a product owner to guide them. The groups determine which agile methodology/structure to use for project delivery and management.
Product squads are responsible for the functional areas of a certain company’s technology product; they do not work with all products or individual projects assigned by management. For example, one squad may focus exclusively on machine learning, which allows the company to accumulate significant experience and intellectual capital in each functional area of this technology. In other words, using squads, you can build teams of real industry experts rather than one big team of programming generalists.
Another way product squads differ from traditional approaches to product development is that they are given real autonomy and can be considered standalone, independent startups.
In practical terms, the squad can choose the areas of functional responsibility on its own. Once it gets into that area—again, machine learning, for example—it can upgrade the production version of your tech product at any time and propose solutions without waiting for the approval of anyone outside the squad.
The basic idea is that squads can lead to much more efficient product development, speed up development cycles, and ultimately improve the quality of delivery and user experience.
Squads work with epics – groups of related user stories that describe higher levels of system functionality. An epic is the smallest element of implementation responsibility. The organization may use Kanban or other agile methods to manage and maintain the epics’ backlog, but the backlog must be continually updated and reprioritized daily.
One way to scale user stories is to make them implementable by pair programming – another distinctive feature of Squad-based development.
When all code is written in pairs, it is subject to constant code review, reducing or eliminating formal code reviews. The daily rotation of programmer pairs spreads knowledge about the system’s individual elements throughout the squad. The code is constantly read, reviewed, and revised as new user stories are implemented.
This practice has the added benefit of reducing dependence on any individual squad member. The use of pair rotation with test-driven development allows any squad member to confidently participate in a pair.
Pair programming can be a key benefit of the squad model for large organizations. As a squad gains experience and maturity, you can split it into two or more squads.
The senior member of the squad becomes the leader of the new squad, consisting of a few original squad members and a few newly trained developers. A new squad starts working on a new chunk of scope. The original squad also involves new developers to gain experience with the squad code as they work on epics in the original or linked snippet. Thus, the squad can grow quickly into a Tribe.
In the squad model, the use of automated testing, test-driven development, and pair programming means you don’t need a robust testing workforce embedded into the team. Testers can become developers instead of acting only as a tester, while others use their deep domain knowledge as product owners.
Teams should follow test-driven development practices. Test-driven development requires you to write a test before writing code, using the concept of tests as specifications. This practice ensures that any member of the squad can understand the code. If developers can read the functional test suite, they can understand how a particular piece of code is implemented.
The test suite developed with this practice should cover all major forms of testing required: functional, user interface, and performance. Full implementation of automated testing can greatly improve code quality and significantly reduce the time spent on manual tests.
There is still a need for a smaller, more specialized testing team to conduct types of testing that require specialized skills, such as cross-device mobile testing, security, and end-to-end performance testing.
Image courtesy of Spotify
The organizational benefits of adopting the Spotify model include:
Since squads are authorized to release product updates directly to the market at any time, they can learn more quickly what works and what doesn’t. This can lead to autonomous improvements and help define faster if the product is working or needs to be fixed.
In a squad, a product manager has many more opportunities to learn about their functional area than when/if they are in charge of the entire product. For example, your product owner can become the ultimate technology expert on how machine learning or IoT can be used to improve product quality and overall user experience, generate new best practices and use cases, and stay on par with the industry trends.
By assigning squads to additional areas of functional responsibility across the entire product line, you can provide a wealth of knowledge to both product owners and developers. In fact, this can be a key differentiator for your business because your competitors will most likely still be using the everyone-works-on-everything model.
The Spotify model focuses on organizing work, not necessarily processes and ceremonies. This gives the organization much flexibility regarding how squads work. Instead of requiring squads to change how they do their job (e.g., “you have to scrum”), it focuses on aligning them with each other and achieving individual team results.
The Spotify model encourages autonomy and creativity by trusting people to do the work they see fit. It focuses on decentralizing decision-making and transferring responsibility to squads.
The Spotify model can increase the transparency of the work and expand the experimental approach to problem-solving in a high-trust environment. This can lead to things like better products, happier customers, and more engaged employees. However, not everyone will experience these results.
There are several legitimate reasons why product groups might not make sense for your organization.
In an agile context, the primary role of a product manager is to inform developers about the user personas and the problems the product needs to solve for those personas. In other words, product managers must have a complete understanding of the product as a whole.
However, if you break down your resources into functional area squads, you’ll essentially share overall product knowledge at a strategic level across multiple product owners. While they can become consummate experts in their respective functional areas, these product owners will most likely not have a complete strategic understanding of the entire product and its lifecycle. It can be risky for your project’s success.
Also, by making your developers hyper-specialists in several functional areas, without allowing them to work on other projects from time to time, you risk isolating the talent from the bird-eye view of your product. So if your squads don’t interact well and often with each other, you risk getting an information bunker.
Because the product squad approach was developed and popularized by a SaaS company, it’s best-fit for Cloud-based projects.
What if you have several related products, and they are built so that an update to one part of the product can affect other parts?
You probably wouldn’t want to restructure your product development and management team into squads because their updates might compromise the stability of the rest of the product.
Also, if your product has many interdependent components, you will often have cases where one squad will have to wait for support from another squad. And that, in the first place, would eliminate much of the value of working in the squad.
One more reason why squad-based development may not work for you is that the success of a product often depends on maintaining some distance and objectivity between product management and development. The product owner must focus on the vision, strategy, and roadmap, while the development team must focus on execution.
Developers will be motivated to solve their tasks as quickly and efficiently as possible. But sometimes, the product manager will have strategic reasons for pursuing an initiative in a predetermined way that may be against the way the development team is thinking.
But suppose the product manager is on the same team as the developers. In that case, you run the risk of them not asking for X because they know that the framework will make it easy to implement Y within their team’s functional area of responsibility.
The same potential problem exists when assigning a product manager to a development team.
A product is more likely to succeed when both product managers and developers strongly advocate for what they think is best for it, even if it creates some tension between both teams.
Product squads are a great way to build strong and knowledgeable development teams.
They also offer what is arguably the best development environment, allowing companies to build and release products quickly and efficiently and then improve them based on user feedback.
Moreover, they seem to be a logical extension of the agile philosophy. Indeed, one of the most important agile principles is: “Self-organizing teams create the best architectures, requirements, and projects.”
And remember, agile development itself is all about doing what works best, not sticking to any development process or rule.
If the product squad approach is right for your organization, it might be worth a try.
But if you’re not sure to what extent your product can handle independent updates at different times, or you’re worried about sacrificing general product knowledge to build your organization’s functional experience, then you might want to take a deeper dive into the squad method first. Implementing the wrong product development strategy can create more problems than it solves.
We at rinf.tech have been building Managed and Dedicated Dev Teams and Squads for other businesses across different industries for 15+ years now. Over this time, we've learned important lessons, and accumulated best practices and tribal knowledge, which makes us well-placed to guarantee your software project success. Contact us to learn more.
When should businesses consider legacy application modernization, what benefits can an application modernization strategy bring, what alternatives to consider, and how to approach a modernization project.
Delving into the intricacies of legacy modernization and how to deal with a tech debt.
Delving into the top 10 trends influencing DevSecOps adoption in 2024, each highlighting how security is becoming more integrated, automated, and essential in the SDLC.
