Where to (initially) create a task/bug with the Spotify model

Question

When using the Spotify model, there are many different squads, who each own their own product. Now as far as I understand, these products could be interdependant (like services). One way to manage this in Jira (or similar) could be to create a project for each squad (so each squad has their own backlog).

If a bug occurs during a black box test, it might not be immediately clear, which service (product) is the cause of the bug and therefore which backlog it goes to. This leads me to my question:

Where do you report a bug, before you know what service (product) it relates to?

Example:

When placing an order in a webshop, there are three different services involved:

• Ordering service
• Inventory managment service (stock)
• Payment service

A bug occur during a black box test, while trying to place an order. It's not immediately clear, what is causing the bug. In which squads backlog should the bug be (initially) created?

Answer 1

This is a problematic question to answer because the "Spotify Model" isn't really a model or a framework or anything that would contain an answer to your question. What people call the "Spotify Model" was a white-paper that generalized the approach being taken at Spotify at a specific moment in time. Therefor, there can be no right answer to your question. I can share some insight, but take it for what it is.

First, I went back and looked at the white paper (it's been a few years) and one of the things it contains is a picture of a few of their applications with sections highlighted to show how "Squads" have broken up the product. You'll notice that they are broken up in fairly clear value streams. One has the ability to play music. Another has the recommendations. In this scenario, even black-box testing has a pretty clear place to start. The fact that you are having difficulty finding where to go with bugs may indicate that you are building teams around architectural components, not functionality.

Second, in an agile environment, I'm unsure how you ended up in this situation. The fact that you need to create a bug in some team's backlog suggests that testing is happening outside of the teams. While it is certainly possible that a bug appears well after release and the root cause is an unexpected odd side-effect of another change, if it happens in testing, the source of the change should be very recent and should have very few teams that could cause it.

On that point, to a certain degree, it simply doesn't matter who you ask to look at it. Let's say you have a bug that shows up after a feature has been in production for a year and no change has been made to that feature. Frankly, at that point, anyone is equally qualified to troubleshoot it. The teams should have strong enough connections to each other to rally around the problem, let someone take lead, and they can reach out to anyone they need to in order to fix it.

As it says in the link you shared, Spotify created a people-driven autonomous approach to structuring their organization to support agility. If you can't simply spotlight that the bug exists and then let the teams self-organize around it, then you should probably be looking at what was missed when trying to apply lessons from Spotify.

Answer 2

I believe the misunderstanding is that the squads do not "own their own product".

Typically, in the Spotify model, Squads will own part of the system or product. Squads are aligned into Tribes. In an organization with multiple, distinct products, I would expect alignment between Squads and Tribes in a way that each Squad or Tribe is aligned with one and only one product.

In Jira, the notion of a "project" best aligns with a product. You can see this in the fact that projects in Jira contain information about components, versions, and releases, which are typically associated with products. I handle multiple teams working in a single product (represented by a project) using a field on the issue. This lets me set up my filters appropriately.

If you are performing black-box testing on a system, you should know which product you are testing. Since you know the product, you should know which Jira project represents that product. The black-box system tester can log a defect against this project, initially without assigning it to the team. The Tribe Lead and Product Owner can review these submitted issues to determine which team is likely best suited to investigate and fix. Of course, it could be a cross-cutting concern that has a dependency across two (or more) Squads, as well.

In your particular example, the "webshop" is a product. However, there may be Squads around the ordering service, the inventory management service, and the payment service. If you are performing black-box testing, you would not know which service the issue is in, but you should know that it is in the webshop and there should be a set of people who can review, triage, and allocate the bug and its solution to one or more of the appropriate teams.

---

Two things to consider:

First, the Spotify Model may not work. It was described in an idealized way. It was never done as it was described across the organization. The things that were done were done because they worked for Spotify and it was never meant to be copy/pasted into a different organization.

Second, it seems like testing is not aligned to either the Squad or the Tribe. Or, perhaps, it's a separate "black-box testing team" that is part of the Tribe. Either way, it seems like there's a disconnect between the testing team and the Squads delivering the work. I'd want to dig deeper into what's going on there.