At one customer, a saying has taken on a life of its own that speaks volumes about the difficulty of SAFe implementations:
Better SAFe, then sorry.
The originator wants to remain unrecognized 😉
For those who are already whipping out the gloating red pen to mark that it should be “than”, I’m happy to give you more background. For this proverb is thoughtfully chosen in every word.
In the beginning, there is the big question of how a company or a division should organize itself in the future. The quick decision in favor of SAFe often arises from the impression that SAFe is everything: more comprehensive, more sound, more applicable, more scalable, more transferable than other frameworks.
And how great that SAFe’s acronym immediately suggests that the whole thing is super safe. What could possibly go wrong?
However, when it comes to implementation, it turns out that the great enthusiasm is followed by disillusionment. This is sometimes even greater in the SAFe context, because SAFe gives so many recommendations and seems so prescriptive. This disillusionment, we will see at the end, is neither unique nor special to SAFe implementations.
The Theory
SAFe – and this is one of the strengths of the framework – provides a lot of information. The fascinating thing is that this information relates to good practices and studies of successful implementations. Who would argue against Kotter’s eight steps? Especially since there’s that great Business Results icon beckoning in the upper right? And on the SAFe webpages there are some examples of companies that have, by their own admission, implemented SAFe very successfully?
Well, let’s first see how Scaled Agile suggests an implementation. There is a clear decision for SAFe with “Go SAFe”. Now the transformations starts with training the “Lean-Agile Change Agents”, the “Executives, Managers, Leaders”, and all who can have positive effects for the introduction of SAFe. At this point, I would like to point out a mistake: Training todays “managers” only.
At the end of the first straight, the value creation is evaluated, very sensible, as I also described myself.
On the way to the second straight, the first (and initially only) Agile Release Train is prepared.
The curve to the third straight is then essentially about repeating the positive experiences of the previous transformation.
So far, so simple. But that’s just the blue theory. Therefore, let’s move on to the more colorful practice.
How to safely fail your SAFe implementation
The following non-recommendations are very much in the style of Watzlawick’s “Guide to Unhappiness”. What is failure and what is success is often subjective, as is this entire article. Rarely are there collectively objectified metrics that precisely define success or failure.
I am not addressing individual persons, and not individual companies. And, to our credit: Where we have experienced derailments of ARTs, it was firstly no one’s intention and secondly, afterwards, always on good terms with joint commitment. Because basically people are good.
I hope therefore, you always find the right path within the now following irony and know to rethink the following lines wisely.
Entscheide Dich für die eine Art der SAFe-Einführung
There are only two ways to introduce SAFe.
- Option one: Do everything exactly according to the supposed theory (there is a lot described!). This means in no case to deviate from the descriptions. Where interpretation is required (it is only a “framework” and not a “manual”) simply interpret in the sense of the inventor (Dean thanks you). The important thing in this case is to insist that there is only this one truth. Otherwise the whole endeavor will become counterfactual at some point.
- Variant Two: See SAFe as a recommendation from which individual elements can be copied as needed. It is particularly helpful for change if the terms are also adapted in the process. Why keep all the familiar terms? That would be unnecessarily complicated!
Pretend that the past was just junk.
It is important to make it clear to everyone that the work done so far has simply been unprofessional, mindless, and self-serving work. The best way to do this is to hire a consultant who first conducts interviews, then locks himself in with the “top management” to announce after long days (and high bills) that everything has to change, but that fortunately there is now a plan for it.
Do not under any circumstances formulate a reason for the change.
Under no circumstances should a reason for the change be formulated. This would require all responsible parties to be far too committed. The reasons for a SAFe implementation are so many, it is a complex situation and always everything is always subjective anyway. In the most dire need, the consultancy can craft a few PowerPoint slides, sure there’s something from the previous customer, that’ll fit. The slides should be published on the intranet, not without first creating the right sub-sub-page for them. This way, everyone has access.
The argumentation should be complicated but open, it must finally do justice to the situation. Under no circumstances should individual causes be singled out, nor should any whacky pictures of the future be painted. Last but not least, a dramatic urgency for an orderly transformation is completely inappropriate.
Let the experts do it. And only them!
It is crucial for a sovereign failure that real experts are involved. People who do menial work such as programming or testing should be avoided. They are much too deep in their nitty-gritty and are not useful for such big ambitions.
Get a bunch of people together, call it LACE.
Congratulations, you have understood the idea of the Guiding Coalition (see Kotter’s eight steps above). Now it’s a matter of implementing it. And what better way than to bring the above mentioned experts together now? Scaled Agile proposes the Lean-Agile Center of Excellence, or LACE. It is, in a sense, the string around the whole SAFe implementation!
Such high-profile members have many responsibilities, of course, so they can only participate in a LACE 20% or 50% or so of their time. But for it to be credible, it still has to be called a team.
It’s true that in SAFe everything is organized with agile methods, but among professionals that can be left aside sometimes. They already know what they are doing. That’s why they don’t need a Scrum Master (Scrum) or Service Delivery Manager (Kanban).
It’s easy to imagine that the top managers don’t have time either. Therefore, it is highly unlikely that they will participate in the LACE team. Under no circumstances should a top manager take on the role of a product owner (Scrum) or service request manager (Kanban), because that would put them far too close. Regularly carefully prepared status reports are instead the means of choice for coordination with the LACE.
Since SAFe has such a wonderful, comprehensive website, training (even SPC training) for individuals or even everyone on the teams is not necessary. After all, knowledge workers know how to acquire SAFe expertise, it’s all there.
Now it’s finally getting started for real!
Enough of plans, they have to be implemented! Therefore, as many teams as possible should be created and ARTs “launched” as quickly as possible. Oh, and at least one large solution and, best of all, the portfolio as well. A reliable way to screw everything up is to “launch” everything at the same time, or at least very quickly.
If you take the trouble to read in the depths of the SAFe website, you will come across the slide above. With a little imagination, it can be interpreted to mean that one of the four factors always applies: let’s face it, there’s always a big challenge, right? You see, then off with this bunch of people onto the ramp for the “launch”!
Therefore, measuring the number of teams and ARTs as a criterion for success also helps: The more, the better. This approach is helpful even if the number of people in a team increases later on: Just start a new team!
Too many teams for one ART?
Simply create a new ART!
And too many ARTs?
A Large Solution!
What, not everything fits into the Large Solution?
Create a Super Large Solution. This is then also arbitrarily scalable and the problem is simply scaled away.
I have also seen several portfolio, which were nested in each other. This is something for real connoisseurs.
Roles, events and artifacts are…nice.
SAFe is a dual organization. This is often not clear at first glance and later causes confusion. Malicious tongues claim that this dual organization is there to cause confusion. But it is actually quite simple: On the right is the old, familiar thing. Left is the new thing. The task now is to make creative connections, similar to the two ways of introducing SAFe.
To be on the safe side, I’ll show an example that should not be followed with the goal of screwing up:
The Finnish Nordic Bank has mapped out development paths for people in its line organization. But that only takes away flexibility and thus agility. That’s what the whole thing is supposed to be about! So it can’t be a good idea.
Instead, it is recommended to work with fluid roles. That means assigning roles to several people and thus transporting today’s image of the organization into the future. Kotter must have thought along these lines in his book Accelerate. Seriously. Cough.
No trainings for anyone!
In general, trainings are for dummies who want to be sprinkled for a week and hang out in the hotel bar in the evening. Don’t be fooled by exams and certificates! This is true for LACE as well as for all others. Sure, SAFe is extensive. But your employees are not stupid, are they? They are learning all their life anyway. The trainings and certifications cost an incredible amount of money.
Communication is super important!
Change is largely about communication. This is the 1×1 of change, is said up and down and everyone nods approvingly. Those who want to fail amateurishly try to create results and talk about them. If you want to fail grandiosely, you have to talk and then create results. It helps to have communication experts (see above) with you, who can gold-plate everything in such a way that seasoned alchemists would turn green with envy.
To not fail, a wholly alternative approach is recommended: walk the talk. But that would be boring.
Architecture comes by itself
Once the approach is agile, the whole development can’t help but result in an agile architecture and a powerful delivery organization (technical term: Continuous Delivery Pipeline)! Not everyone knows this. Many think that there must be elaborate design. Some even claim that without the appropriate business and technical architecture, agile working would not even be necessary. But these are mostly loners who only want new toys, never think about the customer (sic!) and simply can’t get anything done.
And last but not least: SAFe. Must. Be.
One of the most important factors comes at the end, the cherry on top of the chocolate ice cream. SAFe should be introduced despite all the risks and side effects. Because the others are doing it too and it is therefore good. The future will also show that:
Do not scale.
I do weaken near the end and give some serious advice – before adopting scaled agility: don’t do it. The first principle of scaling is: do not scale. Decoupling is always cheaper, and decoupled teams deliver faster than coupled ones.
And now you! What else contributes to successful failure?
Of course, there are many more reasons for SAFe implementations that do not achieve the previously set, communicated goals – or do not actually improve delivery capability – or lead to great dissatisfaction among employees. Although it is SAFe-specific here, the technically spoiled readers recognize that much is typical of personal and organizational change. And ultimately, a SAFe implementation is an organizational change. Thus, the disillusionments mentioned at the article are neither unique to particular organizations, nor particular to SAFe.
But at some point, even this article must have a conclusion. After all, there are also factors that contribute to positive adoption. If that’s of interest, let me know and I’ll get to work on an article. So long, in any case, avoiding the grossest mistakes already contributes significantly to success.
Alternatively, a question mark can be added to the end of the article. So then: What else have you encountered (only with others, of course) that you can share here?
