My Experience on Spotify Agile Methodology

I recently said that I worked in a British Television Broadcasting, Sports, Internet and News giant last year, where I was a part of a scrum team and the team worked in a Spotify Agile Model. In my experience, this is the best agile model I worked on. So, I thought of giving my personal experience about how this works and how we can effectively make use of this methodology in our workplace to get the best results.

Contents

• Introduction to Spotify Agile Methodology
• Teams in Spotify Work Culture
  • Squads
  • Tribe
  • Chapter
  • Guild
  • Examples
• Alignment vs. Autonomy
• Our Stack
• The Approach
  • Sprints
  • Team
  • Sprint Planning
  • Daily Stand-ups
  • Coding Standards
  • Backlog Refinement
  • Sprint Review
  • Sprint Retrospective
• Summary

Introduction to Spotify Agile Methodology

This is the awesome culture that’s happening in Spotify, a music, podcast, and video streaming service. They have an agile development model for their software engineering team and they have defined their own set of rules, based on their experience and to be precise, they don’t have a set of defined rules. Their point is to have rules at the start and later break them (or adapt according to the team’s needs).

Another interesting thing is that, they didn’t like the default roles in scrum. They have renamed the Scrum Master to Agile Coach, as they wanted "servant leaders" more than "process masters". And yeah, no more Scrum teams, instead, they call it Squads.

They have a little or no standardisation of processes - they don’t have a formal standard, and they believe that cross-pollination is better than standardization. Say, if many people from the company found some tool very comfortable and useful, and that tool becomes a path of less resistance, then the other squads use the same tool. This way, something dynamic becomes a standard.

Teams in Spotify Work Culture

As in any agile scrum model, there are different types of teams in Spotify. In contrast with the generic scrum naming convention, they have different dimensions. Let’s look at each type of team, what they do and how they function in detail. Moreover, their culture is more sharing than owning.

Squads

It’s a small cross-functional self-organized team with usually less than 8 people. They have end-to-end responsibilities and they work together towards their long-term mission. With Squads, the key drive is autonomy.

Each Squad has autonomy to decide what to build, how to build it, and how to work together while building it. Although they need to be aligned to the Squad mission, product strategy, and short-term goals.

A leader communicates the problem that needs to be solved. A leader’s responsibility also includes explaining why the problem needs to be solved. Now it’s the turn of squads to collaborate with each other to come up with the solution. And yes, squads do communicate with other squads to find the best solution.

Tribe

It’s a little weight matrix. It’s a primary dimension focused on product delivery and quality. These are a collection of squads within the same business area, for example, there could be a tribe focusing on mobile. The squads within a tribe sit in the same area, and there are usually 100 or less per tribe.

Chapter

This is a set of people, who focus on the competency areas such as quality assistance, agile coaching, designing or web development.

Guild

This 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 anytime. It is a community of interest by mailing list or another informal type of communication methods inside Spotify.

Examples

Let’s take this gaming company as an example and see how is their team organised as:

Clans

Teams

Guilds

Alignment vs. Autonomy

Autonomy provides employees with a sense of collective ownership. They are part of a greater whole, active members (rather than passive) of the team, "making a positive overall contribution to the organization" - Griffin and Moorhead, 2008.

People work with autonomy, mastery, and purpose. Autonomy is motivating, and motivated people build better stuff, and also faster. Autonomy makes us faster by leading decisions happening locally instead of managers and committees.

Alignment enables autonomy. It’s important that everybody understands the company/start-up culture. The stronger alignment we have, the more autonomy we can afford to grant. Autonomy with alignment increases motivation, quality and also fast releases.

Spotify aims (trying hard) to be up on the high alignment with high autonomy and they keep experimenting with different ways of doing that. Here leaders focus on what problem needs to be solved and the teams figure out on how the problem needs to be solved. This way, alignment enables autonomy. The stronger alignment they have, the more autonomy, they can afford to grant.

Our Stack

Coming back to the huge or British giant, we had a crazy setup of architecture. We had the following stack:

• Development Type: Test Driven Development
• Client Interface: Own CSS Framework & Fonts
• Application Server: Apache & nginx
• Programming Language: PHP & Python (they both had separate repositories)
• Database: PostgreSQL
• Environment: Vagrant LAMP Stack
• Repository: GitLab (using git version control system)
• Scrum & Issue Tracking: Atlassian JIRA
• Unit Testing: PHPUnit (yeah, it kinda sucks to write test cases)
• Continuous Integration: GitLab CI (using composer.json for PHP)

The Approach

This concept works well if you have a quite large organization, and you have mature scrum teams. Spotify was born an agile company, so most of these things are sewn into their DNA, but for companies or teams transitioning to scrum it can be a lot more difficult, this concept needs a lot of buy-in and motivation from the team. Although you might not be able to implement this model, there are some things that you can take away from it. Keep reading. We do this as in every agile scrum environment.

Sprints

The heart of a scrum team is a Sprint, a time-box of two week to a month during which a completed, usable, and potentially releasable product milestone is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

We do the two-week sprints and make sure we set SMART goals. Goals that are specific, measurable, assignable, realistic, and time-bound. Typically, a sprint runs for two weeks and it starts from Monday, and ends on Friday, a week later. Also, we take care during the sprint we’ll not update the Sprint Backlog that would jeopardize the Sprint Goal.

Team

Our scrum team is a complete team, where each developer pays two roles. Being a full stack developer, you can often find me in both Front & Back End Development teams. We have our teams with the following skills:

• Front End Developers (that’s where I am)
• Back End Developers (I do this as well)
• Dev Ops (occasionally I help these guys and learn a lot from them)
• Quality Assurance (ah, the tragedy, we wage wars, the dev-tester wars)
• Business Analysts (gotta learn the excellent negotiation skills from these people)
• Scrum Master & Product Owner

We have split into two teams with each of the team having a fair share of resources and there are kinda chapters across teams too. Generally, we have two "tribes". This has become the de-facto standard across all the teams till now.

The right Development Team size should be small enough to remain agile and large enough to complete substantial work within a Sprint. Fewer than three Development Team members reduce interaction and results in smaller productivity improvements.

Smaller Development Teams may come across skill constraints during the Sprint, causing the Development Team to not be able to deliver a potentially releasable milestone. Having more than eight members requires too much management and synchronisation. Large Development Teams cause too much complexity for a pragmatic process to be useful.

Note that the Product Owner and Scrum Master roles are not included in this count unless they are also implementing the work of the Sprint Backlog.

Sprint Planning

We start (or end) the sprint with a sprint planning session that goes on for about half a day. The whole team will be involved in this task and are already aware with the items from attending Backlog Refinement, and therefore can focus on further detailed explanation, frivolous modelling or conversation, re-estimation, creation of the Sprint Goal (an objective set for the Sprint that can be met through the implementation of Product Backlog), and the Sprint Backlog.

Daily Stand-ups

We host a daily 15-minute stand-up in the common area. In some of the teams, we do it by sitting (it’s a crime in my current scrum team). Generally, there will be a team member from another team, so that both the teams are updated of what’s happening between the two (or more) scrum teams. This makes a whole half an hour of morning times interesting, as we sometimes host competitions like who’s the best person to say in an interactive way and not a status update, but keeping it short and crisp on the following:

• What did I complete yesterday?
• What will I work on today?
• Am I blocked by anything?

If there are any blockers, the team will be able to reach out and offer help, if it is in their area of expertise or if they have the subject matter.

Coding Standards

This is the main point of writing this story. I really wanted to stress the best way, moving forward with any scrum team with my collective experience that I had from my previous and current scrum teams.

• Update the JIRA ticket status from Backlog or To Do to In Progress.
• Pull the latest code from development branch.
• Create a new feature branch from the updated development branch.
• Start working on the new feature in your newly created feature branch.
• Make sure your code complies with PHP FIG PSR-4 Standards (this is related to the current project, so may or may not apply to other projects).
• Create one or multiple commits, prepending the JIRA ticket.
• If the remote branch is already updated in the meantime, do a pull --rebase from the remote, then you’re your feature branch with the new commits.
• If the remote branch is not updated with new changes, just push new feature branch with the new commits.
• Create a merge request in GitLab, and get votes from every member of the chapter, say UI team.
• Add a comment in the JIRA item with the screenshots and merge request link.
• Merge the branch with the development branch, if there are no merge conflicts - mostly this won’t happen if it’s rebased and pushed, or if the branch is not updated in the meantime.
• Merge the code to development branch in the repository and make sure graph looks straight.
• Update the JIRA ticket status from In Progress to Ready for QA / PO / Done / Release.
• Pull the latest code from remote development branch to your local branch after the push or before you start branching out to create your feature branch.
• Start with the next task by following from the point 1.

I have detailed about the steps for pushing and merging in git in a granular way in Git Standards followed in our way of Spotify Agile Methodology.

Backlog Refinement

Some teams will also say this as Backlog Grooming. The term grooming has been discouraged since the word has bad connotations, but it is still widely used. At this meeting, we all as a team along with the Business Analysts, Product Owner and Scrum Master, we will make sure that the Backlog is up-to-date by making sure all the tasks are valid, has the right Acceptance Criteria, and re-prioritising as appropriate, adding new stories and removing anything that is never going to be done. Generally, this will be done by the Product Owner alone, but we planned to do it together so that we all are aware about the situation of the project.

Sprint Review

The Sprint Review happens at the end of the sprint. This will be yet again a half day meeting with the whole team, along with the clients, stake-holders, and account managers involved in the project. Our product owner explains what Product Backlog items have been "Done" and what has not been "Done". We as the development team, discuss what went well during the Sprint, what problems we ran into, and how we solved those problems.

We do have a Show & Tell session, where we demonstrate the completed items during the sprint. This goes with the UX & UI team (my team) first, explaining what all we promised vs. what we achieved. Then the development team presents their updates and if there are any demonstrations possible, they do it too.

This will be followed by the QA team automating stuff. It would be magical to watch the mouse pointer moving and keyboard typing automatically. Following which will be the DevOps team speak some jargon that not a single person will be able to understand (Sorry DevOps, but yeah, I understand DevOps and I’ll definitely support your team later).

Every time when this happens, it’s my team, the User Experience team rocks as we show some colourful demos.

Sprint Retrospective

This happens at the end of a sprint, where the development team, scrum master, product owner and all the other team members (DevOps, QA and BA) meet and discuss about the following:

• What went wrong?
• What can we do better?
• What not to do?

This would be a retrospective learning part for all the team members to understand and become aware of the whole scenario as a team and document the wrong elements that happened and review it at the next iteration, to make sure it didn’t happen again. We use our retrospectives to find out what's working, so the team can continue to focus more on those areas. Also, we find out what's not working and use the remaining time to find better creative solutions and develop an action plan.

Summary

Agile Scrum methodology can be embraced probably not only in the software engineering model but also everywhere. I use an agile methodology for my home tasks - cooking, that’s not anywhere related to software development. So let’s embrace this methodology and work great!