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

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

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.

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”.

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.

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

Product owner - The squad has a dedicated product owner that prioritizes the work

Agile coach - The squad has an agile coach that helps them identify impediments and coaches them to continuously improve their process

Influencing work - Each squad member can influence his/her work, be an active part in planning and choose which tasks to work on.

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. 

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.

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...).

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

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.

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”.

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

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.

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.

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”.

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

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.

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.