Spotify Agile Framework: Case Study
By: Raheenul Hasan
Tags: Spotify, Framework, Agile Methodology

Case Study: Spotify Agile Framework

URL: https://www.youtube.com/watch?v=ar4lq1l8pAc — Spotify Model & Culture — a true story? By Fredrik Wendt

URL: https://www.youtube.com/watch?v=Yvfz4HGtoPc- Spotify Engineering Culture — Part 1 — by Henrik Kniberg

URL: https://www.youtube.com/watch?v=vOt4BbWLWQw — Spotify Engineering Culture — Part 2 by Henrik Kniberg

A. Spotify Revenue growth

Spotify makes 91% of its income from subscriptions and the other 9% from advertisements. Of the income it produces, Spotify keeps 30% and parts the rest of the sum between authorizing, music arrangements and paying to the artists.

Reports of artists being disappointed with their profit have come forward a number of times.

Spotify has 3 plans on offer.

• The free version gives you unlimited ad-supported streaming, shuffle-only playback of songs on mobile, access to podcasts and videos. The web has access to on-demand access.

• The premium rendition for $ 9.99 (4.99 for understudies). It includes disconnected tuning in, eliminates promotions and on-request versatile (Access to individual songs rather than just radios).

• The family form for $ 14.99 gives you 6 records (from a single country) adequately making it $ 2.5 per account. The restriction is that all family members should reside in the same address.

B. Spotify business

Spotify has little normalization; it doesn’t have a conventional norm. They accept that cross- pollination is better than standardization. For instance, when enough Squads utilize a certain instrument, that device turns into a way of less opposition and different Squads will in general pick a similar device. After different Squads utilize a similar instrument, test it, and work together, at that point the instrument turns into a default standard.

Spotify employs an internal open-source model, their culture is more sharing than owning. In view of common regard and little inner self, Spotify has a companion code audit, where anybody can include any code at whenever. Then a peer can review the code and make adjustments. Everybody collaborates and spreads the knowledge. They also have a culture that focuses on motivation, which has helped them build a very good reputation as a workplace.

C. Spotify Engineering culture

The Spotify engineering culture is and centers around self-rule rather than arrangement. Spotify energizes a tight coupling of authoritative plan and design. This way Spotify seriously restricts the requirement for arrangement by zeroing in on making teams independent.

One of the enormous achievement factors in Spotify Engineering Culture is Agile Engineering. Culture will in general be imperceptible as it’s there constantly. In any case, on the off chance that we will in general get it, we can utilize it and fortify it.

D. Tribes, Squads, Chapters & Guilds

Spotify uses a complex system whereby people are encouraged to align themselves in communities which share their same objectives (squads), work environment (tribes), skillsets (chapters), and interests (guilds).

Tribe is a Lightweight matrix, a primary dimension focused on product delivery and quality. Each Squad is grouped into a Tribe. They also have a Guild, which is a community of interest that uses a mailing list or another informal type of communication method inside Spotify. In this environment, you can switch your Squad without changing your manager.

A Squad is a small cross functional self-organizing team. Usually less than 8 people. They sit together and have end to end responsibility for the stuff they build, like design, commit, deploy, maintenance, operations.

Chapter is a Group formed based on competency areas such as quality assistance, Agile coaching, or web development.

Guild is a lightweight community of interest where people across the whole company gather and share knowledge of a specific area. Anyone can join or leave a Guild at any time.

E. Team Autonomy and Alignment

Spotify maps organization cultures across a two-dimensional matrix that measures levels of autonomy on one axis and alignment on the other.

Autonomy basically means that the Squad decides what to build and how to build and how to work together while doing it. It is to motivate the people to build better solutions. Self-sufficiency makes fast output by making discussions internally within the Squads.

Alignment is grouping people for specific work in an entire job. The Spotify engineering culture focuses on autonomy instead of alignment. Spotify encourages a tight coupling of organizational design and architecture. This way Spotify severely limits the need for alignment by focusing on making teams independent. The decisions a squad takes must naturally align with the squad’s long-term mission, their internal goals, overall product strategy and other short-term goals which are reviewed every quarter.

F. Metrics

Understanding the Spotify measurements that an organization takes a gander at to assess the development of its foundation, in a way likewise features the vision that the organization has about its clients, its plan of action, and what it’s significant for its financial success. A set of metrics that Spotify looks at comprises:

· MAUs:

Spotify tracks MAUs as “an indicator of the size of the audience engaged with its Service.” This is defined as the total count of Ad-Supported Users and Premium Subscribers that have consumed content for greater than zero milliseconds in the last thirty days from the period-end indicated.

· Premium Subscribers:

Premium Subscribers are users that have completed registration with Spotify and have activated a payment method for Premium Service.

· Ad-Supported MAUs:

That is the total count of Ad-Supported monthly active users that have consumed content for greater than zero milliseconds in the last thirty days.

· Premium ARPU:

This monthly metric shows the revenue recognized in the quarter indicated divided by the average daily Premium Subscribers in that quarter, divided by three months.

· Premium Churn:

That represents the premium members’ cancellations in the quarter indicated divided by the average number of daily Premium Subscribers in that quarter, divided by three months.

· Content Hours:

That represents the aggregate number of hours. Users spent consuming audio and video content on Spotify.

G. Product development approach

Product development approach is based on Lean Startup principles and is summarized by the Mantra. Think it, Build it, Ship it, Tweak it. Each stage has its own purpose and the duration of each stage varies per project. Iterative Agile approaches are used within all stages, as well as for the whole framework. Depending on the type of software, each stage takes different times. “Test It” and “Re-Think It” is also brought into the picture. Testing is an integral part of delivery of end product. Re-Think phase is added to review the product at each stage and take the feedback loop.

H. Hack week

Hack Week is the time of year that we take to celebrate innovation and new thinking. Twice a year Spotify hosts a hack week where they let everyone work for a week on whatever they want. The approach unleashes creativity and improves cross-organizational collaboration. Most Spotify engineers from different geographical offices participate in the week. They use this opportunity to work on a problem or work on some fun feature. If a hack works, it might make its way into a test build of the app so that a small number of Spotify users can try it out and see if it works outside the engineering bubble.

I. Spotify employees’ satisfaction

In addition to enjoying a boost in creative output and employee satisfaction, Spotify’s autonomous work environment results in a diversity of agile practices and tools in use. Spotify’s Head of People claimed that 91% of employees enjoyed working at Spotify, which he said was not satisfactory, emphasizes on the importance of employee satisfaction and how it is important in the agile process. The organization’s administration group doesn’t authorize which agile practice to utilize and group leads don’t mention to workers what tools they should utilize. Spotify gives workers the opportunity to pick what will make them productive. This freedom gives Spotify a balance between consistency and flexibility.

J. Release planning, Big Project

Release Planning should be common and a routine and not hectic. Spotify focuses on making it easier to release code and releasing it more often. This is the opposite of the typical waterfall environment where releases are big, seldom happen, and can be painful. Each application at Spotify has a release train that happens at a regular interval. If a feature is not complete when the train leaves, the feature is used to shut it off. The feature toggles work to hide code in testing and production environments. This also helps alleviate issues with merging code as it is always checked in one place

Big Project: it 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, discard 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.