Please install the Spotify model for me

Suppose the company you work in has requested one of the big consultancies to roll out their favourite scaled agile framework to you with a big bang? It most often is a version of the so-called “Spotify model”. Here is a curated selection of background, readings and videos you want to be familiar with if you find yourself in such a situation.

A part of the so-called Spotify model from Kniberg and Ivarsson’s 2012 article

“I know what I wouldn’t have done, and that is outsourcing the problem to [a big consultancy]… and have them find a solution. The research results are clear. The solutions must come from within the organization.” – John Kotter

What is nowadays called the “Spotify model” is a snapshot of how Spotify in 2011 envisioned to work in the future. Its origins can be traced back to this 2012 article, written by Henrik Kniberg and the former engineering lead and agile coach from Spotify Anders Ivarsson.

Based on that article, and a great series of videos by Henrik Kniberg on the Spotify engineering culture (part 1 here, you can find the rest quite easily), people coined the presented way of organizing as the “Spotify Model”.

Never mind that even Spotify doesn’t use the spotify model, and just maybe, neither should you.

Comparing the “Spotify Model” to SAFe and LeSS

SAFe and “Spotify Model” contain a lot of the same genetic material. Squads are Teams, Tribes are Trains, Chapters are the line organization of the dual operating model proposed by Kotter and later on adopted by SAFe, and Guilds are communities of practice. The rest of the roles in the original 2012 article map quite directly to similar roles in SAFe.

There are videos out there which compare Spotify and SAFe, this one by Joakim Sunden, a former agile coach from Spotify and the person who coined the term Tribe. Furthermore in the “Spotify Model” teams are supposed to have an entrepreneurial attitude (similar to that of Marty Cagan’s empowered product teams) and figure out by themselves what to do. In SAFe, the teams are more akin to a delivery organization.

Comparing to LeSS, the key differences are that teams in the “Spotify model” have their own backlogs and there is a product owner per team. These are both something LeSS advises against. Further, emphasising team entrepreneurship doesn’t encourage the cross-functional learning which needed to constantly shift to work on the most important things.

Rather, it can limit teams to their own areas, hindering collaboration and overall product success. Also, the Team PO role hinders the teams to handle coordination by themselves at the developer level, which leads to increasing the wastes of delay, inventory (via intermediate artifacts such as requirement specs) and coordination bloat.

Why do big consultancies favor the “Spotify Model”?

In my opinion there are four main reasons, which work together:

The “Spotify model” is very similar to SAFe. With the difference that you don’t have to deal out part of the profits to Dean Leffingwell & the folks at Scaled Agile. As a consultancy, you can invent your own jargon and practices (which can most often be directly mapped to SAFe) to fill in the gaps of the “Spotify model” and get the client hooked on your version.

And just like with SAFe, these additional details provide the legacy organization a scaffolding with places to hide in, so you really don’t have to change all that much. Departments can call themselves tribes, component teams become squads, and system owners can remain system owners – you don’t even have to change the term. Finally, with the team product owners handling the brunt of coordination, the inefficiencies of “low-cost” outsourcing remain out of sight.
Spotify conveniently has team product owners. If the client company wishes to stick to the “cost-saving” outsourcing model of the 90s, where the rest of the team is far off and programmers change constantly, you don’t have to make the hard decision of starting to insource developers.

Transformation as a big bang project. In the “Spotify model” you don’t have the notion of Kotter’s (and SAFe’s) dual operating system and is no recommendation of doing the change by moving people group by group into a “parallel organization” which operates in the new way.

From the perspective of the business model of the big consultancies, the above mentioned factors play well together. Further, as it’s not good business to sell a small incremental solution,- big consultancies invariably provide a big solution. The job then is to get in, do a quick transformation project with a big of a bang as possible, with as many consultants as possible (who possibly change constantly), with a clear beginning and an end from an internal resource and pipeline management perspective.

Then, the consultants can celebrate the success with those who paid the bill, publish a sugar-coated case study, get out, and then return to help out and draw more profit as the client discovers that the success actually wasn’t a success to the people in the trenches.

Indeed, most of the advice out there seems to point against a big bang or considering the transformation as a project. The intent of changing the way of working should concern and be clearly communicated to everyone, but rolling out the actual change (in other words, “moving to the parallel organization” as Kotter and subsequently Larman put it) should be done group by group, preferably starting with real, not fake volunteers. And you get real volunteers by educating everyone – something which is hard to do with a big bang.

Then, the fourth reason:

Why Spotify instead of LeSS? Big clients and big consultancies both favour big solutions, and LeSS certainly doesn’t look like one. It also doesn’t help that folks versed in LeSS do not typically work for a big consultancy, and instead quite clearly argue that such method vendors should be avoided.

Instead, LeSS folks strongly state that the solutions should come from inside the company.

Resources to help you on your way

As these things go, if you are still reading this, chances are you may not be one of the people who get to call the shots whether to “adopt Spotify” or not.

So, I’ve collected some curated materials below to help you on your way. I’ve listed them in the order of importance:

A reality check in the form of a video: not even Spotify uses the Spotify model – particularly not outside of R&D which I’ve heard being touted as an upside of “the spotify model” by the big consultancies. The linked video is by another co-author of the Spotify model, Joakim Sunden. An interesting detail is that Spotify nowadays has one manager per every five people.

Jurgen Appelo does an excellent job of both describing and analysing the Spotify model, as well as providing an updated version of it. The article is also endorsed by former mentioned Anders Ivarsson, a co-author of the spotify model.

This article by Alexey Krivitzky does a good job in analysing the Spotify model from the perspective of optimising for adaptiveness (in other words, agility), and thus, points ways forward to heights not directly supported by the model itself.

Joakim Sunden talks about his and “the model’s” journey at Spotify from 2011 to 2017 and shares lessons from helping with transformations in other companies since then.

An article by Rowan Bunning explains the pitfalls in implementing “the Spotify model” at ING” – the emphasis on the entrepreneurship of trains and tribes may lead to a new set of siloes.

This video (Death of the Spotify Model) by Girjs Meijer and Marcin Pakulnici) seems to talk about the same story as the above article by Rowan Bunning. Essentially, the moral of the story seems to be dismantling the “entrepreneurship” and shifting all of the teams as general-purpose teams striving to work on the highest value.

As the final resource, a video comparing SAFe to Spotify by Joakim Sunden. It’s worth listening to, but some points regarding SAFe are a bit (but not too drastically) off.

If you have more great material on the topic, do let me know, and I’ll include it with an endorsement to you finding it.

Scaling agile safe and sound

maatuska revefrsed.png

“Never argue with a fool, onlookers may not be able to tell the difference” – Mark Twain

Back in the day as researchers we pushed Agilefant forward with a versatile-model-first approach. While it lacked bells and whistles such as attachments or detailed user access rights, it had the concepts needed to support large scale agile already in 2007.

Fast forward to today, its last and final incarnation was known as Nektion (the proliferation of the A-word tends to repel executives whose organizations might need it the most), and its entire ontology could be configured to fit the convoluted structures of large complex organizations you might run across.

Despite that, or perhaps because of it, I nowadays find myself rather agnostic with respect to whether agile should be scaled using frameworks such as SAFe, LeSS or DAD – or if it should (or even could) be scaled at all. Anyway, the result is usually better – if only slightly – than the darkness which existed before trying “agile” out.

Still, many of the lean/agile thought leaders out there do have clear opinions on the matter. If you’re in the process of “scaling agile” or considering it, my advice is that you should explore these opinions, and consider how the views expressed may or may not apply to your context.

To help you get started, I put together a table of some of the writings around the topic from the better known writers of the field I’ve run into. They are ordered starting from the most recent.

Many of the posts I’ve raised are critical of frameworks for scaling agile. Some are even critical about the notion of scaling agile in the first place. I made this choice because the organizations and people who are in the business of providing frameworks, tools and consultancy for scaling agile already cover the upside quite well.

There are also other posts, but I’ve tried to condense this list to the most popular and/or such that they have some depth to them.

By exploring the material below, you’ll hopefully become aware of the tensions around the topic – and thus are better able to steer clear of the potential pitfalls in your own transformation efforts.

While some comments are nowadays outdated (for example the notion that “SAFe allows to release at the PI cadence”), all of the authors there are surely worth following, and to dig deeper, check out also the commentaries of the posts linked below. I’m updating (last updated 2024-05-31) the list as I find new noteworthy articles.

Author	Post	Quote
Martin Hinshelwood (2023)	SAFe delusion	“…marketing stories. Some practitioners have been there and know the difference between marketing and real stories, others know not only how things started yet also how things are going now.”
Pawel Huryn (2022)	Watch out, waterfall ahead! The truth about SAFe	“It’s not a coincidence that SAFe was created by the same person who made the Rational Unified Process (RUP). In my opinion, no buzzword (Agile, Scrum, Lean, Enterprise, etc.) can cover its true nature.”
Sean Dexter (2020)	Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness	“[…] viewing teams as a “delivery” function instead of a strategic one. The high level thinkers come up with ideas, and the low level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it. […]”
Jeff Gothelf (2020)	SAFe is not agile	Large organizations seeking agility […] cling to the faorganizations seeking agility […] cling to the familiarity of waterfall processes. SAFe gives the illusion of adopting agile while allowing familiar management processes to remain intact.”
Bob Galen (2019)	SAFe no longer – my final farewell	“[…] I’ve struggled with it for a long time. […] Believe me, I’ve tried to understand, support, and apply it. […] But it’s too big, far from the principles of simplicity at the heart of agility [and] focused on pursuing revenue. […] Just because it’s popular, doesn’t make it right. Nor does it mean that I have to support it.”
Dan North (2018) @tastapod	In praise of SWARMing	“Scaling methods are not unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation.”
Duncan Nisbet (2018) @duncnisbet	SAFe systems thinking?	“The cultural aspects […] are the overriding blocker to systems thinking. Merely talking about it briefly in a 2 day workshop is not going to overcome that challenge.”
Renee Throughton (2018) @agilerenee	Why SAFe is not the scaled approach you need	“It encourages massive batching […], old world thinking on estimation […], doesn’t change leadership behaviours [ …], doesn’t force a change in organizational structure”
Marty Cagan (2018) @cagan	Revenge of the PMO	“If you were an old-school PMO missing your classic portfolio, program and project management, you would probably love it.”
John Cutler (2017)	Have you heard the one about SAFe?	“There are very few people voicing the perspective of non-consultant full-timers. The narrative is primarily driven by consultants and “thought leaders”… all with […] vested interest in guiding the perception of the market, closing deals, and getting their foot in the enterprise door. […] Thoughtful comparisons of approaches would benefit everyone.”
Steve Denning (2017) @stevedenning	What is Agile? The four essential elements	“The emphasis […] is more on descaling big complex problems into small pieces than on scaling up the organization to match the complexity of the problems it is dealing with.”
Mike Cottmyer (2015) @mcottmyer	Let’s acknowledge SAFe for what it is…and move on	“You either create the conditions to do Agile well—Agile as it was defined 14 years ago—or you do something else. That something else is called SAFe.”
Jacob Creech (2015) @JacobCreech	SAFe: How I learned to stop worrying and try the Scaled Agile Framework	“Suffice to say, I have a reasonable perspective on SAFe in real life, which I prefer to the typical theological debates that arise when SAFe is discussed.”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman	Scaling Agility or Bureaucracy	“Good consultation often helps to get results, also with SAFe. However, there is the risk that the systemic conditions are not changing, and the change remains superficial.”
Kristian Haugaard (2015) @haugaards	Interview with Dean Leffingwell about SAFe	“Many of [reviews of SAFe] have been written by authors who never spoke with anybody who had been involved in a SAFe implementation…”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman	LeSS-SAFe comparison	“[Both LESS and SAFe use Nokia as a reference, but] LeSS was and is mostly used at Nokia Networks […] while SAFe was mostly used at Nokia Mobile Phones”
Jeff Sutherland (2015) @jeffsutherland	Q&A with Jeff Sutherland on Agile Leadership	“scaling frameworks are often used to provide scaffolding for the legacy organization until they can evolve”
Ron Jeffries (2015) @ronjeffries	Dependencies, Scrum of Scrums, and SAFe	“[…] a huge fraction of the dependencies between teams are artificial. They are due to poor allocation of work from above, and to the existence of unnecessary silos of responsibility.”
Mike Cohn (2015) @mikewcohn	You Don’t Need a Complicated Story Hierarchy	“When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline.”
Sami Lilja (2014) @samililja	The case against scaling	“The problem is NOT that we lack ways to scale agile. The problem is NOT that we fail with agile in large organizations. The problem is that we are large. […] The frameworks take “large scale” as given, and do very little to reduce that.”
Lyssa Adkins (2014) @lyssaadkins	The Agile Coaches’ Coach Shares Her View on SAFe	“Rumi urges us not to become too attached to one “grain”; one teacher or one way, or, in our world, one agile framework or one perspective. I urge the same. Rather, let us look out wider and farther.”
Mike Cohn (2014) @mikewcohn	Introducing the LAFABLE Process for Scaling Agile	“some of [scaling approaches have been] even tested on real teams before the marketing machinery spun up to promote them”
Ron Jeffries (2014) @ronjeffries	SAFe – Good But Not Good Enough	“SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning”
Ron Jeffries (2014) @ronjeffries	Issues with SAFe	“Release Train is an example of a remedial practice presented as an ultimate solution. […] SAFe does not push hard to eliminate the problem: it just gives a way to accommodate it.”
Peter Saddington (2014) @agilescout	The Scaled Agile Framework (SAFe) – A Review	“thoughtful and well-intentioned [but] takes it a bit too far and defines […] almost too much”
Charles Bradley (2014) @ScrumCrazy	Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives?	“To date, no Agile Manifesto author has endorsed it. That should tell you something right there.”
David J. Anderson (2013) @f4p_dja	Kanban – the anti-SAFe for almost a decade already	“in 2003 I decided to focus on […] reducing or eliminating resistance to change. A process-centric focus wasn’t working without a lot of money, positional power and fear to motivate individuals to fall into line.”
Amr Elssamadisy (2013) @samadisy	Is it safe?	“The question is not whether SAFe should be used as the strategic basis for large Agile adoptions. The question is this: What will make those adoptions most successful?”
Ken Schwaber (2013) @kschwaber	unSAFe at any speed	“The boys from RUP are back, […] partnering with tool vendors. […] Consultants are available to customize [SAFe] for you, just like RUP”
Neil Killick (2012) @neil_killick	The Horror Of The Scaled Agile Framework	…” a horrible, money-making bastardisation […] of Scrum, Agile and Waterfall…”

P.S. Curiously enough, I was not able to find posts of sufficient depth, quality or otherwise of interest (subjectively, of course) from 2016. But surely there are some lying around! Can you point me to any?

The simplest way to run SAFe with JIRA

Ship in a Bottle Seute Deern 1

“Going agile with JIRA often looks like learning to sail with a ship you’ve built yourself – in a bottle” – Dr. Agilefant, 2016

Somewhere in your large, complex organization there are people who think you should strive for a more agile way of working. Some of those people may think that the Scaled Agile Framework (SAFe™) could be a good blueprint to follow.

While there are alternatives, let’s suppose you want or have to use your existing JIRA to support also the new way of working.

Mismatch of models

SAFe is less complicated than it may seem at a first glance. The difficulties stem from JIRA’s conceptual model, which does not match what is suggested by SAFe. On top of that your organizational design and/or constraints posed by your suppliers or customers probably do not match the set-up suggested by SAFe either, but that is the subject of another post.

JIRA natively has a three level requirements abstraction model (Epics, Stories and Sub-Tasks), but the terms are not configurable. Sure, you could define new issue types with the proper naming, but the terms in the UI will remain the same. This means that at least some mental mapping is required from the users. And of course, a three-level work item breakdown does not scale to a four-level SAFe.

In addition, JIRA’s single level non-nested work containers (Projects) means that at least some workarounds will be needed to express SAFe’s levels of planning.

Typical pitfalls

JIRA originated as an in-house bug tracker. It’s first commercial release was in 2002, and while plenty of features have since been added, little has been taken out. While this makes JIRA highly configurable, it is easy to go overboard in terms of the workarounds.

A common pitfall we’ve seen is that prevailing impediments to agile such as a function or system based organization are replicated into JIRA as some key concept – typically as Projects. This further cements the existing structures – which in most cases should be dismantled and rebuilt around customer value delivery.

Another common challenge stems from attempting to overcome the limits of JIRA with plug-ins. While this is possible – to a degree – it leads to a more complicated set-up. And even with a willing, SAFe-trained organization and detailed instructions, the supposed way to use JIRA can prove too complex to grasp.

The result is a constant demand for training to grasp the complicated JIRA-with-plugins set-up. People also simply go around the complicatedness and make up their own special ways of using the tools, which makes progress roll-ups difficult and improving the ways of working via measurements impossible.

Resorting to ‘shadow accounting with MS Excel’ is also fairly common solution even in cases where JIRA is seemingly being used.

The simplest way

In matching SAFe and JIRA, you have to make some compromises. You should strive to avoid design decisions that directly get in the way of the transformation. You don’t want to simultaneously deal with both the resistance to the new way of working and the complicatedness of the desired JIRA usage model.

Having observed JIRA usage in a number of organizations striving toward large-scale agile we have devised a blueprint for how to implement ‘three-level’ SAFe (known as ‘Portfolio SAFe’ in the 4.5.1 version) using JIRA.

We’ve deliberately aimed at the simplest possible model doable with plain vanilla JIRA. While it is by no means perfect, it presents a sane starting point. The mapping of the key concepts is described in the table below.

SAFe concept	JIRA concept	Notes
Portfolio	Project	JIRA’s projects have no beginning or end, and they are the highest level wrapper of content
Epic	Epic	Workflow: funnel, review, analysis, backlog, implementing, done
Feature	Custom defined issuetype ‘Feature’	Use JIRA’s native ‘epic link’ to connect Features to Epics. Workflow: funnel, analysis, backlog, implementing, done
Story	Story	Use the child-parent issue link to connect to Features; workflow funnel, backlog, sprint, done
(Bug)	Bug	Use the child-parent issue link to connect to Features; workflow funnel, backlog, fixing, done
Strategic theme	Label	Manually add at least to Epics; and then to the depth deemed relevant
Key system being worked on	Component	Add components to the depth of the work breakdown you have sibling work items which concern different components
Team, Train, Solution, Portfolio	A single JIRA user for each party	Multiple people use the same login. Everyone should have access rights to ‘everything’ except admin functionality
Portfolio kanban	Kanban board	One for each portfolio
Program kanban	Kanban board	One for each train; program increments are not explicitly modeled; Features in the status ‘implementing’ are considered to be in the current program increment
Team board	Scrum or kanban board	One for each team, according to their preference
PI Objective	Online shared spreadsheet	Not because it’s are good but because it’s better than what you’ll hack to JIRA – especially from the business owners you’ll want to get engaged. Also, spreadsheet works better than JIRA for the most important metric suggested by SAFe – program predictability based on PI Objectives’ achieved business values

Evaluating the design choices

The choices made above come with good, bad and an ugly side. The Good is what we see as the upside of the choices, and The Bad as the downsides which we see that can be overcome. The Ugly refers to those downsides which are inherent to plain vanilla JIRA and can’t easily be worked around.

The Good

Very little mental mapping required; JIRA concepts are not forced to represent other things than their name implies
User per party and no access restrictions support the notion of shared responsibility and promotes the importance of frequent communication
Can be moved to in an existing JIRA set-up; changes are restricted to a single project and new ‘party’ users
Possible with plain vanilla JIRA
Not necessary to use JIRA’s rather convoluted sprint functionality
Virtually non-existent licensing cost (only a handful of user seats required)
Frees the parties to organize as they wish as a team (do more detailed coordination on a physical board, work as a mob, and so on)
Changing the legacy organization structure based around systems is a key challenge in most organizations; including this reality via modeling systems explicitly as Components can be leveraged to spot and eliminate dependencies as well as problems with the current organizational design

The Bad

Unconventional design choices (compared to how JIRA is in my experience commonly used) may cause resistance in moving to the model
- No user per a living person
  - However, the model does not fundamentally change if the team-user is replaced with a person-user; you can still model the teams and trains as groups and use these in queries
- No detailed user access control; everything is shared;
  - While people often create separate projects to prevent others from ‘messing up their issues’, these fears are mostly unfounded; people with access rights make mistakes too and you should have frequent backups and selective restoring capabilities anyway
To leverage strategic themes in querying lower level items, you’ll need to add them by hand all the way to the story level
JIRAs label editor (or rather, the lack of one) makes the usage of Strategic themes error-prone
One might argue that having ‘Bug’ as its own issue type is against the grain of ‘the simplest thing that might work’; however, our experience is that sooner or later you’ll want to be able to discern between fixing and enhancing based on work item type; this also frees using labels for other purposes

The Ugly

Plain vanilla JQL is not powerful enough to support many queries which can be seen as interesting to running a SAFe-like process; in a future blog post will show what exactly I mean by this
- However, the most important metric of SAFe has to do with PI Objectives and those we suggest should not be in JIRA at all
- Also, the plugins required to ease the needed queries and detailed filtering work around the most critical issues are relatively inexpensive; we will take a more detailed look of this in a future post
Hard typing of requirements and no support for N-level work item splitting and; why you would want to avoid the former and have the latter is the subject of another (rather long) post by itself; but it has to do with the heart of agile requirements management – iterative refinement and keeping the batch sizes manageable
Program boards with dependency visualization can’t be done with plain vanilla JIRA; I predict sooner or later someone will do a free plugin compatible with Cloud JIRA

Running the model

We are running a model very similar to the one described in a couple of customer cases. In the future we will be writing about for example how PI and sprint plannings work in this model, and also present a set of example queries to questions commonly asked by the key SAFe-org stakeholders (such as ‘show me all the work related to this epic’ or ‘show all the work related to this strategic theme).

To be among the first to get the link, follow @dragilefant on Twitter or LinkedIn or @NitorCreations

To be among the first to get the link, follow Nitor on Twitter or me on LinkedIn.
And should you be running something similar – or even try this model out – we’d very much like to hear of your experiences.