17

Die Agilitäts-Lüge

Seit 5 Jahren beschäftige ich mich mit dem Thema Agilität, Scrum, Kanban usw. Ich habe erlebt, was funktioniert und was nicht funktioniert. Ich habe eine Idee, was es braucht, damit Agilität funktioniert. Und das hat wenig mit dem zutun, was in vielen Artikeln über Agilität drin steht. Ich muss heute mal mit Dir über die Agilitäts-Lüge sprechen.

Die Sau die momentan durchs Dorf getrieben wird hat viele Namen: Scrum, Kanban, Scrumban oder auch gern unter dem Deckmantel des Lean-Gedanken.

Ich spreche von Agilität.

Ich spreche von der Wunderwaffe gegen aus dem Ruder laufende Projekte, gegen die Mauer zwischen Entwicklung und Betrieb und natürlich die einzige Möglichkeit die komplexe Welt von heute zu beherrschen.

Du fragst Dich, was ist denn jetzt mit dem Sieber los? Ist der verrückt geworden? Der hat doch mit  Carsten Krautwald über Kanban im IT-Service-Management und mit Dierk Söllner über Agilität im Allgemeinen gesprochen. Und hat er nicht auch ein Whitepaper über agile Praktiken geschrieben?

Ja, Du hast Recht – das habe ich. Ob ich verrückt bin oder nicht, entscheide bitte am Ende des Podcasts selbst.

Zu Beginn ein kleiner Blick zurück: Ich durfte in den letzten fünf Jahren ein Team von Softwareentwicklern auf ihrer agilen Reise begleiten. In dieser Zeit wurde ich zum Scrum Product Owner ausgebildet und hatte das Vergnügen an einer Management 3.0 Schulung teilzunehmen. Ich lese viel über das Thema und beschäftige mich damit.

Und genau hier komme ich auf den Titel dieser Episode: Die Agilitäts-Lüge. Ich möchte provozieren, denn ich finde es problematisch, was und vor allem wie über Agilität geschrieben wird. Ich bin der Meinung, es entsteht ein ziemlich verzerrtes Bild. Ein Bild, welches eine unrealistische Erwartungshaltung weckt.

Wie siehst Du das?

Wäre ich unbedarft, könnte ich den Eindruck gewinnen, dass ich einfach nur ein Board, Sprints und einen Product Owner brauche und schon wird alles gut. Und wenn es nicht klappt, dann sind die Organisation und ihre Randbedingungen schuld, die Agilität nicht zulassen.

Dem ist aus meiner Erfahrung nicht so. So einfach ist die Erklärung leider nicht.

Lass uns von vorn anfangen:

Wozu brauchen Du und ich Agilität?

Viele Menschen leben in dem Glauben, dass sie mit immer genaueren Plänen und immer kürzeren Reportingzyklen, die Zukunft vorhersagen und damit steuern können. Das mag auf eine Reihe von Branchen zutreffen, allerdings bei weitem nicht mehr für alle.

Ganz deutlich wird das bei softwarebasierten oder eben digitalen Geschäftsmodellen. Dort wo Kunde und Technik verschmelzen, dort wo Konsument und Produzent zum Prosumer werden. Die Vorhersagbarkeit hat ein Ende.

Du fragst warum?

Weil wir spätestens dann, wenn der Mensch ins Spiel kommt von komplexen Vorhaben sprechen. Diese sind nicht planbar. Der Mensch ändert sein Verhalten, seine Meinung von heute auf Morgen. Der Mensch kann das, was er möchte häufig nicht gut beschreiben.

Das bedeute im Umkehrschluss, dass die Entwicklung eines Service oder eines Produktes schnellen Veränderungen unterliegt. Noch viel mehr, wenn wir uns nicht in einem blauen Ozean befinden. Als blauer Ozean wird im Vertrieb ein Geschäftsmodell mit keinen oder wenigen Konkurrenten bezeichnet.

Bitte jetzt nicht falsch verstehen – nicht nur weil ein Mensch dabei ist, handelt es sich gleich um ein komplexes Vorhaben. Das möchte ich Dir an einem Beispiel erläutern: Nimm den motorisierten Raupenbagger von Lego Technic  oder den Lego Technic Unimog. Der Aufbau ist kompliziert. Zumindest für mich. Zum Glück gibt es eine Anleitung.

Wenn ich dieser Schritt für Schritt folge, dann werde ich am Ende auf jeden Fall ein funktionsfähiges Modell haben. Ich werde unterwegs ein paar Fehler machen, aber ich werde es hinbekommen. Nur weil Du oder ich das Modell bauen, ist das kein komplexes Unterfangen. Es ist einfach „nur“ kompliziert. Es gibt eine feststehende, unveränderliche Anleitung wie Du und ich das Modell bauen können. Ich denke, den Aufbau könnte auch eine programmierte Maschine erledigen.

Anders ist das beim Berliner Flughafen. Klar, auch da gibt es einen Bauplan. Auch wurden schon an anderen Stellen Flughäfen gebaut. Jedoch sind bei einem solchen Großprojekt die Rahmenbedingungen so individuell und die Anzahl der zu koordinierenden Beteiligten so hoch, dass das es auf jeden Fall ein komplexes Projekt ist.

Dieses Projekt lebt, weil es ständiger Veränderung unterliegt. Der Aufbau des Unimog ist ein totes Projekt – da ändert sich nichts.

Das heißt, wenn wir – und damit meine ich die gesamte Organisation – anerkennen, dass die Planbarkeit komplexer Vorhaben eine Illusion ist, dann dürfen wir über Agilität sprechen.

Agilität bedeutet nämlich wendig – schnelles Reagieren auf sich ändernde Rahmenbedingungen. Das ist die Stärke einer agilen Organisation oder eines agilen Projektes.

Das bedeute für Dich, dass Du ganz kritisch prüfen darfst, ob Dein Vorhaben kompliziert oder komplex ist. Bevor Du ein Vorgehensmodell wählst.

Was meinst Du, ist IT-Betrieb kompliziert oder komplex?

Dazu gehe ich einen Schritt weiter und behaupte, dass Agilität dann angezeigt ist, wenn wir das Ziel eines Vorhabens und den Weg dorthin nicht genau kennen können. Würden wir Ziel und Weg kennen, dann wäre die Wendigkeit einfach ein Risiko zu viel. Wir könnten einen Plan entwerfen und diesem stur folgen.

Wie ist das jetzt mit dem IT-Betrieb? So genau bin ich mir da noch nicht sicher.

Der Regelbetrieb ist gut beschrieben. Es gibt die Systemhandbücher, Checklisten und Prozeduren, die einfach abgearbeitet werden. Das ist sicher kompliziert, aber nicht komplex.

Jetzt kommt es zu einer Störung. Auch hier tendiere ich dazu, die Komplexität zu verneinen, denn das grundlegende Verfahren zur Störungsbehebung ist bekannt und das Ziel auch. Ähnlich sehe ich das für Problem- und Change-Management.

Solange Du im eigenen Saft des technischen IT-Betriebes schmorst, bleibt es bei kompliziert. Oder?

Komplex wird es, wenn Du Dich auf die Ebene der Geschäftsprozesse begibst. Denn dann färbt fehlende Planbarkeit innerhalb der Unternehmen auf Dich ab. Hast Du das Ziel, das Geschäft so gut wie möglich zu unterstützen, wirst Du mit sich ständig verändernden Anforderungen konfrontiert sein. Da ist Wendigkeit ein wirklicher Wert.

Das beantwortet die Frage: Wozu brauchen Du und ich Agilität? Wir brauchen sie, um mit unklaren Zielen und einem unklaren Weg zum Ziel sinnvoll umgehen zu können. Wir werden auf dem Weg Fehler machen. Ein agiles Vorgehen stellt sicher, dass wir schnell erkennen, ob wir dem Ziel näher kommen oder einen Fehler gemacht haben.

Beispiel gefällig? Lass mich dazu in die Softwareentwicklung gehen. In der „agilen Sprache“ gibt es die Iteration. Die Iteration ist ein zeitlich begrenzter Projektabschnitt, in dem ein vereinbartes Ergebnis geliefert wird.

Anders ausgedrückt: Der Kunde und der Auftragnehmer einigen sich für eine Iteration von einer Woche, dass eine bestimmte Softwarefunktion fertiggestellt wird. Nach dieser Woche wird das Ergebnis dem Kunden präsentiert und dieser entscheidet, ob es das ist was er wollte oder nicht.

Da nach kurzer Zeit eine Ergebniskontrolle erfolgt, erkennst Du Fehlentwicklungen sehr schnell. Zusätzlich hast Du die Möglichkeit, auf sich ändernde Anforderungen zu reagieren, weil Du eben nicht für Monate vorplanst. Das ist die Wendigkeit.

Fehler frühzeitig erkennen und Wendigkeit – das sind die Gründe, warum wir Agilität brauchen.

Damit sind wir bei der zweiten Kernfrage:

Was ist Agilität?

In den Artikeln, die ich lese, steht häufig, dass Agilität eine Methode ist, die viel besser als die Wasserfall-Methode oder das V-Modell für Projekte geeignet ist. Das verstehen viele, Probleme mit Projekten gibt es immer. Dann ist es ja gut, dass es an der Methode liegt. Die kann ausgetauscht werden.

Also: Auswahl eines geeigneten Vorgehensmodells, Schulung und mit ein wenig Glück auch noch die Anpassung an das eigene Unternehmen. Wenn das fertig ist, dann ist die Organisation agil – schließlich arbeitet sie jetzt nach Scrum.

Kommt Dir das bekannt vor? Die Geschichte kennen wir doch irgendwoher, oder? Ich sag nur ein Stichwort: ITIL-Einführung. Ja, da ist das genauso gelaufen. Das Ergebnis ist bekannt.

Zurück zur Agilität. Agilität ist keine Methode! Agilität kann man nicht einführen. Scrum führt nicht zu einer agilen Organisation.

Ich kenne jetzt genügend Menschen, die mich nun lünchen wollen. Bitte wartet noch kurz.

Für mich gibt es sechs Punkte, die erfüllt sein dürfen, wenn eine Organisation agil sein möchte:

1. Jeder Mitarbeiter übernimmt die Verantwortung für sein Handeln und seine Arbeitsweise.
2. Jeder Mitarbeiter übernimmt die Verantwortung für die Zusammenarbeit in seinem Team.
3. Jeder Mitarbeiter übernimmt die Verantwortung für das Erreichen des Gesamtzieles einer Iteration und nicht nur für sein eigenes Teilziel bzw. seinen eigenen Beitrag.
4. Offenheit und Transparenz werden wertgeschätzt, gefördert und eingefordert.
5. Experimentieren wird gefördert und Scheitern begrüßt. Es geht darum beim nächsten Mal besser zu Scheitern.
6. Das Team arbeitet kontinuierlich an der Verbesserung der Zusammenarbeit, Projektabwicklung und den eigenen Skills und kommuniziert offen über Probleme und Hindernisse.

Agilität ist eine Grundhaltung, Geisteshaltung und ein Standpunkt, der sich an den Handlungen und dem Verhalten jedes Einzelnen ablesen lässt.

Ein Team, welches mit Scrum oder Kanban arbeitet, Standups und Retrospektiven durchführt, ist noch lang nicht agil, wenn jeder nur seinen Aufgabenbereich sieht und die Komfortzone nicht verlässt, im Standup die Fehler und Probleme nicht angesprochen werden und in der Retrospektive Kuschelkurs gefahren wird.

Es ist nicht damit getan, ein neues Vorgehensmodell einzuführen. Wer den Anschein erweckt, dass dem so ist, der lügt.

Es ist allerding schon so, dass im ersten Schritt nach der Einführung von Scrum oder Kanban die Ergebnisse besser werden, Probleme verschwinden und alle zufrieden sind.

Scrum und Kanban bedienen sich Werkzeuge, die auf der einen Seite Transparenz schaffen – zum Beispiel das Taskboard und die Daily Standups – und auf der anderen Seite dafür sorgen, dass bisher existierende Grenzen aufgehoben werden. Wir sprechen im agilen Umfeld immer von den cross-functional Teams. Das heißt, ein Team hat alles Wissen und alle Fähigkeiten, um selbständig die Aufgabe zu lösen.

Diese einzelnen Elemente bringen sehr schnell einen Nutzen. Aus dieser Erfahrung heraus habe ich auch das Whitepaper geschrieben, in dem ich 7 agile Werkzeuge im Kontext IT-Service-Management beschreibe.  Das Whitepaper kannst Du Dir hier anfordern:

Die Einführung von Scrum, Kanban oder die Nutzung einzelner agiler Praktiken kann nur der erste Schritt sein, wenn Du es ernst meinst. Um langfristig mit agilen Methoden Erfolg zu haben, bedarf es einen kulturellen Wandel der Organisation und jedes einzelnen Menschen.

Das Schwierige und Aufwändige ist die Menschen auf dem Weg zur Selbstorganisation und Selbstverantwortung zu begleiten. Das ist eine enorme Veränderung. Erinnere Dich bitte an den Podcast mit Michael Hagemann. Mit ihm habe ich über das Thema gesprochen. Den Link zur Folge findest Du in den Shownotes unter www.different-thinking.de/034

Bei der Veränderung der Organisation geht es darum, eine Umgebung zu schaffen, in der Fehler erlaubt und erwünscht sind. Es geht darum, zu verstehen, dass die Kollegen aus den eigenen Fehlern lernen können und es daher wichtig ist, darüber zu sprechen. Es geht darum, dass die Verbesserung der eigenen Methoden und Prozesse wichtig für den Fortschritt ist.

Das bedarf Menschen, die die Veränderung möchten. Und es bedarf Führungskräfte, die die Menschen auf dem Weg begleiten, den Rahmen dafür gestalten sowie nachdrücklich und verlässlich dafür sorgen, dass das Ziel nicht aus dem Auge verloren wird. Selbstorganisation bedeutet, dass Du als Manager nicht mehr gebraucht wirst. Du wirst viel mehr als echte Führungskraft im Sinne von Leadership gebraucht.

Bin ich verrückt?

Das Thema spuckt mir schon seit Monaten durch den Kopf. Ich weiß gar nicht, was das Fass nun endgültig zum Überlaufen gebracht hat. Agilität ist eine Sau, die durchs Dorf getrieben wird. Genau wie ITIL. Lass Dich nicht irritieren, sondern schau, was Du wie für Dich und Dein Unternehmen einsetzen kannst. Ich bin überzeugt, dass wir beide Welten benötigen (Bi-Modal-IT). Und ich bin mir sicher, dass genügend Unternehmen Scrum einführen werden und sich wundern, warum es nach kurzer Zeit wie vorher ist – genau wie mit IT-Servicemanagement.

Bleibt mir abschließend noch eine Frage zu formulieren: Was meinst Du sind IT-Betrieb und IT-Service-Management kompliziert oder komplex?