Das agile Missverständnis - the agile misunderstanding

(please find the english version below)

28 Jahre nach der Wiedervereinigung ist Deutschland wieder geteilt. Organisatorisch gibt es diejenigen, die Software machen, und den Rest. Die einen nutzen agile Methoden wie Scrum oder Kanban. Der Rest lebt seine Hierarchien, verteilt Aufgaben und kontrolliert. Die Frontlinie verläuft häufig zwischen Kunden und Dienstleistern, in großen Softwarefirmen zwischen Vorstand und Rest oder zwischen Software-Teams und Fachabteilungen (ja, die gibt es noch). In Start-ups irgendwo zwischen Geldgebern und der Mannschaft. Damit verbunden ist eine Menge gegenseitiges Nichtverstehen, weil beide Seiten ihr inkompatibles Tun verteidigen, ohne darüber zu sprechen, warum genau sie was tun. Grund genug, mit ein paar Missverständnissen aufzuräumen.

Was ist agil?

Genaugenommen fehlt es an einer klaren Definition. Oft lesen wir „agile Vorgehensweisen, beispielsweise Scrum oder Kanban.“ Das klingt nicht präzise. Manche Netzquelle schlaumeiert: „Unter Agilität versteht man alle Methoden, die agil sind.“ Schönen Dank. Technisch trifft am ehesten die Aussage zu, dass alle Methoden agil sind, die die abstrakten Werte und Prinzipien des agilen Manifests in die Praxis umsetzen. Damit ist ein Schirm gemeint, unter den Methoden und „Hacks“ (= Kniffe) nach Belieben schlüpfen können, wenn sie Menschen, funktionierende Produkte, Kunden und Flexibilität in den Vordergrund stellen. Deshalb werden auch ältere Lösungen – wie das allermeiste Lean-Instrumentarium – von der Agilitätsbewegung vereinnahmt. Geschenkt. Schauen Sie doch einfach mal anhand der genannten Kriterien Ihre eigenen Regeln und Arbeitsweisen durch, da merken Sie schnell, was davon alles agil ist und was nicht.

Warum agil?

Gerne wird behauptet, wir hätten ja Fachkräftemangel und müssten den jungen Leuten anders begegnen, sonst fühlten sie sich nicht wohl. Oder noch allgemeiner: Das Zeitalter der Selbststeuerung sei angebrochen und deshalb ein neues Führungsverständnis vonnöten. Beides mag sein, geht aber am Kern der Sache vorbei.

Der da ist: Software ist oftmals sehr neuartig. Und anfangs ist noch nicht klar, wohin die Reise gehen wird, welche Funktionen die Kunden goutieren werden und welche nicht. Genaugenommen ist das Neue, dass die Kunden selbst in vielen kleinen Schritten die Produktentwicklung mit ihrem Feedback steuern. Dann laufen viele klassische Lösungen und Prozesse ins Leere, die vor der Auftragserteilung beschrieben sehen wollen, was konkret am Ende, wann und zu welchem Preis geliefert werden und auf Anhieb perfekt funktionieren wird.

Ganz generell gilt, wenn man unterwegs ist und nicht weiß, wo man hinwill oder was einem auf der Reise passiert, ist man besser dran, wenn man schnell reagieren kann. Wenn die Beteiligten selbst Alternativen entwickeln, abwägen und handlungsfähig sind, ohne dass ihre Signale in der unendlichen Befehlskette bis ins Hauptquartier und zurück versanden können. Klassische Organisationen verschwenden nämlich unendlich viel Geld. Weil Arbeitsteilung, starre Kapazitäten und standardisierte Prozesse nicht angemessen in der Lage sind, Neues zu produzieren und mit Überraschungen umzugehen. Und da es immer wichtiger wird, zügig Neues zu schaffen, gibt es agile Methoden und finden sie rasend Verbreitung.

Sind uns diese Hintergründe erst einmal bewusst, können wir als Vertreter der Softwarewelt den Nutzen einzelner Bausteine und Modifikationen ableiten, ohne einfach nur das Gelernte inquisitorisch zu verteidigen („ein Kanban ohne Cumulative Flow ist kein Kanban“), und wir erhöhen unsere Fähigkeit, funktionierende Lösungen zu entwickeln, statt uns nur gegenseitig zu erzählen, wie wir die Dinge gerade tun („interessant, das probiere ich auch mal aus“).

Muss ich das auch?

Viele sehen in der Zusammenarbeit mit ihren Software-Dienstleistern die neue Welt und wollen das auch: Weniger planen, schnelle Entscheidungen, ausprobieren. Try und Error, ohne Anträge, Dokumentation und Rechtfertigung. Dafür holen sie sich einen Berater aus der Software-Branche, der ihnen die Zutaten vermittelt. Mitarbeiter erlernen agile Methoden und wenden sie auf ihre Aufgaben an. Manchmal funktioniert das, manchmal nicht. Über kurz oder lang wächst die Skepsis im Management, werden Rollen eingespart oder das Ganze verkümmert, weil es die Zutaten für Software-Suppe sind und nicht für den Industrie-Wrap oder den Dienstleistungs-Salat. Allein die Annahme, der Lieferant darf immer dann die versprochene Funktionen reduzieren, wenn er nicht wie erwartet vorankommt, wird in 99% aller traditionellen Wirtschaftsumgebungen Widerstand erzeugen.

Deshalb sollten Sie sich lieber fragen: Wieviel Neues brauche ich? Wie schnell muss ich eigentlich sein? Früher reichte es, ab und zu mal zu schauen, was die anderen machen und zu sehen, auf welchen Zug wir aufspringen. Heute sind fast nur noch ICEs unterwegs. Die zudem immer schneller fahren. Deshalb werden alle, die sich nicht grundlegend verändern und ihren eigenen Zug auf die Reise schicken, in ihrem Kochtopf den Froschtod sterben.

Viele Großunternehmen haben das erkannt und kaufen sich Start-ups als Vehikel, in denen radikal Neues entsteht. Manche beginnen auch, ihre eigenen Arbeitsweisen zu verändern. Irgendwann knirscht es dann, weil sie liebgewordene Zöpfe abschneiden müssen. Denn individuelle Boni, zentrale Debattierzirkel und Entscheidungen sowie hunderte liebgewonnene Rituale sind mit den neuen Gesetzmäßigkeiten, Geschwindigkeiten und Flexibilitäten entweder nicht kompatibel oder zumindest für den Erfolg sehr schädlich. Dann wird es richtig spannend, wie das im Einzelfall ausgeht.

Für Mittelständler und kleine Unternehmen bedeutet das: Was tun Sie, um Ihr notwendiges Maß an Neuem zu schaffen und so flexibel zu sein, wie es Ihr Markt erfordert? Sind Ihre Kapazitäten so anpassungsfähig, dass nichts liegen bleibt? Schaffen Sie sich immer mehrere Alternativen? Wird am gleichen Tag entschieden? Ist die soziale Dichte hoch und alle wissen immer Bescheid? Das wird notwendigerweise Ihre Organisation verändern. Dabei brauchen sie nicht hektisch nach den erstbesten Methoden zu greifen, die Ihnen euphorisiert von Branchen gereicht werden, die anderen Gesetzen gehorchen als die ihrige. Viel wichtiger wird es sein, authentisch zu bleiben und sich so zu organisieren, wie es zu Ihnen passt. Und wenn es funktioniert, wird das Ergebnis zwangsläufig das sein, was heute gemeinhin unter dem Begriff „agil“ verstanden wird.

The agile misunderstanding

Germany is divided again 28 years after reunification. Organizationally, there are those who do software and the rest. The first use agile methods like Scrum or Kanban. The rest lives its hierarchies, distributes tasks and controls each others. The frontline is often between customers and service providers, in large software companies between the board and the rest, or between software teams and departments (yes, they still exist). In start-ups, somewhere between founders and the team. Linked to this is a lot of mutual incomprehension, because both sides are defending their incompatible actions without discussing exactly what they are doing. Reason enough to clear up with a few misunderstandings.

What is “agile”?

In fact, there is no clear definition. We often read "agile approaches, such as Scrum or Kanban." That does not sound precise. Some sources on the internet are smart talking: "Agility is all methods that are agile." Thank you. Technically, the most obvious statement is that all methods are agile that put into practice the abstract values and principles of the agile manifesto. This serves as an umbrella under which methods and "hacks" can slip at will, if they put people, functioning products, customers and flexibility in the foreground. That's why even older solutions - like the vast majority of lean instruments - are absorbed by the agility movement. Given. Just take a look at your own rules and working methods based on the mentioned criteria, and you'll easily realize what's agile and what's not.

Why agile?

It is claimed that we have a shortage of skilled workers and therefore have to treat the young people differently, otherwise they will not feel well and leave us. Or more generally: The age of self-organisation has begun and therefore a new understanding of leadership is needed. Both may be, but misses the heart of the matter:

Software projects are often very vage in the beginning, it's not clear where the journey will go, which features the customers will like and which they will not. Strictly speaking, what is new is that customers themselves control the product development with their feedback in several small steps. Then, many classic solutions and processes go into the void, which want to see before the purchase order is being issued, a precise description of what will actually be delivered at the end, when and at what price and will of course work perfectly right away.

In general, if you're on the road and do not know where you are going or what will happen to you on the journey, you're better off if you are able to react quickly. When all in your team develop alternatives, weigh up and are capable of action, without their signals getting stuck in the endless chain of command to the headquarters and back. Classical organizations waste a lot of money in doing so. Because division of labor, rigid capacities and standardized processes are not adequately able to produce new solutions and deal with surprises. And as it becomes more and more important to quickly create something new, there are agile methods and they are spreading rapidly.

Once aware of these backgrounds, we, as part of the software industrial complex, can better understand the benefits of individual methods without simply inquisitorially defending what we have learned ("a kanban without cumulative flow is not a kanban"), and we increase our ability to develop functioniong solutions ourselves instead of just telling each other how we're doing things ("interesting, I'll try that out").

Do I need to do that, too?

Many are working with their software service providers and see new regimes and want it too: planning less, making quick decisions. Try and error, without requests, documentation and justification. For this they hire a consultant from the software industry, who teaches them the ingredients. Employees learn agile methods and apply them to their tasks. Sometimes that works, sometimes not. Sooner or later skepticism grows in the management, roles are economized or the whole thing is stunted, because it's the ingredients for software soup and not for the industrial wrap or service salad. Alone the assumption that the supplier is allowed to reduce the promised functions whenever he does not progress as expected, will create resistance in 99% of all traditional economic environments.

Therefore, you should ask yourself: How much new do I need? How fast do I have to be? In the past it used to be enough to look at what the others are doing every now and then and to see which train we jump on. Today, almost only express trains are on the way. They drive faster and faster. Therefore, those who do not change fundamentally and send their own train on the journey will die frog death in their cooking pot.

Many large companies have recognized this and are buying start-ups as vehicles in which radically new things are created. Some also begin to change their own ways of working. At some point it crunches because they have to question old habits. Because individual bonuses, central debates and decisions as well as hundreds of further rituals are either incompatible with the new laws, speeds and flexibilities or at least very damaging for the success. Then it gets really exciting, what comes out in the individual case.

For SMEs and small businesses this means: What do you do to create the rate of innovation you need and to be as flexible as your market requires? Are your capacities so adaptable that chaos can´t happen? Do you always consider several alternatives? Will the same day be decided? Is the social density high and everyone always knows what´s going on? That will necessarily change your organization. You don´t need to hectically implement the first-best methods that are euphorically presented to you by industries that obey other laws than yours. It will be much more important to stay authentic and to organize yourself as it fits you. And if it works, the result will inevitably be what is commonly understood today as "agile".