Don’t use the Spotify model to speed up delivery

Many organisations followed down the path of the “Spotify Model” by adopting the roles and org structure, hoping and expecting that would make teams faster.

In many cases, nothing has actually changed except for some people’s titles.  Oh, and “Squads, Guilds and Chapters.”  The hierarchy remains the same.  The responsibilities remain the same.  The work remain the same.  Nothing important changed.

Here’s the thing - What made Spotify move faster wasn’t changing titles or the name of organisation units.  They completely re-wrote the operating manual for their organisation:

1. Let’s start with their “Inverse-Conway Manoeuvre”.  Their software was originally built by teams in a hierarchical structure, with an architecture that is typical of hierarchical organisations. It wasn’t conducive to making small-batch, rapid & iterative changes, because the codebase had lots of dependencies that impacted across teams.  To address the issue, they rewrote the codebase using microservices architecture. This allowed the teams to own their “patch” of the code, and make any changes and deploy them rapidly without fear of breaking the code or dependencies of other teams.

2. Out of this change, teams became mini startups - they experimented with their patch of the product by using A/B testing to find out what worked best for users.

3. Next is the “break stuff and go faster” culture.  The founders from the top-down said “I want you to feel like you can break any rule within the organisation that doesn’t make any sense.  On one condition - as long it means you go faster.”

4. The organisation moved on from Scrum, because there were faster options.  An Agile Coach would work with teams from time to time to assist them with going faster.  Teams could use whatever method of delivery and collaboration they preferred, again, so long as it meant they moved faster.

Here’s how to fix it:

➤ Stop doing project-based work and project delivery.

➤ Change team structure, and remove hierarchical reporting lines.

➤ Build architectures that allow teams to make code changes without impacting others.

➤ Challenge indoctrinated rules.  “Who created  this rule?” “Why did they create it?” “Is it still relevant now?”

➤ Consider moving on from Scrum.  Scrum is “Mini Waterfall.”  It’s slow.  Your teams are ready to move on.  Maybe you aren’t ready.  Yet.

➤ Don’t feel that the Spotify Model is the best one around.  Decide what your values and objectives are.  Find better terminology, roles and titles.

➤ Most of all - improve your delivery system.  Start by understanding the constraints of your current system, and invent a better system of delivery.  Optimise for the right outcome.