Einleitung

Spätestens seit Deming ([01]) ist es offiziell: es gibt immer etwas zu verbessern. Das gilt auch und vielleicht besonders für die Projekt-Arbeit bei der Softwareentwicklung.

Aber wie oft nehmen denn Sie sich denn die Zeit, um (kurz) über Ihr Verbesserungspotential im Projekt nachzudenken?

Prof. Lothar J. Seiwert ([01], Seite 37)

Agile Vorgehensweisen wollen solche Situationen gerade vermeiden. Wie eXtreme Programming (XP) versucht, die Säge scharf zu halten, das möchte ich Ihnen hier kurz zeigen.

Seitenanfang

Verbesserung

Verbesserungen bei der (Projekt-) Arbeit können durch verschiedene Aspekte ausgelöst werden:

• man lernt, wie bestimmte Aufgaben/Abläufe besser bzw. leichter erledigt werden könnten;
• man erkennt, warum gewisse Fehler aufgetreten sind;
• die Umwelt stellt einen plötzlich vor neue Situationen, die mit den bisherigen "Kochrezepten" nicht oder nur schwer zu bewältigen sind;

Und immer gilt das gleiche Muster: man erkennt ein Verbesserungs-Potential, beschließt eine Änderung im Vorgehen, wendet dieses geänderte Vorgehen an und prüft am Ende, ob diese Änderung Erfolg gebracht hat bzw. wo das nächste Potential schlummert. WICHTIG: je kürzer ein solcher Zyklus ist, desto schneller kann man sich erfolgreich anpassen (nach einer Theorie sind ja die Dinosaurier eben wegen ihrer langen "Zyklus-Zeit" ausgestorben).

Nun kennt jeder Projekt-Leiter mindestens theoretisch sogenannte Projekt-Reviews. Gerade bei großen und besonders bei sehr großen Projekten wird nach Projekt-Ende(!) ein Blick zurück geworfen: was ist denn schlecht gelaufen? was ist uns aufgefallen?

Soweit sehe ich noch keinen Unterschied zwischen Klassischen (Wasserfall-) Projekten und Agilen Projekten. NUR: bei den klassischen (Wasserfall-) Projekten erfolgt ein solches Review tatsächlich posthum, d.h. nachdem das Projekt abgeschlossen ist. Auch ein phasenweiser Rückblick verbessert bei klassischen Projekten nichts: die Phase ist zu Ende und wird in diesem Projekt nicht mehr durchlaufen; d.h. jeder Vorschlag zur Verbesserung wird am konkreten Projekt nichts mehr ändern; somit müssen solche Vorschläge erst einmal in der Schublade landen. Und ob ein Nachfolger-Projekt jemals in diese Schublade hineinsieht, das ist mehr als fraglich.

Verbesserungen sollten nicht für einen anonymen Kandidaten irgendwann in der Zukunft geplant werden. Vielmehr wäre es doch auch viel motivierender, falls die Verbesserungs-Vorschläge auch noch dem eigenen Projekt helfen könnten.

Und genau das sehen wir eben bei allen Agilen Vorgehensweisen, da sie grundsätzlich ein Iteratives Vorgehen zeigen.

Seitenanfang

Kleine Schritte

Das Erfolgsrezept heißt: möglichst kurze Zyklen im Projekt, die dem Team erlauben, auf kurze Projekt-Abschnitte zurückzublicken, sich zu erinnern und sofort für den nächsten Zyklus eine konkrete Verbesserung vorzuschlagen und umzusetzen.

Es geht auch nicht darum "alle möglichen" Defizite aufzuarbeiten. Es genügt, das momentan wichtigste (in den Augen des Teams) zu bearbeiten. Denn eines ist klar: in Kürze kommt die nächste Gelegenheit, um wieder eine Verbesserung einzuleiten.

Bei allen Agilen Vorgehensweisen und so auch bei eXtreme Programming (XP) lassen sich folgende natürliche Punkte im Projekt-Ablauf für einen Rückblick finden:

• Tägliches Standup-Meeting;
• Ende einer Iteration;
• Ende eines Release;
• (ein Rückblick am Ende des Projekts ist damit eigentlich gar nicht mehr notwendig)

Wie diese Punkte in einem XP-Projekt genutzt werden, soll im folgenden kurz beschrieben werden.

Seitenanfang

Schärfen 1: Standup-Meeting

Die Original-Regel bei XP von Kent Beck heißt: "Tägliches Standup-Meeting" ([03]).

Der Tag ist eigentlich so ziemlich der kleinste "Zyklus" in einem Projekt. Gerade bei XP mit seinem extrem kleinen Schritten (Test-Code-Refactor) macht es durchaus Sinn, auf diesen kleinen Zyklus zurück zu blicken.

Jeder Tag beginnt mit einer kurzen Besprechung im Stehen. Jeder Teilnehmer hat ca. 2 Minuten Redezeit. 10-15 Minuten sollte die maximale Dauer insgesamt für ein Standup-Meeting sein.

Jeder Teilnehmer spricht (kurz) über folgende Punkte:

Ein wichtiges Ziel des Standup-Meeting ist die gegenseitige Information: die Team-Mitglieder sollen über den Fortschritt bei den Kollegen und im Projekt aktuell informiert sein, ohne viel Zeit in Meetings sitzen zu müssen.

Angenehmer Nebeneffekt: ein solcher Start in den Projekt-Tag ist eine sanfte Orientierung und fokussiert automatisch jedes Team-Mitglied auf das aktuelle Projekt-Geschehen.

Seitenanfang

Schärfen 2: Iterations-Ende

Am Ende einer Iteration hat man praktisch ein Mini-Projekt abgeschlossen: von der Priorisierung und Konkretisierung der Anforderungen bis hin zur Abnahme und Lieferung des lauffähigen Systems.

Das ist ein guter Zeitpunkt, um sich über die vergangenen 1-2 Wochen folgende Gedanken zu machen:

Ein Flipchart eignet sich gut für die "Dokumentation":

• die Fragen werden in 4 Quadranten geschrieben;
• die genannten Punkte schreibt man sofort in den jeweiligen Quadranten;
• nach Abschluß diese Rückblickes wird das Blatt gut sichtbar im Projekt-Raum an die Wand gehängt;

Am Ende entscheiden die Teilnehmer, welche genannten Punkte besonders wichtig sind und was man sich als Team nun konkret für die nächste Iteration an Verbesserung/Veränderung vornimmt (auch das wird auf dem Flipchart vermerkt bzw. markiert).

Seitenanfang

Schärfen 3: Release-Ende

In der minimalen Form können am Release-Ende ebenso die Fragen wie beim Iterations-Ende als Anleitung für den Rückblick verwendet werden. Nach meiner Erfahrung wird dabei aber nicht grundsätzlich neues aufgedeckt werden.

Angebracht und vom Aufwand vertretbar (1x ca. 2 Stunden pro Release) wäre auch eine gemeinsame Moderation zum Thema "Verbesserungs-Potential im Projekt":

• Orientierung (15 Minuten)
  eine nette Einleitung "zum Aufwärmen" wäre das sog. XP-Radar vom William Wake ([04]): in einem Netz-Chart wird dargestellt, wie weit das Team die XP-Regeln nach eigener Einschätzung einhält; jedes Team-Mitglied sollte dazu jeweils Wake's Fragen beantworten, die Punkte werden im Team addiert und gemeinsam auf einem Flipchart eingetragen;
• Punkte-Sammlung (15 Minuten)
  jedes Team-Mitglied schreibt Stichpunkte auf Karten zu folgenden Fragen:
  - Was ist wirklich gut gelaufen im Projekt?
  - Was hat mich im Projekt behindert?
  - Was ist sonst im Projekt bemerkenswert?
• Gruppierung (50 Minuten)
  alle beschriebenen Karten werden eingesammelt (und gemischt);
  gemeinsam werden an einer Pinwand alle zusammengehörigen Karten in Spalten gruppiert;
  die Karten werden nacheinander bearbeitet, aber nicht weiter diskutiert(!);
  am Ende hat man meist 8 bis 15 Spalten: kurze können eventuell zusammengefaßt werden; lange kann man u.U. teilen;
  jede Spalte erhält einen Begriff als Namen/Thema;
• Priorisierung (10 Minuten)
  jeder Teilnehmer erhält Klebe-Punkte (es geht aber auch einfach ein dicker Stift);
  die Anzahl der Punkte für jeden = (Anzahl der Themen-Gruppen) / 2;
  jeder/jede klebt seine/ihre Punkte auf das Thema, das persönlich am wichtigsten ist;
  alle kleben gemeinsam;
• konkrete Aktionen (20 Minuten)
  gemeinsam werden zu den Top-3 der priorisierten Liste Aktionen bestimmt:
  wer sollte bis wann welches Ergebnis zu diesem Thema an wen abliefern?

Mit Rückblicken in dieser Form kommen oft Punkte zur Sprache, bei denen der notwendige Handlungsbedarf außerhalb des Projekt-Teams liegt. Hier ist dann der Team-Coach gefragt, um diese Punkte geeignet weiterzuleiten und entsprechende Ergebnisse einzufordern.

Auch hier sollte die Zusammenfassung (=Themen-Gruppen inklusive Priorisierung und Aktionsplan) auf einem Flipchart gut sichtbar im Projekt-Raum plaziert werden.

Natürlich erwartet das Team dann auch den Vermerk auf diesem Flipchart, sobald Punkte aus dem Aktionsplan erledigt sind.

Seitenanfang

Dokumentation

Das Thema "Dokumentation" ist hier wie auch sonst zwiespältig: zum einen helfen natürlich Notizen beim späteren Zusammenfassen wie auch bei der Vorbereitung von zukünftigen Projekten; zum anderen kann der Aufwand dafür erheblich werden und steht dann in keinem guten Verhältnis mehr zum Nutzen.

Mein Vorschlag dazu:

• aus den Review-Sitzungen erhält man ohne Zusatzaufwand die Flipcharts; das jeweils letzte sollte offen im Projekt-Raum gut sichtbar plaziert sein;
• wird auch noch eine kleine/schlanke Projekt-Homepage gepflegt, dann sollte auch ein Top-Level-Menüpunkt "Review-Notizen" kein großer Aufwand sein: zu allen Iterationen und Releases werden chronologisch jeweils genau die Stichpunkte von den Flipcharts zu den Schlüsselfragen festgehalten; mehr nicht;

Falls für diese Formen der Aufzeichnung nicht sofort wieder formale Regeln und Vorschriften erlassen werden, hält sich der Aufwand mehr als in Grenzen und beschränkt sich auf das Übertragen der Stichpunkte vom Flipchart in eine HTML-Tabelle.

Seitenanfang

Zusammenfassung

In klassischen (Wasserfall-) Projekten sind Projekt-Reviews oft nicht mehr als "Papier-Tiger": das eigene Projekt ist längst abgeschlossen, nichts wird mehr etwas am Projekt-Verfall und -Ausgang ändern; zukünftige Projekte (vor allem bei anderer personeller Zusammensetzung) werden das Gefundene nur selten zu Gesicht bekommen oder gar berücksichtigen. Und manchmal haben sich die "wirklich" Beteiligten schon in alle Winde zerstreut, sodaß die ihren wichtigen Beitrag nicht mehr leisten können.

Agile Vorgehensweisen mit ihrem Iterativen Grundmuster bieten die idealen Voraussetzungen, um Rückblicke wirksam und nachhaltig im eigenen(!) Projekt einzusetzen: damit läßt sich bei geringstem Aufwand eine Verhaltensweise im Projekt einführen, die für ein ökonomisches Arbeiten und optimale Leistung sorgt.

Einzige Bedingung: das Team muß konsequent diese Reviews durchführen. Und das sollte machbar sein, oder?

Seitenanfang

Verweise

Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und für weiterführende Informationen:

[01]	Mary Walton: The Deming Management Method; (Management Books 2000 Ltd)
[02]	Lothar J. Seiwert: 30 Minuten für optimales Zeit-Management; (Gabal-Verlag)
[03]	Kent Beck: eXtreme Programming, Das Manifest; (Addison-Wesley)
[04]	William Wake: http://www.xp123.com/xplor/xp0012b/index.shtml;

Seitenanfang