With Scrum through the crisis?

Do you feel it? The next crisis is near. Or is it still the same crisis as in 2008? It doesn’t really matter. German exports are no longer growing as fast as they have in recent years. China is weakening, they say. The automotive industry has gambled away its exhaust gas tricks and has to let its pants down for the first time. And the central bank can’t really do much more after years of throwing money at the people. So it’s only a matter of time before the current uncertainty grows into the next crisis.

Even the agile movement seems to be in a bit of a crisis. The first hype about using agile methods outside of software development is over. Instead, one often has the impression that the wheel has already turned far in the other direction: Among the moderate representatives of the writers’ guild, it is now, so to speak, good manners to relativise the benefits of agile methods from the outset: According to this, Scrum and Co. could definitely be used profitably. But neither the environment nor the managers in most companies are able or willing to let agility develop. However, if you really want to be in vogue today, the best words to describe this are pseudo-agility, (fr)agility or the failure of the agile organisation. About the crisis of agility, so to speak.

Let’s allow the two crises to clash in our minds – in keeping with the motto “if a crisis, then the right one”. Maybe some inspiring thoughts will arise. Can one crisis victim perhaps help the operas of the other crisis? As a mental help we fix our thoughts on five “R’s” that characterise the essence of Scrum:

R for reaction

“Crises” always have to do with the fact that people, organisations and societies have to deal with change. “Every new adaptation is a crisis of self-esteem”, the philosopher and author Eric Hoffer once said. In clinical pathology, “crisis” is described as “the sudden change of an illness, for better or worse”.

Scrum not only accepts change based on the Agile Manifesto, but welcomes it – even late in the development process. If in a traditional environment the change in project requirements often triggers a crisis in the truest sense of the word, then in Scrum such a change is considered a normal process. Since the goal for the next sprint is based on what the team can (or believes it can) achieve and is not set as an absolute goal from above, such changes are manageable. Scrum reacts to changes in requirements by adjusting the priorities and goals for the team. In Scrum, the crisis that is triggered by not reaching a fixed goal is intercepted from the beginning by constantly reviewing and adjusting this goal in close cooperation with the customer. Scrum therefore offers a philosophy and a procedure that allows to react to changes instead of turning them into crises.

R for resonance

In Scrum the frequent coordination is not only limited to the relationship with the customer. Rather it runs through all areas of the project ecosystem. Daily Standup Meetings, the continuous involvement of the Product Owner in the development process (or the sales process in Sales Scrum or the planning process in the project business) or the frequent coordination with other stakeholders in the company all aim to create greater and more immediate resonance for what the team is doing.

And such resonance is especially necessary in crisis scenarios. Dietrich Dörner, for example, has shown that bad problem solvers obtain far less feedback than good problem solvers do. Instead, they tend to make decisions on their own. Under pressure this tendency becomes even more pronounced, which often significantly accelerates the course of a crisis. [1] From a certain stage onwards, crises are characterised by real spurts of activity. But the fact that many activities are undertaken does not mean that they are the right activities. And these activities often miss the customer in the crisis instead of helping him, the manufacturer’s most important ally. Like the participants in Dörner’s experiments, we tend to focus on the problems we can solve rather than those that need to be solved most urgently. As a result of this behavior, goal-directedness and solution competence for the actual problem suffer. [2] The frequent votes in Scrum are therefore quite justified – and especially in crisis situations they can help to break the downward spiral of missing feedback and increasing pressure to act.

R for reflexion

Psychology has shown in numerous experiments that people unconsciously cling to their own views, especially in crises – even if they know that these views are wrong. [3] When time and resources are scarce, decisions have to be made quickly and the pressure is high, a real mental adjustment process often sets in. The openness to deal with divergent ways of thinking decreases. Alternatives are seen as risks rather than opportunities – although they are often necessary to manoeuvre an organisation out of its current situation. The “framing effect” leads to negative opinions generating even more negativity. [4]

In this way, a downward spiral of scepticism and negative behavioural dispositions sets in, which excludes many helpful solutions from the outset.

Scrum attaches great importance to reflexion. The goals, the approach, the methods and the way we work together as a team are regularly questioned in Scrum. Above all, the assumptions on which the work was based are also questioned. The so-called “retrospectives” in which the team discusses the “soft facts” of the work are just as important as the “reviews” in which the “hard” facts are discussed. And they are a mandatory part of every sprint. Scrum teams are always designed to be as diverse as possible, so that existing assumptions and beliefs are scrutinised from many sides. Of course these measures are no guarantee that the crisis mechanisms described above will be avoided. But at least the institutional framework is in place.

R for rituals

As “institutions” in Scrum, many contemporaries will most likely first think of rituals such as the regularly recurring Daily Scrums (“Daily Standup Meetings”), the Sprint Planning Meetings, the Sprint Reviews and the Sprint Retrospectives. The iterative, rhythmic nature of Scrum, with its recurring cycles of Sprints and Meetings, invites association with the rhythmic beating of jungle drums during the tribal rite.

In crisis, rituals are a double-edged sword. For it can often be observed that organisations emphasise their well-rehearsed processes and rites to the extent that they seek to be a seemingly safe haven where the crisis seems to deprive them of the basis of their existence under their feet. As a result, the pressure to adapt within the organisation increases. At the same time, however, rituals create reliability, stability and trust. And they ensure that important elements such as the reflexion of the common togetherness do not fall victim to the daily business (or the hectic crises). In this respect they can be an important regulating – or better, dampening – element, especially in times of crisis.

R for roles

The sharp separation of the roles in Scrum is the other characteristic that is mentioned most often. On the one hand it ensures that responsibility – as paradoxical as this may sound in view of the emphasis on teamwork in Scrum – is individualised. Especially in crises the participants like to duck away. In the thicket of unclarified responsibilities, the own mistakes of the past can be comfortably sat out. And this is exactly where Scrum comes in: The Product Owner is responsible for ensuring that the customer’s point of view and wishes receive sufficient attention. If this is not the case, it is solely his fault – not the fault of the Scrum Master and not that of the development team. The tendency of superiors to micromanagement, which is often seen especially in times of crisis, is thus – if the roles are correctly defined and implemented – put a stop to this. The task of the development team is to help the product owner understand what the team can achieve in a given time frame and to implement the corresponding work packages in such a way that the customer receives a functioning, testable product. The Scrum Master, finally, has to keep the team free, remove obstacles and ensure that the team works in accordance with the agile philosophy. If this is not the case, he is to be held responsible, no one else.

A historical experiment illustrates why the individualisation of responsibility is important: In the 1880s, French agricultural inspector Maximilian Ringelmann had his men pull a cart and measured how hard each one of them pulled. And he found out that the more people pulled the cart, the less strongly the men pulled – even if the weight to be pulled was kept constant for the individual. In 1979 the American psychologists Stephen Harkins, Bibb Lantané and Kipling Williams coined the term social loafing for this phenomenon. [5]

Conclusion

Scrum shows its strengths especially when you apply its elements with the necessary degree of abstraction and mental flexibility. Often what you do is nothing new compared to what is commonly called “good management”. Scrum helps that you really do it. In this the framework is timeless. And timeless things survive crises – if they really exist. Does Scrum offer ways to overcome crises? I leave the answer to this question to you. If this text has provided some initial food for thought, it has achieved its goal.

Notes (in German):

[1] Dietrich DÖRNER, Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Reinbek bei Hamburg 2006, S. 29, 41
[2] Dietrich DÖRNER, ebd. S. 29, 90.
[3] Dietrich DÖRNER, ebd. S. 134-135
[4] Jochen MAI / Daniel RETTIG, Ich denke, also spinn ich. Warum wir uns oft anders verhalten, als wir wollen. München 2011, S. 114f.
[5] Dietrich DÖRNER, ebd. S. 262-264. Dieser Beitrag greift zum Teil auf Gedanken zurück, die Dr. Michael Scherm zusammen mit dem Gründer der OBI-Baumarktkette, Prof. h.c. Manfred Maus, in einem Gastbeitrag zur CEO Practice von Egon Zehnder veröffentlicht hat.

Dr. Michael Scherm has published more articles in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.