Was ist agil, was ist lean?

Als Coach helfe ich Ihnen, in Ihrer Umgebung (Firma) ein System aus Leuten, Ideen, Produkten, Geld, Zeit und Wissen zu kreieren, in dem engagierte Teams Wert schaffen können. Ist das nun agil? Ist das „lean“?

Die Frage in Hamburg

Vorige Woche traf sich die Limited WIP Society Deutschland in Hamburg zu einem Open Space mit diversen, interessanten Sessions zu Themen aus dem Umfeld von Kanban, einer der Lean-Methodiken. Ich war auch dort. Sergey Shishkin stellte in einer Session unter der Überschrift „Science and Fiction“ eine für mich sehr interessante Frage:

Wie kann es sein, dass wir unserem Prozess mit Hilfe von Kanban Gleichmäßigkeit geben wollen, und gleichzeitig wollen wir  agil sein, das bedeutet doch, jederzeit Veränderung willkommen zu heißen, oder? Wie viel Science ist denn das, und wieviel ist Fiction?

Am Ende der Session antwortete ich:

Wir heißen Veränderung im Produkt willkommen. Der Kunde darf sich jederzeit etwas anderes wünschen, wir machen das möglich. Wir benutzen dafür jedoch meistens den gleichen Prozess und optimieren ihn, dadurch werden wir in gewissem Maße „berechenbar“. Agilität im Produkt und Gleichmäßigkeit im Prozess widersprechen sich nicht.

Agil und Lean, eine Beziehung

Das Thema geht mir noch weiter im Kopf herum, weil ich das Gefühl habe, die Antwort müsste noch vielschichtiger sein.

Die vier Werte aus dem Agilen Manifest heißen ja: wir schätzen…

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Wenn ich das mit dem Alltag in einem Kanban-System vergleiche, mache ich die folgenden Beobachtungen:

Individuen und Interaktionen: Für mich ist das am spannendsten an Kanban – wir stehen gemeinsam vor der Tafel, sehen zu, was die Arbeit gerade macht und reden darüber, wie es weitergeht. Ab und zu staut sich die Arbeit, wir laufen gegen das WIP-Limit und (weil wir es respektieren) arbeiten wir nicht weiter, sondern lösen gemeinsam das Problem, das zu dem Stau geführt hat. Individuen, die interagieren, um ein Problem zu lösen. Das ist es. Das bleibt ein konstanter Wert im Team.

Funktionierende Software: Ein Team, das ich einmal coachte, hatte sich entschieden, über jeder Spalte (verstehen, entwickeln, abnehmen, akzeptanztesten, usw.) der Kanban-Tafel einen Zettel anzubringen, auf dem die „definition of done“ für diese Spalte steht. Wann gilt etwas als „verstanden“, „entwickelt“, „abgenommen“, usw.? Wann ist „fertig“ wirklich fertig? Verständliche Stories, klare Abnahmekriterien à la BDD, das ist am Ende der „verstehen“-Spalte wichtig. Funktionierende Software, vorzeigbar, getestet, eingecheckt im Konfigurationsmanagementsystem, usw. – das ist am Ende der „entwickeln“-Spalte wichtig. Das Team spricht oft darüber. Die Leute versuchen, die DoDs  ernst zu nehmen und Karten nur durchzulassen, wenn sie wirklich der DoD in der Spalte entsprechen. Seltsam, die DoD bleibt jetzt (nach kurzer Einschwingzeit) ziemlich konstant, obwohl die Arbeit sich jeden Tag verändert und jeden Tag neu ist.

Reagieren auf Veränderung: Mit dem Management dieses Kanban-Teams habe ich gesprochen, als die Kanban-Einführung anstand. Sie ließen sich überzeugen, dass ein stetiger Fluss von fertiger Software wichtiger ist als hohe Auslastung der Leute und das Erreichen eines Releaseplans mit festem Termin und festem Umfang. Die Kunden bekommen dadurch mehr Flexibilität, denn wenn das Team wenig WIP im Gepäck hat, kann es seine Richtung auch schnell verändern. Lean funktioniert hier als Enabler für Agilität. Und dafür darf auch schon mal jemand unbeschäftigt herumsitzen, das ist auch gut so.

Zusammenarbeit mit dem Kunden: Kanban-Teams erreichen im Laufe der Zeit eine einzigartige Fähigkeit: Bewusstsein über das, was sie können, Bewusstsein über die eigenen Fähigkeiten: Wie viele Karten pro Woche schaffen wir? Wann können wir die Software für eine neue Karte liefern, die wir heute angefangen haben? Welche Qualität können wir sicherstellen, wenn man uns das tun lässt? Mit diesem Wissen kann das Team ganz anders mit dem Kunden zusammenarbeiten. „Vertragsgegenstand“ ist nun nicht mehr ein bestimmter Inhalt oder Umfang, sondern das Verhalten eines reifen, engagierten Teams! Es geht um Service, nicht um Scope. Kunde, wir zeigen Dir, was wir können und wie wir arbeiten, und Du entscheidest, wie Du dieses Können innerhalb des Alltags möglichst gewinnbringend für Dich nutzt. Zusammenarbeit: Der Kunde will, das Team kann. Beide kommen überein, Willen und Können zusammenzubringen, um Wert zu schaffen.

Gegenseitigkeit

Lean-Methoden wie Kanban räumen engagierten Teams die Bahn frei in Richtung Agilität. Kenntnis der eigenen Fähigkeiten (Berechenbarkeit im guten Sinne) gibt Teams die Ruhe, die sie brauchen, um jeden Tag neue Veränderung willkommen zu heißen.

Hört sich philosophisch an, merke ich gerade. Doch: Warum eigentlich nicht?