More agile without Scrum?

Jürgen Knuplesch begins his article with the postulate that complexity is a measure of predictability, but not of comprehensibility. Humans are complex: they are adaptable, but do not necessarily act predictably. A person can respond very differently to the same stimulus twice because they learn and adapt. Imagine a five-year-old child calling you an idiot. You will certainly react very differently than if a colleague of the same age does the same. So it always depends on the context. So there is no universal answer to the question "How do you react when someone calls you an idiot?".
 
Just like people, the market is a complex adaptive system. When a new product comes onto the market, competitors often react quickly and develop products that can compete with it. This is where Jürgen Knuplesch comes in, because for him it is the same with agile consulting. Here, the focus is on self-organization in the team, because the team can assess the context better than a Scrum Master.
 

There have been a great many attempts in the past to find a universal and universally applicable approach to managing complex projects. And the efforts continue, because even if many managers have already found a way and prefer to use one method, a perfect and unchallengeable way simply does not exist. The inventors of Scrum rather want Scrum to be perceived and referred to as a framework, not necessarily as a process. The context just mentioned also plays a crucial role here. Scrum was intended from the beginning to approach the respective context step by step and to find a solution that depends on this context. Continuous change is the solution. Jürgen Knuplesch emphasizes at this point that the simple introduction of Scrum does not automatically turn a company into an agile company. Scrum can be used for agile methods - but it does not have to be.

This is where Jürgen Knuplesch starts to tell one of his instructive stories. It's about a team working on a product that has been used by many customers for some time. The team works on known bugs, discovers new bugs and works on them as well. There are tests taking place all the time. Routine tasks. Reduce bugs. Everyone is bored. How to motivate here? What can the manager say to inspire the team? The manager Jürgen Knuplesch came up with accepts the challenge and reminds his team that maintenance contracts are the company's cash cow. The team that reduces bugs earns the bacon for the whole company. It clears the way for new development and innovation, where no bacon is (yet) earned. Jürgen Knuplesch wants his imaginary team to see themselves not as the poor victims who have to take on the boring tasks, but as the heroes of the company who secure everyone's existence.  At every opportunity the manager points out this fact to his team. He also submits his view to the new developers, who like to see themselves in a privileged position.  An approach that bears fruit. A good idea.
 
The manager looks at the bug reduction process and wants his team to stop trying to fit reality to the processes, but to organize themselves to better fit reality. Each area has a developer. The ideal of cross-functional separation of powers is still pursued. But the tasks are simply too daunting for the number of developers. Not an unrealistic scenario. All developers are aware that there is way too much work.
A joint decision is made with the product owner to reschedule the backlogs based on people. Not ideal, but it shows success. The backlog becomes a bit clearer and the prioritization is clearer. Unfortunately, the product owner is no real help due to lack of knowledge in the field of development. He can only see the priorities from the customer's point of view, which sometimes makes it difficult to coordinate with the developers. This brings a higher responsibility for the developers. Thus, the team says goodbye to Scrum. Patch increments are determined solely by the deadline negotiated with the customer. Patch managers and product owners work closely together. But none of this has much to do with Scrum anymore. But: what works must be seen as positive.
 
What Jürgen Knuplesch wants to make clear with his story is that Scrum should not be seen as a prime directive. Scrum is a good concept that often leads to the goal. But unusual circumstances require unusual measures. Sometimes even normal circumstances call for unusual measures. Too much work, too few people, too much stress. Humans are, after all, known to be adaptive systems. In some ways, moving away from Scrum is even more agile than using Scrum in some situations.