-->

Montag, 4. Oktober 2010

Wovon zum Teufel redet ihr überhaupt?

Warum typische Probleme des klassischen Projektmanagements bei Agilem Vorgehen gar nicht vorkommen

Als ich meine ersten Projekte planen muste, bin ich – wie viele andere wahrscheinlich auch – erst mal los gezogen und habe mir ein Buch über Projektmanagement besorgt. So mit Gant-Charts und allem drum und dran. Bloß habe ich es nie hinbekommen, damit irgendein Projekt zu managen, weil die Realität immer so aussah, dass alle Projektpläne nach zwei Tagen Makulatur waren und das Updaten so viel Zeit in Anspruch genommen hat, dass ich am Ende mehr mit der Verwaltung der Pläne als dem Projekt zu tun hatte.

Natürlich hatte ich dann ein schlechtes Gefühl, weil ich dachte, dass ich Projektmanagement irgendwie nicht kapiere. Vielleicht würde ich etwas Wichtiges übersehen und es deshalb falsch machen. Oder noch schlimmer: Ich wäre vieleicht "führungsschwach" und müsste meinen Leuten mehr in den Allerwertesten treten?

Egal, da Projektmanagement und ich offensichtlich nicht füreinander bestimmt waren, habe ich die ganzen Tools irgendwann quasi gezwungenermaßen in die Ecke geworfen und mich so gut wie möglich durchgewurschelt. Interessanterweise funktionierte das erstens ganz gut und zweitens - aber das habe ich erst viel später gelernt - ähnelte meine Vorgehensweise dann dem, was man heute als Agile Methode bezeichnet.



Eigentlich könnte man es jetzt dabei bewenden lassen, aber eines Tages habe ich die Kritische Kette von Eliya Goldratt kennen gelernt und DAS war dann wieder richtig spannend, obwohl es dabei eigentlich um klassisches Projektmanagement geht. Denn Goldratt konnte  erklären, wo meine Probleme her kamen und dass es nicht an mir lag, sondern dass beim klassischen Projektmanagement einige wichtige Punkte tatsächlich konzeptionell falsch sind. Darüber hinaus zeigt er dann auch noch, wie man es besser machen kann.

Der Grund, warum ich diesen Beitrag hier schreibe, ist, dass auch für die Anwender Agiler Vorgehensweisen Goldratts Analysen sehr hilfreich sind. Insbesondere hilft Goldratts Analse, einige typische Planungsfallen zu vermeiden, in die man auch als Projektleiter oder Teammitglied in einem Agilen Team hineinfallen kann.

Goldratt nennt drei Gründe, warum es bei klassischem Projektmanagement (*) zu massiven Verzögerungen oder gar zum Scheitern von Projekten kommt:

1. Falscher Umgang mit Aufwandsschätzungen
2. Verspätungen addieren sich, Gewinne gehen verloren
3. Multitasking verschlimmert die Situation

1. Falscher Umgang mit Aufwandsschätzungen

Geht man eine Planung so an, dass man die Arbeitsschritte oder Aufgaben festlegt und dann die Ausführenden um eine Aufwandsschätzung bittet, so wird bei den Angefragten mehr oder weniger folgende Überlegung ablaufen:

"Hm, ich brauche dafür drei Tage. Aber irgendwas geht immer. Also besser kein Stress. Ich melde mal fünf Tage. Aber dem Kollegen haben die neulich böse das Zeitbudget gekürzt. Besser, ich melde sieben Tage, dann sollte ich auf der sicheren Seite sein."

--

Nun schalten wir kurz auf Fast Forward und schauen uns an, was an dem Tag passiert, an dem laut Plan die Aufgabe zur Bearbeitung an stünde. Wir erinnern uns: Der Schätzwert waren drei Tage, gemeldet wurden sieben.

Am Tag minus sieben vor Abgabe: "Man, die haben mir nicht mal eine Kürzung reingesetzt. Na, dann habe ich ja richtig üppig Zeit."

Am Tag minus fünf vor Abgabe: "Eigentlich sollte ich heute ich starten. Aber die Arbeit braucht sowieso nur drei Tage, also nehm ich mir lieber etwas anderes, Dringenderes vor. "

Am Tag minus drei vor Abgabe: "Mist, heute wollte ich es machen, aber gerade heute brennt es bei meinem Hauptkunden. Ok, ich schiebe es noch einen Tag, morgen und übermorgen muss ich eben richtig ranklotzen."

Am Tag minus eins vor Abgabe: "So was aber auch, die eine Teilaufgabe war echt tricky, das mit den zwei Tagen war doch zu knapp. Was soll's, muß ich halt zwei Tage Verzögerung melden. Wird schon nicht so schlimm sein, die anderen überziehen ja auch immer."



Ich denke, jeder Mensch mit etwas Berufserfahrung als Entwickler oder Projektleiter hat solch einen Ablauf schon häufiger erlebt :((

Goldratt rät übrigens nicht von Pufferzeiten ab (in unserem Beispiel die vier Tage, die über die drei Tage "Rohschätzung" hinaus angegeben werden), sondern zeigt in seinen Veröffentlichungen auf, wie man diese richtig einsetzt und managed. Was es damit auf sich hat, werde ich aber in einem anderen Beitrag unterbringen, heute geht es erst mal um die drei genannten Aspekte.

2. Verspätungen addieren sich, Gewinne gehen verloren

Jedes Projekt hat eine Vielzahl von Aufgaben, die jeweils von mehreren Unteraufgaben abhängig sind, die alle vollständig erfüllt sein müssen, bevor weiter gearbeitet werden kann. Ein Auto kann erst die Werkstatt verlassen, wenn der Motor repariert und die Räder angeschraubt sind; das Hauptgericht im Restaurant kann die Küche erst verlassen, wenn Fleisch und Gemüse und Beilage auf dem Teller liegen – die Beispiele lassen sich unendlich fortsetzen. Verzögert sich nur eine der Teilaufgaben, wirkt sich dies an solch einem "Integrationspunkt" auf den gesamten Projektverlauf aus. Andererseits ist es so, dass die frühere Fertigstellung von mehreren anderen Teilaufgaben gar nichts nutzt. Dieser "Vorsprung" wird einfach verpuffen. Die Grafik zeigt ein schönes Beispiel: Obwohl zwei der eingezeichneten Aufgaben früher fertig sind, verpufft der Vorsprung, da die Integration erst statt finden kann, wenn auch die unterste Aufgabe erledigt ist.



3. Multitasking verschlimmert die Situation

Liegen die Einzelplanungen vor, geht man in der klassischen Projektplanung gerne davon aus, dass man diese nun nach Belieben auf die Mitarbeiter verteilen kann. Das ein Mitarbeiter dann mehrere Aufgaben parallel bearbeiten soll, ist dabei eher die Regel als die Ausnahme. Dass die parallele Bearbeitung aber immer auch zusätzliche Umschaltzeiten erfordert, wird gerne übersehen. Schon ein einfaches Telefonat genügt, um einen Mitarbeiter für eine Viertelstunde aus dem Tritt zu bringen, die mentale und tatsächlichen Reorganisation des Arbeitsplatzes beim Umschalten auf eine andere Aufgabe wirkt sich natürlich noch viel deutlicher aus (Hier ein guter Artikel über eine ausführliche Studie dazu).



"Wovon zum Teufel redet ihr überhaupt?"
Wie Agiles Vorgehen diese Probleme vermeidet


Für die "klassische" Projektarbeit mit ihrem Top-Down-Ansatz einer zentralen Steuerung bietet das Konzept der Kritischen Kette ein gutes Instrument, Planung und Abarbeitung zu verbessern. Wirklich Interessant ist aber, dass in der Agilen Projektentwicklung diese Probleme gar nicht berücksichtigt werden müssen, da sie aufgrund einer besseren, weil zeitnäheren, genaueren und transparenteren Planungsmethodik erst gar nicht auftreten. Besonders gut lässt sich dies am Beispiel von Scrum zeigen.


Vor der Arbeit: Gemeinsame, transparente Aufwandschätzungen


Die Aufwandschätzungen in Scrum werden im Rahmen der Sprintlog-Planung kurz vor der Bearbeitung vorgenommen und gemeinsam diskutiert. Damit fließen in diese Aufwandsschätzung bereits eine Vielzahl von Erfahrungen und Informationen aus dem bisherigen Projektverlauf ein, was die Zuverlässigkeit deutlich erhöht, taktische Spielchen wie die Einberechnung unnötiger Puffer entfallen.

Während der Arbeit: Keine Verzögerungen / Momentum wird aufrecht gehalten


Das Herunterbrechen der Aufgaben in überschaubare Einzelaufgaben von nicht mehr als 16 Stunden, verhindert, dass große Überraschungen entstehen können.

Die täglichen Scrum-Meetings führen dazu, dass jederzeit klar ist, wer an was arbeitet und wie jedes Teammitglied voran kommt. Kritische Situationen wie in dem obenstehenden Beispiel (siehe Grafik) mit der um einen Tag verzögerten Integration werden sofort bekannt und können gemeinsam bearbeitet werden.

Die tägliche Dokumentation und Veröffentlichung des Burn-Down-Charts macht das Releaseziel kontinuierlich sichtbar, hält das Momentum im Team aufrecht.

Das Vermeiden von Multitasking


Dadurch, das die Aufgaben jeweils nur für einen Sprint und von allen Teammitgliedern gemeinsam geplant werden, ist die Planung beim Agilen Vorgehen automatisch wesentlich feingliedriger und realistischer, sowohl was die Einzelaufgaben angeht, als auch was die Abstimmung der Abhängigkeiten angeht. Ohne dass darauf gesondert geachtet werden muss, ergibt sich aus dieser besseren Planung sowie aus dem ausdrücklichen Verbot, dass Product Owner oder andere Nicht-Teammitglieder in die Arbeitsplanung eingreifen, praktisch automatisch eine optimierte, serielle Arbeitsplanung für die einzelnen Teammitglieder.

Mehr zur Kritischen Kette

Es gibt zur Kritischen Kette eine Reihe von Wiki-Einträgen und Webseiten. Ich persönlich finde die aber alle nicht so hilfreich. Ganz anders dagegen die Bücher. Da schafft es Goldratt m.E. sehr gut, das Thema Projektmanagement lebendig und gut nachvollziehbar darzustellen.

Für den Einstieg lohnt sich auf jeden Fall dieses Buch:

"Die Kritische Kette: Das neue Konzept im Projektmanagement"
von Eliyahu M. Goldratt, hier bei Amazon




(*) Mit klassischem Projektmanagement meine ich hier eine Top-Down-Vorgehensweise, bei der vorab ein Masterplan erstellt wird, in den idealerweise vor Projektbeginn alle Aktivitäten, die Aufwandschätzungen und die Bearbeitungsfolge eingetragen und dann nach Plan abgearbeitet werden.

Keine Kommentare: