One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities. Spotify is a fascinating company that is transforming the music industry.

Dealing with multiple teams in a product development organization is always a challenge

There is a downside to everything, and the potential downside to full autonomy is a loss of economies of scale. The tester in squad A may be wrestling with a problem that the tester in squad B solved last week. If all testers could get together, across squads and tribes, they could share knowledge and create tools for the benefit of all squads.The chapter is about your small family of people having similar skills and working within the same general competency area, within the same tribe

Chapters

All systems have a system owner, or a pair of system owners (we encourage pairing). For operationally critical systems, the System Owner is a Dev-Ops pair – that is, one person with a developer perspective and one person with an operations perspective. The system owner is the “go-to” person(s) for any technical or architectural issues related to that system.He focuses on things like quality, documentation, technical debt, stability, scalability, and release process.

System Owner

Squads are encouraged to apply Lean Startup principles such as MVP (minimum viable product) and validated learning. MVP means releasing early and often, and validated learning means using metrics and A/B testing to find out what really works and what doesn’t. This is summarized in the slogan “Think it, build it, ship it, tweak it”.

Squads are encouraged to apply Lean Startup principles

Spotify technology is highly service-oriented. We have over 100 distinct systems, and each can be maintained and deployed separately. This includes backend services such as playlist management or search or payment, and clients such as the iPad player, and specific components such as the radio, or the “what’s new” section of the music player

What about architecture?

To promote learning and innovation, each squad is encouraged to spend roughly 10% of their time on “hack days”. During hack days people do whatever they want, typically trying out new ideas and sharing with their buddies.

Hack days

A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches.

Squads

Ideally each squad is fully autonomous with direct contact with their stakeholders, and no blocking dependencies to other squads.

Each squad is a mini-startup

The product owner is responsible for prioritizing the work to be done by the team, but is not involved with how they do their work. The product owners of different squads collaborate with each other to maintain a high-level roadmap document that shows where Spotify as a whole is heading, and each product owner is responsible for maintaining a matching product backlog for their squad.

A squad doesn’t have a formally appointed squad leader, but it does have a product owner

A tribe is a collection of squads that work in related areas – such as the music player, or backend infrastructure.The tribe can be seen as the “incubator” for the squad mini-startups. , and have a fair degree of freedom and autonomy. Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe. The squads in a tribe are all physically in the same office, normally right next to each other, and the lounge areas nearby promote collaboration between the squads.

Tribes

Most people cannot maintain a social relationship with more than 100 people or so (the number is actually larger for groups that are under intense survival pressure, which isn’t really the case at Spotify, believe it or not...).

Tribes are sized based on the concept of the “Dunbar number”

A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices. Chapters are always local to a Tribe, while a guild usually cuts across the whole organization. Some examples are the web technology guild, the tester guild, the agile coach guild, etc.

Guilds

Our matrix is weighted towards delivery.That is, people are grouped into stable co-located squads, where people with different skill sets collaborate and self-organize to deliver a great product. That’s the vertical dimension in the matrix, and it is the primary one since that is how people are physically grouped and where they spend most of their time.

People are grouped into stable co-located squads

The horizontal dimension is for sharing knowledge, tools, and code. The job of the chapter lead is to facilitate and support this.In matrix terms, think of the vertical dimension as “what” and the horizontal dimension as “how”. The matrix structure ensures that each squad member can get guidance on “what to build next” as well as “how to build it well”.

The job of the chapter lead

He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership. However, from time to time he will take a “system owner day” and do housekeeping work on that system. Normally we try to keep this system ownership to less than a tenth of a person’s time.

The System Owner is not a bottleneck or ivory tower architect

Building and improving the Android client, creating the Spotify radio experience, scaling the backend systems, or providing payment solutions.

Each squad has a long-term mission

A synchronization meeting where one person from each team meets to discuss dependencies. We don’t usually do scrum of scrums at Spotify, mainly because most of the squads are fairly independent and don’t need such a coordination meeting.

Scrum of scrums

Dependencies are not necessarily bad - squads sometimes need to work together to build something truly awesome. Nevertheless, our goal is to have squads be as autonomous as possible, especially minimizing dependencies that are blocking or slowing a squad down

Squad dependencies

Product owner - The squad has a dedicated product owner that prioritizes the workAgile coach - The squad has an agile coach that helps them identify impediments and coaches them to continuously improve their processInfluencing work - Each squad member can influence his/her work, be an active part in planning and choose which tasks to work on.

Quarterly survey with each squad to measure improvements I

Easy to release - The squad can (and does!) get stuff live with minimal hassle and sync. A process that fits the team - The squad feels ownership of their process and continuously improves it. Mission - The squad has a mission that everyone knows and cares about, and stories on the backlog are related to the mission. Organizational support - The squad knows where to turn to for problem-solving support, technical issues as well as “soft” issues.

Quarterly survey with each squad to measure improvements II

Their job is not to make releases for the squads - their job is to give the squads the support they need to release code themselves; support in the form of infrastructure, scripts, and routines. They are, in a sense, “building the road to production”.

At Spotify there is a separate operations team

motivationandinspiration

Motivation & Inspiration

education

Learning & Education

Scaling Agile atqparameters = {'client_id': settings.UNSPLASH_ACCESS_KEY, 'query': a.title}
response = requests.get(settings.UNSPLASH_API_URL + '/search/photos', params=parameters)
 Spotify

The System Owner is not a bottleneck or ivory tower architect

Similar ideas to The System Owner is not a bottleneck or ivory tower architect

System Owner

System? Or Goal?

Writing a book: Getting started