Das erste Wertepaar des Agilen Manifests

Vergangene Woche entbrannte eine Diskussion auf einem unserer internen Kommunikationskanäle der it-agile. Dabei ging es darum, ob Kanban ohne WIP-Limits Kanban genannt werden darf und kann, oder nicht. In der Diskussion gab es Vergleiche mit Scrum, wann Scrum Scrum ist, und wann man eine bestimmte Implementierung agil nennen kann, und wann eben nicht.

Im Verlauf der Diskussion habe ich mich zu folgendem Kommentar hinreissen lassen:

Sowohl für Kanban als auch für Scrum gilt aber gleichzeitig: Wenn ich nichts verbessern will, brauche ich auch nichts ändern, sprich eine neue Methode einführen. Wie disruptiv ich das mache, kann ich dabei immer anhand der Kultur und bereits in Progress befindlichen Änderungen dosieren. Warum muss ich das dosieren? Das beschreibt das Satir Change Modell. Ich kann Kanban genauso hart einführen, wie ich Scrum weich machen kann, auf die Dosierung kommt es an.

Dieses Statement bedarf ein wenig mehr Eklärungen – Grund genug für einen Blogeintrag. Als Aufhänger nehme ich hierfür das erste Wertepaar des Agilen Manifests: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“.

Werkzeuge

Werkzeuge gibt es in der Agilen Welt zu Hauf‘. Wie schon der Text des Manifests ausdrückt, sollten wir aber darauf achten, dass wir nicht abhängig von unseren Werkzeugen werden. Die Dinge auf der rechten Seite besitzen einen Mehrwert in unserer täglichen Arbeit, aber die Dinge auf der linken Seite besitzen einen viel größeren Mehrwert.

Beispiele für Agile Werkzeuge sind Taskboards in Scrum, WIP-Limits in Kanban, oder auch einfach nur das Akzeptanztest-Rahmenwerk innerhalb der Entwicklung. Diese Werkzeuge stellen ein Hilfsmittel für unsere Arbeit dar. Am Taskboard trifft das Scrum-Team selbstorganisierende Entscheidungen. Alistair Cockburn nennt diese Art von Tools Information Radiator, Verbreiter von Informationen. Ein Taskboard hilft dabei, Informationen bezüglich des derzeitigen Arbeitsstandes zu vermitteln. Doch ein Taskboard allein ist nicht genug. Wie ich gerade in einem Team feststelle, ist das Taskboard häufig veraltet und stlelt nicht den derzeitigen Stand der Arbeit dar. Ist das ein Problem? Vielleicht.

Ähnlich verhält es sich mit WIP-Limits. Wenn ich derzeit an 200 Dingen gleichzeitig arbeite, dann sieht mein Kanbanboard vielleicht wie ein Tetris-Spiel kurz vor dem Game Over aus. Doch muss ich in diesem Zustand nach WIP-Limits suchen? Die Beraterantwort auf diese Frage: Es kommt drauf an. Wenn die Organisation gerade damit begonnen hat, Kanban einführen zu wollen, und das erste Mal vor einem derartigen Berg an Arbeit steht, dann ist das vielleicht erstmal ein Punkt, die 200 anderen Tickets im System zu behandeln, und erste Erfahrungen mit dem Board und den Neuerungen zu sammeln. Das Kanban-Board stellt in diesem Fall mit den Worten von Virginia Satir ein sogenanntes fremdes Element dar. Die Menschen benötigen unterschiedlich viel Zeit, um mit diesem fremden Element umgehen zu können. Einige werden sich verstecken, andere werden das fremde Element gezielt bekämpfen. In so einem Zustand ist es vielleicht ratsam, nicht noch ein fremdes Element in Form von WIP-Limits einzuführen, auch wenn die Methode das vielleicht vorsieht. Hier ist es ratsamer dem Team Zeit zu geben, um mit diesem Board zunächst mal umzugehen.

Auf der anderen Seite kann es aber auch sein, dass das Team bereits seit einiger Zeit mit dem Kanbanboard kämpft, und kein Land mehr sieht. Das Team ist völlig am Ende, und weiß nicht mehr weiter. Der extern eingeholte Berater wird hier vermutlich ein wenig Wackeln einführen wollen, um das festgefahrene Team wieder in Fahrt zu versetzen. Ein fremdes Element in Form von WIP-Limits können hier genau dieses Wackeln auslösen. Aber auch wenn das Team vielleicht gerade erst seine Arbeit auf ein Kanban-Board abgebildet hat, könnte es ratsam sein, bereits jetzt WIP-Limits anzustreben – ganz davon abhängig, wie viel Veränderung die Organisation derzeit vertragen kann. Und eine Veränderung stellt jede Einführung einer neuen Methode dar – ansonsten müßte ich schließlich nichts Neues einführen.

Prozesse

Ich persönlich hasse das Wort „Prozess“. Für mich verbirgt sich dahinter ein Haufen von Paragrafenreitern auf den 30er Jahren. Den einzigen Ausdruck, den ich vielleicht noch mehr hasse, ist „best practice“, aber diese Diskussion ist Teil eines anderen, vielleicht zukünftigen Blogeintrags.

Bei Prozessen unterscheide ich immer zwischen dem Prozess und der Prozessbeschreibung. Motiviert ist diese Art der Betrachtung von einem Diktum der Schwedischen Armee, das Don Gause und Jerry Weinberg in Exploring Requirements zitieren:

When the map and the territory don’t agree, always believe the territory.

Mit anderen Worten, wenn der gelebte Prozess nicht zur Prozessbeschreibung passt, dann ist man gut damit beraten, sich den gelebten Prozess anzusehen, und von dort aus Anpassungen vorzunehmen. Prozesse werden von Menschen erstellt. Das beinhaltet auch, dass Menschen diese Prozesse ändern können. Es macht keinen Sinn, wie Zombies täglich zum Standup zu erscheinen, und sich darüber zu beschweren, wie viel Arbeit man in diesen 15 Minuten machen könnte. Stattdessen sollte jeder darüber nachdenken, wie er dem Team dabei helfen kann, sich auszutauschen, und den gleichen Effekt zu erzielen, wie es ein tägliches Austauschmeeting von 15 Minuten erreicht.

Genauso können Menschen auch den Prozess verändern, der vielleicht in der Organisationsbeschreibung für das kommende ISO-Audit verankert ist. In der Tat ist die Prozessbeschreibung diejenige, die am meisten hinter dem gelebten Prozess hinterherhängt. Ist das ein Problem? Wenn Sie die Illusion eines beschriebenen Prozesses für ein wohlig-warmes Gefühl bei der Arbeit brauchen, dann vielleicht schon. Bisher habe ich allerdings noch kein Team erlebt, das nicht in der Lage war, eigene Absprachen zu treffen, oder durch Pragmatismus vom beschriebenen Prozess abzuweichen – oft zum Besseren.

Individuen und Interaktionen

In unserem Beruf entwickeln wir Software von Menschen für Menschen. Dabei ist es wichtig, für gute Kommunikation zu sorgen, und die Beteiligten zu wertschätzen. All die Energie, die einzelne in traditionellen Projekten damit verschwenden, sich gegenüber späteren Folgen abzusichern, Geheimnisse zu verbergen, oder gar das Projekt zu manipulieren, würden wir gerne in die Entwicklung von funktionsfähiger Software stecken. Dabei ist es wichtig, dass wir die Freiheit für unsere Arbeitsweise behalten. Ein vorgeschriebener Prozess kann zwar für Wiederholbarkeit sorgen, allerdings habe ich noch nie das gleiche Projekt zweimal entwickeln müssen. Das wäre auch verdammt langweilig.

Stattdessen sind die Menschen in unseren Projekten das wichtigste. Wenn wir ihnen vertrauen, dann werden sie in der Lage sein, auch ohne unsere ständigen Interventionen gute Ergebnisse zu erzielen. Werkzeuge und Prozesse helfen ihnen vielleicht am Anfang dabei, Klarheit zu bekommen. Aber wenn ein Prozess die Arbeitsweise beeinträchtigt, dann findet einen besseren Weg. Agil ist letzen Ende kein Endzustand oder Ziel. Eine Hauptaufgabe einer Agilen Einführung ist ein kontinuierlicher Verbesserungsprozess – also ein ständiges System aus Feedback und kleinen Verbesserungsschritten. Es gibt mehrere Möglichkeiten, dieses zu erreichen – auch über Agile Prozesse hinaus. Doch sollten uns die Prozesse dabei nicht im Weg stehen. Und wenn wir das Ziel nicht erreichen, dann sollte uns kein Prozess vorschreiben, was wir tun und nicht tun können. Kreativität und Adaption sind letzten Endes der SChlüssel zur steten Verbesserung.

Scrum und Kanban sind derzeit weit verbreitet. Beide haben Vorteile, beide haben Nachteile, beide sind Veränderungen in einer Organisation. Bei der Einführung sollte aber eben wegen der Individuen und Interaktionen Sorge dafür getragen werden, dass diese Veränderungen auch mit getragen werden. Denn nichts behindert eine Einführung stärker als ein boykottierendes Teammitglied.