In this series of blog entries I share some observations, stories and thoughts. My daily work is usually comprised of managing my own company, helping people as a coach for Agility and Systems Modelling, and training people, i.e. enabling them to learn in an engaging and efficient manner.
I have been working with SAFe since 2013. I was one of the first seven SPCs in Germany. This is certainly not an attempt at bragging as you will see shortly. SPC, incidentally, stands for 'SAFe Process Consultant. It's a certificate you are awarded once you prove your commitment to SAFe by attending a three day course followed by a multiple choice exam. The pre-requisites for attending are, or at least used to be, a track record as an agile coach, as well as a SCRUM Master certification. It has to be said, though, that the SAFe exams are not as laughable as the one for the SCRUM Master certification. My opinion of SAFe cannot be described in a single statement. But trying to summarize I would have to say that it has the potential for causing a lot of damage to an agile initiative. On the other hand, if guided by a true agile coach (who certainly has to be armed with more than SAFe), a team can be successful with it. So in the following I will share my experience of several quite interesting projects:
A framework refrains from concrete prescriptions - for good reason. Such prescriptions are always dependent on a context. And that context cannot be known by the framework. The things you will find in SAFe, however, are amalgamations of prescriptions and random selection of examples. This makes it very hard for a user to find their way around the underlying model in order to instantiate it for themselves. So SAFe as it currently stands inhibit the ability for users to define their own methodology by throwing everything a given item could be at them. This is the exact opposite of what a framework should be doing.
The approach that brought us SAFe is very simple - some might say, daringly simplistic. It's basically this: take the SCRUM guide a, nd replace the words for the events, roles and artifacts with words for larger things, and there you have it. The principle applied here is self-similarity. In a later blog post I might elaborate on this using the material from a talk I give regularly at an annual in-house conference of my largest customer.
HOWEVER: With its focus on larger initiatives, in fact much larger than is recommended for a SCRUM team, SAFe gets you immediate attention from management at quite senior levels. This can be very helpful. If you don't mess up the initial version of your ART (team of agile teams), and that's easy to achieve, then you have a good chance at getting a large programme which runs a lot more smoothly than with previous approaches. Well, at least initially. The actual techniques people have to master in order to make such a release train succeed are nowhere to be seen in SAFe, barring the largest ones such as DevOps. Again, the guidance you will have find in SAFe has next to no value if you are the poor sod who actually has to come up with the solutions to making cheap and repeatable integration happen, for example. The SAFe guidance simply tells you that CI/CD are great things and mentions some good sources which re-enforce the message of how great an idea DevOps is. For the actual projects I have been working, there were significant integration issues across software, hardware and organisation boundaries. Again, I might elaborate on this at a later stage.
What many people mean when they talk about 'scaling agile', is the act of taking SCRUM and making it applicable to larger contexts by
drawing on the principles of self-similarity. Incidentally, this is the exact approach that brought us SAFe. However, the only thing companies really need to get
started is the Agile Manifesto and the 12 Agile Principles. And yes, one or more good coaches.
Trying to apply the mechanics of SCRUM or indeed SAFe and expect the organisation as a whole to become more agile as a result is a fallacy. In fact, SAFe takes away a lot of agility by catering to long-term increments and all the belated feedbacks that come with it. Aside from this, it is very hard for larger teams to perform time-efficient and cost-efficient product integrations. They are burdened by procedures and tools which do not support this properly. I can only advice very strongly to devote your attention to this challenge. If you want to reap the benefits of agility, you must solve this problem.
Deciding on a so-called framework such as SAFe or LeSS or any other, is in fact asking the wrong question if your are starting. In order to ask this question to your benefit you must first know where your organisation stands in terms of the complexity it faces, as well as where your products stand. Only then are you equipped to answer the question of how much agility is needed for a given context or product development effort.