I will try to describe a problem around the topic of “agile methods” from my own perspective, because I think it is relevant. And here we go: Recently I discovered an answer from Ron Jeffries (XP) on Twitter about about the (un)popular SAFe:
My first reaction was: “Yeah, that’s how I see it. Basically, SAFe is just BAD.” With a little reaction time, however, a lecture by Henrik Kniberg came to my mind (“Is SAFe EVAL?” https://youtu.be/TolNkqyvieE), in which he reflects on this question in a very differentiated way and reports how they tried out “Big Room Plannings” at Lego. All this with SAFe as a framework in mind.
Ok, your own world picture briefly shattered again?
Next thought: If I am in an organization that really wants to “introduce” Scrum, then I get a bad feeling in my stomach. What exactly are the problems to be solved? Does the organization see them or is it more of an abstract concept in the mind of a few individuals? Why exactly should Scrum be the solution? In my experience, if organizations have transparency about the actual problems they face, they will find solutions that can be implemented almost instantly with much less resistance and then addresses the real problems in a target-oriented way. Of course, agile methods like Scrum (or SAFe for that matter) can be an inspiration. But they remain the means to an end.
And what about SAFe?
When I think a bit further here, I could say that if agile methods or frameworks are more likely to contain solutions, then it is very likely that the problems they address are actually present in more than one organisation. However, these methods then always offer little support in identifying and understanding the problem itself. They propagate a specific solution. At the same time, we as Komplexitäter in our work with different organizations notice more and more that specific problem patterns appear again and again. The organisations themselves are never aware of this. For them these problems are rarely transparent. They are therefore almost never discussable for the people in the organization. Scrum, SAFe and Co. are never the solution in this environment, but in many cases they are already part of the problem (“In our company agile method XYZ somehow doesn’t work. Can you help there?”). What we as coaches do then has a lot to do with making problems visible and discussable. In the truest sense of the word it is often first of all about developing terms and language for the existing problems in the organisation. And it is precisely here that the familiar agile methods, to put it mildly, tend not to help. They offer a supposed shortcut that quickly leads to a dead end.
Practical example of one agile method
A team I recently joined asks me if I can explain to them exactly how the “Planning Poker” would supposedly work “right”. They have tried it before and it always came to unsolvable discussions within the team about what exactly should be estimated. There was no clear answer to my question as of what real problem the team wanted to solve by playing poker (“we heard that this is how it’s done”, “estimates could be helpful for planning”)
In the next retrospective, they address the issue that almost all the tasks they start are blocked shortly afterwards. Either there is a need for internal coordination within the team in order to implement the task or the first developer who looks at a task needs immediate clarification of its subject matter and the team is waiting for PO and stakeholders. There is no continuous backlog refinement yet. The team realises that it is a problem if the entire team is only involved very late in the process. As a solution they use the Scrum Guide and try out a first Backlog Refinement as a one-hour meeting. As a method I suggest, to the surprise of the team, “Planning Poker”. The team uses the method only as a way to quickly get to the points where they still have questions or need clarification. The estimation itself is basically not used any further and the question of “what and how do we estimate” could be answered much easier by the team now.
In the following retro, the team realizes that they are much better prepared to work on a task via the “Planning Poker” solution, all have a general idea of what it is all about and what the others are working on at the moment. As a result, there are fewer questions during the course of the work on specific tasks, and if there are any questions, they can usually be answered more quickly, because everyone already has a rough idea of what it’s all about.
This example shows that the “Planning Poker” tool could only have an effect when there was a real problem, which everyone accepted, that should be solved. Of course, I can imagine that there are also cases where people simply try out a tool (ideally following the instructions) and see what advantages it offers. In the context of agile methods this seems to me to be the exception rather than the rule.
tl;dt
Hypothesis – “Solution-oriented agile methods and frameworks such as SAFe and Scrum indicate generalizable problems. They contribute little to a better understanding of the problems itself. The problem patterns then repeat themselves in organizations. However, this organizations lack the fundamental tools to recognize problems and thus make them treatable at all. Organizations then introduce solutions that cannot have a lasting effect without a deeper understanding of the problems.”
What do you think? Do you know of any practical experiences that do not fit my hypothesis? What speaks against my considerations?
Inspiriert? 
