Stop SpotiSAFe®
The havoc-wreaking bastard child of SAFe® and the Spotify model must be stopped.
Why are companies implementing some hybrid between the Spotify model and SAFe?
In several recent assignments, I have encountered a botched implementation of a merge between the Spotify model and the Scaled Agile Framework. The attempt to balance Spotify’s decentralized agility with SAFe’s structured approach is often sold by consultancy firms as the best of both worlds. The non-framework that arises creates a convoluted organizational structure that fails to harness the strengths of either approach. This compromise results in a disjointed implementation, creating a Frankensteinian model that struggles to reconcile the distributed autonomy of Agile squads with the hierarchical bureaucracy imposed by SAFe. As companies increasingly gravitate towards this hybrid model, a critical evaluation is essential to warn against this practice and address real organizational needs to avoid having to amend the transformation when things do not quite seem to work as promised in the consultancy PowerPoints.
Spotify, the model that is not a model
The Agile nirvana known as the Spotify model has garnered quite some attention for its innovative approach to organizational structure, emphasizing autonomous cross-functional teams organized in a “tribe-squad” hierarchy. Popularized by the great videos of Henrik Kinberg's Spotify Engineering Culture — Part 1 & 2 (aka the “Spotify Model”), it has gained quite some traction in the agile community. Although the videos contain some great examples of agile practices and culture, they should not be perceived as an implementable scaling model but rather as a snapshot of what was happening at that time at Spotify. So, despite its widespread adoption, criticism abounds regarding the lack of a real standardized and applicable model. Detractors argue that the so-called “Spotify model” is not a model in the traditional sense, as it provides more of a set of guiding principles than a concrete framework. This lack of specificity has led to challenges for organizations attempting to implement the model, as the absence of clear guidelines can result in ambiguity and inconsistency. Critics also highlight that what works for Spotify, a company with a unique culture and history, may more than likely not be directly applicable to other organizations with different contexts and needs. As the Agile scaling movement evolves, it becomes imperative to scrutinize the practicality and suitability of the Spotify model, urging organizations to consider more tailored and adaptable approaches that align with their specific objectives and challenges.
SAFe® the framework that is not agile.
Enter SAFe. What we lack in structure in Spotify can be made up with SAFe, where this is abundantly present. However, the Scaled Agile Framework often faces criticism for being paradoxically labelled as an “agile” framework while embodying characteristics that seem antithetical to true agility. Critics argue that SAFe mimics existing layers of hierarchy and predefined processes, resulting in a rigid structure that contradicts the agile principles it claims to uphold. The extensive set of roles, ceremonies, and artifacts prescribed by SAFe can lead to a bureaucratic and cumbersome environment, hindering the adaptability and responsiveness essential to genuine agility. Moreover, the framework’s emphasis on planning and documentation may be seen as promoting a waterfall-like approach rather than embracing the iterative and incremental nature intrinsic to agile methodologies. As organizations grapple with the challenges of implementing SAFe, there is a growing scepticism about whether this framework genuinely fosters agility or merely imposes a top-heavy structure that stifles innovation and transformation.
SpotiSAFe® the framework model that is making things worse.
Organisations trying to implement the fusion of SAFe with the Spotify model, colloquially known as SpotiSAFe®, often encounter significant challenges that impede the transformation's effectiveness. The attempt to integrate these two frameworks to strike a harmonious balance between structured and hierarchical SAFe and the apparent freedom and start-up culture of Spotify often leads to an appeal to everybody in the organisation. Those who want change along the lines of autonomy and new ways of working find enough to be hopeful and transgress towards the non-model that is Spotify. Whereas the more conventional, those who would like things to remain as they are, find enough in the SAFe framework to cling on to command and control positions and traditional processes. I suspect this is where the SpotiSafe model originates; it’s a consultancy firm marketing dream that caters to everyone's desires. However, selling what everyone wants might just not be what your organisation needs.
Hastily thrown together, it usually does not consist of a proper operating model, worsened by the fact that most of the junior consultants charged with implementing this monstrosity often do not have any real agile experience or an inspect and adapt mandate. Roll out before the fixed price deadline and get the hell out of Dodge, scoring another successful agile implementation to be celebrated on their corporate websites. Meanwhile, it leads to the different opposing factions in the organisation googling their way to their own bubble within the transformation. These contrasting views will, without fail, lead to much conflict and imminent disaster. Lost quarters have been reported, and burnouts are often unfortunately to follow. When it becomes apparent that things are not working and seem to be a bit more complex than the picture-perfect PowerPoints, it's often too late, as people will be disillusioned by “Agile”.
As we see organizations struggle with the pitfalls and mishaps of SpotiSAFe, it has become critically clear that evaluating before implementing would be wise. Assess and test whether the hybrid framework genuinely aligns with your goals or risks introducing a convoluted structure that undermines the very essence of agility. Join us in the next articles to find out how. For now, it's essential to know why you need to transform before making any major changes to your organisation and avoid wreaking havoc.
Share your experience in the comments with SpotiSafe or other nirvanic best-of-both-world attempts of consultancy firms to roll out Agile Transformations from a box. I would love to include your stories in a next artcile.
Check out: Stop Big Bang Agile Transformation!
