Warum fällt es so schwer die Menge nicht getaner Arbeit zu maximieren?

Bei der Umstellung von klassischer zu agiler Projektführung fällt eines immer wieder auf: Die Projektmitglieder, die sehr lange in den klassischen Denke unterwegs waren, tun sich extrem schwer die Menge nicht getaner Arbeit zu vergrößern.

Menge nicht getaner Arbeit? Was soll das denn bitte schön jetzt sein? Wer einen Blick in das Agile Manifest wirft, wird diese Formulierung in den 12 Prinzipien wiederfinden:

„Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.“

Die Denke dahinter stammt aus der Zeit, als das Toyota Production System entwickelt wurde. Das Grundprinzip bei Toyota ist seitdem: „Verschwendung vermeiden“. Hierzu zählt neben den Produktionsmitteln auch die Zeit. Und genau hier setzt die Formulierung aus dem Agilen Manifest an.

Wo läßt sich nun Zeit einsparen? Mindestens mal bei den Aufwänden, die man im klassischen Alltag in Dokumentation stecken würde. Nicht über Dokumente miteinander zu kommunizieren, wäre solch ein Aspekt.

Über Dokumente miteinander zu kommunizieren ist langwieriger und fehleranfälliger, da Geschriebenes misinterpretiert werden kann und im Enzelfall die Klärung nicht zeitnah erfolgt. Abgesehen davon zeigt die Erfahrung, dass in einem Gespräch von Angesicht-zu-Angesicht Dinge in der Diskussion zu Tage treten, die in Dokumenten meist nur implizit zu finden sind, weil der Autor über diese in seiner täglichen Routine nicht mehr bewußt nachdenkt. Nicht selten handelt es sich aber um wesentliche Aspekte für das Verständnis von Geschäftsabläufen des Kunden.

Alles, was mit Reporting zu tun hat, das entsteht, weil Stakeholder sich nicht in der Lage sehen, bei den agilen Events des Projekts ihren Informationsstand aufzufrischen, ist ebenfalls Verschwendung. Ich bin manches Mal erschreckt, wieviel Aufwand bei klassischer Projektführung in derartig tote Dokumente investiert wird, wenn ich einen Blick auf die Dokumentenhaltung des Projekts werfe. Selbst wenn ich das unter Stakeholder-Management verbuchen würde, steht mindestens der Aufwand für das Aufhübschen in keinem guten Verhältnis zum übertragenen Inhalt.

Zweiter Aspekte wäre Vertrauen. Wenn ich damit rechnen muß, dass zu einem späteren Zeitpunkt im Projekt eine Beweisführung notwendig wird, halte ich alles fest, was diesem Tatbestand Rechnung trägt. In einer vertrauensvollen Umgebung ist so etwas reine Verschwendung. Man würde lediglich Beschlüsse festhalten, damit der sich im Projektverlauf ändernde Rahmen für das eigenverantwortliche Handeln nachvollziehbar bleibt.

Dritter Aspekt wären Annahmen über zukünftige Anforderungen des Kunden, die schon jetzt zum Tragen kommen sollen, z.B. in der Systemarchitektur, damit dann bei der tatsächlichen Umsetzung die Aufwände nicht so hoch werden. Das Problem ist hierbei, dass die Annahmen nie wirklich treffen können. Die kurzen Innovationszyklen des Marktes lassen es kaum mehr zu weiter als ein Quartal in die Zukunft zu schauen. Wenn ich mit dem Wissen von Heute Annahmen über die Situation in einem Jahr oder noch weiter in die Zukunft treffe, hat das was von Hellseherrei und Glaskugellesen. Jede Minute, die in die Ausarbeitung und Dokumentation derartiger Anforderungsvorwegnahme investiert wird, ist Verschwendung.

Vierter Aspekt wäre der direkte Kontakt mit dem Kunden. Ich bezeichne es gerne als „Durchlauferhitzer“, wenn der klassische Projektleiter für jede Kleinigkeit als Hauptansprechpartner für den Kunden herhalten muß, die ein Teammitglied auch sofort, direkt und in eigener Person hätte klären können. Mal abgesehen von dem zu erwartenden Informationsverlust dauert solch eine Klärung schon deshalb länger, weil die Verfügbarkeit für ein Gespräch zwischen drei statt zwei Personen geklärt werden muß.

Noch interessanter stellt sich die Situation dar, wenn ein Projektmitglied es nicht als seinen Aufgabenbereich ansieht, etwa Termine zu machen mit dem Kunden, obwohl es dazu selbst in der Lage wäre, da diese Zeit für den eigenen Arbeitsbereich ja sonst fehlen würde. Ich bezeichne so etwas gerne als „lokale Optimierung“. Das Projektmitglied arbeitet dardurch optimal nach eigenem Empfinden, verkennt aber, dass das die Effektivität des Projekts untergräbt.

Ich möchte es mal bei diesen Beispielen belassen. Entscheidend für unsere Ausgangsfrage ist im Wesentlichen der disruptive Charakter des Wechsels von klassischer zu agiler Führung. Plötzlich müssen Mitarbeiter Verantwortung übernehmen und Entscheidungen treffen, die ihnen vorher nicht erlaubt waren. Da entsteht natürlich erst mal ein Vakuum, Verunsicherung, vielleicht sogar Misstrauen.

„Darf ich das überhaupt tun?“ ist sicher eine zentrale Frage. Und selbst wenn darauf mit einem lauten „Jaaaaaa!“ geantwortet wird, schaut man manches Mal in zweifelnde Gesichter. Was vorher ein ungeschriebenes Gesetz war nicht zu tun, wird jetzt plötzlich zu einer Verhaltensregel. Da fehlt Erfahrung, Mut, und manches Mal auch die Fantasie, sich zu überlegen, wie man mit der Situation sinnvoll umgehen kann.

Vorher war das Denken verboten, jetzt wird es zu einem Muß. Kein Wunder, dass manch einer in alte Verhaltensmuster zurückfällt. Die passen zwar nicht mehr richtig, aber im Rahmen des jetzt zur Verfügung stehenden Gestaltungsraum und der Eigenverantwortung, fühlt es sich gut an, erst mal so weiter zu machen wie bisher. Es handelt sich ja schließlich um eine selbst getroffene Entscheidung, und man wendet als eine mögliche Ausprägung das bereits gelerne Muster an. Dadurch ist man sofort produktiv und fühlt sich sicher in seinem Handeln. In diesem Sinne greift auch hier wieder die „lokale Optimierung“. Und das Projekt steht vor entsprechenden Effektivitätsproblemen.

Besonders interessant ist hierbei sicher auch noch der Versuch des Projektmitglieds möglichst keine Fehler zu machen. Dafür wird viel Zeit in die eigene Qualitätssicherung investiert. Oder noch schlimmer: es werden auch noch andere dazu verleitet auf ein bereits ausreichendes Ergebnis einen zusätzlichen Blick zu werfen. Gegen ein Vier-Augen-Prinzip spricht hierbei grundsätzlich nichts, wenn dadurch z.B. Bugs frühzeitig entdeckt werden. Aber in diesem Zusammenhang wird schon mal mehr gemacht als es für den Kundennutzen notwendig wäre.

Was wäre nun eine sinnvolle Einstellung für jeden Einzelnen im Projekt, damit der agile Rahmen entsprechende Wirkung entfalten kann und wir eine Maximierung nicht getaner Arbeit erreichen?

Wir investieren unsere Zeit nur in Dinge, die notwendig sind für die Erreichung des angestrebten Kundennutzens. Somit setzen wir bei einer User Storie z.B. nur soviel um, dass die Akzeptanzkriterien gerade erfüllt sind. Wer sich mit Test Driven Development schon mal auseinander gesetzt hat erkennt dieses Prinzip auf allen Ebenen der Umsetzung wieder. Sobald die Kriterien eines Unit-Tests erfüllt sind, wird aufgehört mit der Implementierung von Funktionalität.

Für mich gilt grundsätzlich erst mal die 80-20-Regel: 80% reichen. Man kann es auch so formulieren: wir investieren gerade soviel, dass der Kunde nicht mehr auf die Idee kommt sich zu beschweren. Diese Forderung ist insofern interessant, weil nicht selten ein Mismatch zwischen dem Anspruch des Kunden und dem Anspruch der Umsetzung zu beobachten ist. Die Ansprüche des Kunden sind meist schneller zu befriedigen als die Ansprüche der Umsetzer. Dies ist ein wichtiger Zusammenhang, da selten das Budget bereitsteht um über die Ansprüche des Kunden hinauszugehen. Tut man es doch, kann dass das Projektergebnis gefährden.

Damit kommen wir zu einer wesentlichen Forderung im agilen Projekt: kontinuierlich die eigenen Entscheidungen im Kontext des Geschäftswerts des Kunden zu bewerten. Im Prinzip muß ich soweit gehen, dass ich mir Gedanken darüber mache, ob ich z.B. eine bestimmte Methode, einen bestimmten automatisierten Test, letztendlich eine bestimmte Zeile Code tatsächlich brauche und Zeit in deren Erstellung stecken sollte. Gleiches gilt für die konzeptionelle Vorarbeit. Muß ich gedankliche Entwürfe noch schriftlich festhalten, oder werden diese direkt in Code umgesetzt. Damit könnten wir einige tote Projektdokumente verhindern ;-).