Using Atlassian suite to support the Spotify Agile model

The Spotify agile model has over the last few years gained a lot traction in the Agile community and many organizations are adopting it. In this post, I would like to take a closer look at the Spotify model and show you how you can leverage Atlassian tools – especially Jira and Confluence – to support a similar model at your organization.

The Spotify model was first introduced to the community through conference presentations and an excellent white paper by Henrik Kniberg & Anders Ivarsson entitled Scaling Agile @Spotify.

Here’s the visual representation of the model shared in the seminal white paper that made the Spotify model of agile organization into something recognized by the agile community.

As you can see, the model presents a way of dealing with multiple teams that operate in a single product development organization.

It might look complicated at first glance, but in reality it’s far from it.

Over the years, Spotify grew as an organization and scaled its operations to dozens of teams across multiple cities. It’s a challenge to have self-organizing Agile teams in fast growing environment. Spotify’s structure evolved into an organization model which comes across as an seemingly traditional matrix model but in contrast is geared towards delivery, agility, autonomous feature driven teams.

Let’s start with the basic unit – a Squad. A Squad is like a Scrum team and works like a startup. Team members are expected to have all the skills required for design, development, testing, and releasing software to production. It’s a truly self-organizing team that can use Scrum,Kanban, or a mix of both. A collection of Squads that work in related areas is a Tribe.

Lean startup principles are integral to the Squad’s way of working. The focus is on releasing early and often, and employing metrics and techniques like A/B testing to validate what works and what doesn’t.

The lean principles encourage “fail fast” approach where an MVP (Minimum Viable Product) helps to validate learning and quickly adapt the product to the business/customer needs.

Interestingly, a Squad doesn’t have a formal leader, but a product owner who prioritizes the team’s work, but has no power over how the team delivers that work. Product owners from different squads are in continual communication with each other to develop and maintain a high-level roadmap that offers a broader picture of the company’s direction.

Squads are autonomous units, but the downside of being completely autonomous can be lack of knowledge sharing among various squads. That’s where the concept of Chapters comes in. Chapters constitute of people with similar skills from every squad across a Tribe or even multiple Tribes. There can be a Backend Chapter which has backend developers from every Squad who get together to share knowledge and update each other on the interesting technical challenges faced/fixed in their field of work.

Now, the original Spotify white paper recommends to have one Chapter per tribe like a QA Chapter,  Frontend Chapter, etc. But, I have observed Chapters spanning multiple Tribes as well since that increases the scope of knowledge sharing and having everyone on the same page when it comes to specific technologies pertaining to that chapter. So it may vary from one organization to another. Also, the Chapter lead is responsible for performance reviews and other HR tasks for the members of their Chapter.

Then there are Guilds. The idea behind Guilds is a group of people sharing common interests (Agile, automation, etc) which can be spread across Chapters and Tribes. Teams and the Agile coach on board decide what kind of Guilds they want. They might not want Guilds when starting out with this model if you already have Chapters which cut across tribes.

Now that you know what the Spotify agile model is all about, it’s time to take a closer look at how Atlassian can help you implement some of its features in your organization.

Atlassian’s Jira Software supports both Scrum and Kanban – the two prominent Agile frameworks.

Based on the Spotify model, we’ll see how we can set-up our Jira projects, spaces, and boards taking into account the concept of Squads, Tribes and Chapters.

The idea is to recommend an approach which will help the teams to startup quickly with the tools – and of course, were there is enough room for improvisation. Factors like team’s maturity in terms of DevOps, continuous delivery, release management have an impact on the setup and configuration of these tools. Whether teams are collocated or distributed across the globe also plays an major role.

Each Tribe can be mapped with one Jira project, and while creating stories for the project we can select the Squad based on the field or Squad can be selected once refinement of the stories is done – either way story is mapped with a Squad by means of a custom field. Let’s suppose we have Squads named after cities like London, Paris, Amsterdam, etc. (you can also name them after team’s favorite beers 🙂 ).  

Creating an story will look something like this. We can choose the Squad either at the time of creation  or once the refinement is done.

Fig 1 – Create screen of an Story with a drop-down for squads

Now, we intend to use a combination of Scrum and Kanban. Dev teams that are working on delivering software features are better suited to work in time-boxed sprints i.e. Scrum and to employ other Scrum ceremonies like sprint planning, standups, and retrospectives along with demos involving all stakeholders. Whereas POs who are more concerned with prioritization of backlog and managing new business requirements as they arrive can leverage Kanban boards to refine the requirements and make them available as sprint backlog for the Scrum teams.

Here’s an overview of the complete workflow of an Story and how we can divide it into 3 parts

Fig 2 – Categorization of the story workflow in 3 parts

Part 1 of the story deals with it’s refinement, part 2 with development and part 3 with release.

Now, the idea is to have 3 separate boards for the entire flow, for part 1 we have the Kanban board for POs, part 2 we have an Scrum Board for the Squads, and for part 3 we again have an Kanban board for the release teams.

This is a generic opinionated approach and you might want to have it in a different way. For example, sometimes teams want to create a separate linked ticket for the release teams once the story reaches “sprint done” as release team might want the tickets to be part of their projects and thus the need of linked tickets in a separate project.

Also, depending on the Devops maturity of the Squad teams, the team might be doing the majority of the deployment and release work themselves with few insights from the Ops team and in this way just extending the development workflow of the story to incorporate part 3 (release flow). Thus, without the need of creating any linked ticket in a separate project.

Some Agilists also might not like the idea of having “QA” specific statuses in the flow and might want to replace them with QA specific sub-tasks or not have them altogether.

Because if the team is writing high quality automation tests while developing the features then having such statuses will not make much sense. But based on the fact that lot of teams work in globally-distributed environments and if you have your QA engineers in other part of world (India/China) then it’s better to have QA specific statuses in your flow as that helps the QA teams get notified of work in their bucket especially when they start their day in morning.   

Here’s how the PO Kanban board looks like:

Fig 3 – PO kanban board using squad based swimlanes

We can see that each Squad (London, Paris, Sydney) has a dedicated swimlane on the Kanban board. This is basically for demo purpose because ideally each Squad has an dedicated PO and thus each Squad should have it’s own PO board. But in the case a PO is managing backlog for couple of squads then they can configure the board like the above.

Here’s the underlying JQL query for the board:

“project = DEMO AND type = Story AND status in (Open, “In Refinement”, “Ready for Sprint”) AND resolution is EMPTY ORDER BY Rank ASC”

Since we should ideally have dedicated PO refinement board per squad thus we just have to add squad criteria in the above query to make it like

“project = DEMO AND type = Story AND status in (Open, “In Refinement”, “Ready for Sprint”) AND Squad =Sydney AND resolution is EMPTY ORDER BY Rank ASC”

This will have the board displaying only stories for the Squad “Sydney” and also notice that we use only the part 1 of the three parts of the workflow statuses. Once the story (like DEMO-5, Sydney Squad in the above image) reaches the statues “Ready for sprint” which is the rightmost status on the Kanban board, then it will automatically appear on the Sydney Squad scrum board backlog, like below.

Fig 4 – Sprint Backlog in the Sydney Squad’s scrum board

The column mapping on the Scrum board of the Sydney dev team will look like this:

Fig 5 – Column mapping in the Sydney squad’s Scrum board

Notice, that here the “Ready for sprint” column is the left most one and once we start the sprint then the DEMO-5 story when moved to “Dev in progress” will automatically disappear from the PO Kanban board (Fig -3) as this status is only part of the Scrum board and not the PO Kanban board.

Fig 6 – Active sprint view of the Sydney Sprint board

The right-most column from the column mapping (Fig-5) is “Sprint done”, now this is the first column of the Release board. Thus, when the story moves to sprint done then it signifies the “point are burned” because in Jira the right-most column is “done” column on the board.

Burndown chart and velocity reports are critical for assessing the team’s performance. That’s why it’s important to follow the workflow and move the story to sprint done rather than doing it few hours before completing the sprint. Because lot of teams do that and the Scrum master ends up with a steep drop in the charts rather an a gradual and more metric friendly burning of points.

Now, for managing release (part 3 of story workflow) we can have a separate Kanban board. There can be various ways of managing release, but my suggestion is to do what works best for you. Sometimes release teams are separate thus it’s better to end the workflow of the dev story and create a separate linked task in the board of the release team.

Fig -7 Column mapping – Release Kanban board

Releases are generally at the level of Epics thus when releasing the Epic all the child stories are also released. Since Epics can easily span multiple sprints thus when the stories reach the release board after the sprint then they have their own release lifecycle because it’s now on a Kanban board instead of a timeboxed scrum board.

If you have a monthly release cycle for Epics then you can gradually move the child stories across various stages of release like integration testing, UAT, Pre-prod, etc. and then make it available as an release candidate when releasing the Epic.

It may also happen that you have to release the Epic as the business needs some of the child stories to be deployed ASAP but the Epic still has some partially completed stories. In this case you can also split the epic and release the one which is ready and critical for business.

Uptil now I have showed screenshots of boards used by stories. Since Epics are higher level requirements thus you can manage them via similar Kanban boards based on a much simpler workflow (default Kanban flow) as teams work primarily with stories only.

Epics are at the level of Tribe and contain stories that span across Squads and sprints for that Tribe and thus a single Kanban board will suffice for the entire lifecycle of the Epic.

Fig -8 Column mapping – Epic Kanban board for Demo project

In this article I have covered the Jira side of things in the Spotify model. These use cases indicate that Atlassian tools are perfectly tailored to support an organization that would like to follow the Spotify model.

Apart from tracking and managing the project in Jira, it’s also critical to manage the requirements at the program/project/team level for which we use Confluence. I plan to write a couple of more articles about content management in Confluence, project tracking at the portfolio level and managing dependencies between projects.

Have you got any questions about implementing Atlassian tools or the Spotify model? Feel free to reach out to me in comments; I’m always happy to share my knowledge with the community.

Tarun Sapra is part of the team Agile Centre of Excellence at Ingenico Group and is working as an Atlassian Architect