I know it is en vogue to bash other people and things. Most of the time three fingers are pointing backwards. It is the same with the Scaled Agile Framework (SAFe). I read a lot of SAFe bashings lately. And on agile conferences people are confirming to each other how terrible SAFe is. But SAFe is not the problem, it isn’t. Let’s see why. And let’s see how a different perspective might help us move past the ranting and move forward.
Why SAFe is not the problem
.
A model does not do agile transformations. People do.
First of all, models do not do transformations. People do. There are many more reasons why SAFe isn’t the problem, but that is really my main point.
Yes. SAFe is wrong.
Well, SAFe is a model. All models are wrong. Models are an abstraction. They are much less than reality, they are a simplification, they are … well, wrong. So, because SAFe is a model, SAFe is wrong. Models are not designed to be totally right. We design models as a tool for professionals. Professionals who complement the models with knowledge and wisdom. Professionals who interpret the results in the light of that context.
SAFe is wrong, but SAFe is useful.
If you understand that SAFe is a model and understand the limitations of models: SAFe can be a useful tool. Models help us navigate uncharted waters. They give guidance. But we must use any model with one very important thought in our mind: “Warning. This is a model. While it is useful, it is incomplete, it is an abstraction, it can lead to false results. Use it with care.” This warning also applies to SAFe.
The other scaling models are wrong and useful, too.
The sentence “Models are wrong – but useful” applies to other scaling models, too. (We call some “frameworks”, but for my article here, I stick to the term model.) Large Scale Scrum (LeSS) is great, too. Scrum@Scale is useful. I like Appelo’s “unfix organizational patterns”, too. When it comes to the complexity of larger organizations, there is no one size fits all solution. All scaling models are all useful. They provide different answers to different circumstances. And while they are all useful, they are all models, and they are all wrong.
Why we need scaled agile
.
We need Agile beyond the team level.
Some people say, “the problem is scaling in itself”. But ignoring scaling is not an option. There are many arguments against it. Reason one: Assume we work according to agile values and principles at the team level. Then it is helpful if we coordinate between the teams according to the same values and principles. (And many of us know how difficult it gets when we operate with different values at the team level than the rest of the organization.). Reason two: That local optimization in the teams doesn’t help the overall value stream. Reason three: The main idea behind agility is responsiveness in a complex environment. This is especially useful on an organizational level.
That future without larger organizations may never come.
Some people say that the time for big organizations has gone by. They say that the future lays in self-managed team entities. I am not arguing against it or for it – but I don’t see it soon. So, for the time being, let’s work with what we have as organizations right now.
Why scaled agile is inherently worse than team level agile
.
Buckle up: Scaled Agile has an exponential complexity
Scaled agile addresses agility with more than one team. This has an exponential complexity. Additionally social systems are non-deterministic. So, everything about scaled agile has an exponent and comes with non-determinism. This exponential complexity will not go away, whatever we do. So, we have to deal with this if we organize social systems that are larger than one team. And currently we must do that (see above).
Scrum can be bad. Scaled Scrum can be bad to the power of two.
Yes, SAFe implementations can be bad, indeed. Bad to the power of two – because of the exponential complexity. But that is not the fault of SAFe. We all know Scrum implementations that are bad, but we do not blame Scrum for it. (Sidetrack, yes, some people blame Scrum and offer Kanban as a solution. Yet, Scrum and Kanban are a happily married couple. Each one of the two hates it if we call either one “the better one”. Because they perform so well as a couple.) Good Scrum needs practice, lots of practice. The same is true for scaled agile. Additionally, scaled has that exponent attached to it. We need exponentially more practice. The problems are exponentially bigger. Coming to a common understanding with 100 people is exponentially more difficult. The agile transformation is exponentially messier. That is no-one’s fault. That is the consequence of larger social systems. And since “We need answers for scaled agile” (see above), we need to deal with this complexity. Ignoring is not an option. That also means that we need to invest more time. It might cost more. And it might take longer to see the results that everyone is hoping for.
Fixing the problem: knowledgeable users of scaled agile models and a real invest in agile transformation
.
Use scaling models in the light of agile values and principles
Since a model is an abstraction, we strip away much of reality in a model. When we use a model to make conclusions about reality, we must put that reality back in. To make any agile model useful, we need to interpret it in the light of two things. First, we must interpret it in the light of agile values and principles. Second, we must interpret it in the light of our own organization. Mindset and interpretation determine what kind of reality we make out of a model. E.g., a Daily Scrum can be a Morning-Reporting-Meeting or an event of self-management. That’s up to us team members. The same applies to SAFe: The PI Planning can generate a Gantt Chart. But it also can be a great collaborative refinement of a Product Backlog. It depends on us. A rant like “SAFe: A Waterfall Pig with Agile Lipstick” shows how this also works in the opposite. You can intentionally misinterpret a model. With the right mindset SAFe can be helpful, with the wrong mindset it can be harmful. It depends on how we want to see things.
Don’t think of SAFe as a framework like Scrum. Use SAFe as an encyclopedia.
SAFe calls itself a framework. Scrum calls itself a framework. The use of the same term leads people to think that Scrum and SAFe are something like the same thing. They are not. Scrum is a framework where you don’t deselect elements. SAFe is an encyclopedia of patterns, where deliberate selection is essential. When we understand the encyclopedia idea, we can use SAFe properly – and be more successful.
Build on in-depth knowledge of Scrum, Kanban, etc.
As an encyclopedia, SAFe does no go deep into frameworks. Scrum is a whole model on its own. The same applies e.g., to Kanban, or Design Thinking. SAFe does not replace those frameworks, it rather assembles them. For example, the SAFe article on Kanban is useful. But it does not replace education, and practice, and in-depth knowledge of Kanban. Scaled Agile needs in depth knowledge of the models it assembles. So, build an interdisciplinary team. Within the team there should deep knowledge with the models referenced in SAFe. And the team should participate actively in the community working on scaled agile.
SAFe is incomplete. SAFe is not the only thing in the world. Look beyond.
There are many articles in SAFe. Some people even blame the encyclopedia for listing so much. Yet SAFe is far from being complete. And SAFe really, really is not the single source of truth. When Program Increments are not the right choice: Select LeSS-like Sprints. The unfix pattern of flexible team composition fits to your organization? Why wouldn´t you choose it, if it seems to be the best option for your current situation?
See how SAFe, Scrum@Scale, LeSS, unfix complement each other
Let’s look beyond the different naming conventions in the Scaled Agile models. Then a lot of similarities become visible. This is no surprise. There is a limited set of patterns we can use to organize the work of several teams. The values and principles of Lean and Agile frame and thus limit the options of the scaled agile patterns. That means, the different Scaled Agile models are not competing. They are rather complementing each other. This is one more reason not to rant, but to look, compare and learn.
Do not reinvent the wheel.
SAFe and the other scaled agile models provide a big benefit. They offer proven solutions (patterns) for typical situations. There is no need to reinvent the wheel and go through all the trouble of creating and perfecting it. Fitting and adopting is already hard enough, so save your energy for that. The only exception would be: the situation is new.
Stick with known terminology.
Agile terminology is already confusing enough. E.g.: “story” is a size, “user story” is a technique, and Jira uses the term “ticket”. Don’t add to that confusion. Use known terminology that allows people in your organization to look up stuff in the world wide web. The scaled agile frameworks help with sticking to terminology. Pick one and stick to it. A mix-and-match approach between the frameworks’ terminologies is not useful. And remember: all models are wrong.
Do not forget the first rule of scaling: do not scale.
Just because there are scaled agile patterns it is no reason to use them. Invest in the first rule of scaling: Do not scale. In a scaled environment, everything is exponential, also our savings from decoupling. Examples are: Instead of a large solution, use a portfolio of uncoupled ARTs. Instead of an portfolio Kanban, use objectives and key results (OKRs). As always with agile, use the simplest solution that does the trick.
Take the agile transformation seriously.
You don’t become agile by rolling out an encyclopedia. A scaled agile transformation takes – surprise, surprise – exponentially longer than adopting agile at the team level (and how long did that take you?). The screw ups are exponentially bigger. The pain is exponentially bigger. Little problems at the team level surface when teams synchronize. Thus, take your time and add a long-term change management approach to your SAFe roadmap. The articles on change management in the SAFe encyclopedia are a good start. Again, they do not replace knowing change management in depth. Change Management is a whole body of knowledge. Apply it. Not only the article.
More agile transformation
My colleague Vincenzo Parisi has written a good article about screwing up with SAFe. In his humoristic way he lists the dos as don’ts: “How to masterfully screw up your SAFe implementation”. I think it is worth your time.
About Me
I am Malte. I have many years of experience with agile, frameworks and organizational change management. I have a history of product development. I fathered a consulting company. I wrote one of the early books on scaling agile (updated yearly since). We put in place agile with teams and organizations. We use all that stuff with ourselves. And we support many clients. That’s my colorful background, so you know.
