E-Learning: Klassisch und Agil kombinieren

Die Elemente eines klassischen Projektumfelds haben zumeist ihre Berechtigung und auch ihre Funktion im Unternehmen. Allerdings stehen sie in einem Spannungsverhältnis und manchmal sogar im Widerspruch zu dem Einsatz agiler Techniken. Solche Widersprüche gilt es bei der Kombination von klassischem und Agilem Projektmanagement aufzuspüren und sinnvoll aufzulösen.

Anhand eines Beispiels aus der Praxis betrachten wir hier kurz, wie eine funktionierende Verbindung zwischen einer klassischen und agilen Vorgehensweise aussehen kann. Das folgende Briefsortierungs-Beispiel macht auch das Spektrum deutlich, in dem von Agilität gesprochen werden kann. Es ist einem realen Projekt bei einem Großkonzern entnommen. Der besseren Verständlichkeit zuliebe ist es etwas vereinfacht, aber im Wesentlichen korrekt wiedergegeben.

Bei dem Projekt ging es um die Erstellung von Hard- und Software für die Briefsortierung. Dazu sollten sowohl eine Sortiermaschine entwickelt werden als auch gleichzeitig die Software, die diese Maschine steuert und die postalischen Prozesse realisiert.

Das Projekt begann damit, dass die Postorganisation eines Landes eine Ausschreibung für neue Sortieranlagen machte. Im Verlauf des Angebotsprozesses wurde eine detaillierte Spezifikation des gewünschten Produktes erstellt, auf der die Kostenschätzungen für das Projekt basierten. Auch ein Termin für die Lieferung des Endproduktes war frühzeitig festgelegt. Damit standen praktisch die drei Elemente des PM-Dreiecks fest.

Im weiteren Verlauf des Angebotsprozesses initiierte die Postorganisation dann allerdings ein Bieterverfahren, bei dem mehrere Anbieter wiederholt den Preis der anderen Anbieter unterbieten konnten, um den Zuschlag zu erhalten. Als das Projekt startete, war das ursprünglich geplante Projekt-Budget auf ein »politisches« Budget geschrumpft. Das in der Theorie funktionierende PM-Dreieck war damit also bereits hinfällig (Letztlich wurde das Projektbudget mit Quersubventionen aufgestockt). Bei dem Budget handelte es sich um einen mehrstelligen Millionenbetrag.

Das Projekt war auf Ebene des Projektmanagements zunächst klassisch geplant. Zur Minimierung des Risikos wurde die Entwicklung allerdings an den agilen Entwicklungsprozess „Unified Prozess“ angelehnt. Dazu wurden insbesondere die Anforderungen als Anwendungsfälle (vergleichbar mit User Stories, aber deutlich ausführlicher beschrieben) formuliert und Iterationen geplant, in denen diese Anwendungsfälle sukzessiv umgesetzt wurden. Beispiele für solche Anwendungsfälle waren:

• Briefsendungen nach Postleitzahlen sortieren
• Briefsendungen auf Straße und Hausnummer genau sortieren
• Briefmarken erkennen
• 2-D-Barcode-Briefmarken erkennen
• Bei Umzugsweiterleitung neue Adresse auf Brief drucken
• Statistikdaten für Adressen an Postorganisation senden

Wie komplex diese Prozesse sind, zeigt eine kurze Skizzierung des Anwendungsfalls »2-D-Barcode-Briefmarken erkennen«: Es gibt Kennzeichen, die man sich zu Hause ausdrucken kann, um einen Brief zu frankieren. Natürlich darf diese Frankierung nur für einen Brief gültig sein. Wenn also eine Maschine ein solches Kennzeichen liest, muss sie landesweit alle anderen Maschinen darüber informieren, dass dieses Kennzeichen nun seine Gültigkeit verloren hat. Bereits Sekunden später muss dann ein Brief mit der gleichen Kennzeichnung in einem anderen Briefzentrum als Fehlfrankierung erkannt und aussortiert werden.

Auf Basis der formulierten Anwendungsfälle wurden mit der Postorganisation Meilensteintermine vereinbart, um jeweils ein bestimmtes Bündel von Anwendungsfällen vorzuführen und schriftlich abzunehmen. Für den Kunden, also die Postorganisation, blieb die Projektstruktur im Wesentlichen klassisch mit einer Reihe von Zwischenabnahmen. Das Besondere daran war die Lauffähigkeit der Zwischenprodukte, mit denen die Postorganisation bereits eigene Prozesse testen konnte.

In der Entwicklung wurden die Meilensteine als Iterationsenden geplant. Es gab dabei mehr Iterationen als Meilensteine. Zwischen manchen Meilensteinen lagen also mehrere Iterationen. Zudem wurden die ersten Iterationen zur Erstellung einer Infrastruktur sowohl bei der Software als auch bei der Maschine verwendet. In diesen Iterationen wurden also keine Anwendungsfälle für den Kunden realisiert. Die Ergebnisse waren die Basis für die darauffolgenden Iterationen.

Insgesamt verlief das Projekt sehr erfolgreich. Der Kunde bekam zwar im definierten Zeitraum nicht alles, was er spezifiziert hatte, aber die Funktionen, die ihm wichtig waren, wurden geliefert und obendrein noch einige Funktionen, die er bei der Spezifikation übersehen hatte. Auch musste der Projektleiter des Kunden bei mancher Zwischenabnahme ein Auge zudrücken, wozu er aber bereit war, da der Auftragnehmer sich im Gegenzug mehrfach mit gutmütiger Auslegung von Spezifikationslücken erkenntlich zeigte, es also wenig kostenpflichtige Change Requests gab.

Dass das beschriebene Vorgehen in diesem Projekt möglich war, basierte unter anderem auf zwei wesentlichen Faktoren:

• Zum einen kannte sich der Auftragnehmer sehr gut in der Domäne, also den Prozessen des Auftraggebers aus. Nur so war es möglich, die Anwendungsfälle im Sinne der Prozesse beim Auftragnehmer sinnvoll und weitgehend korrekt zu erstellen.
• Zum anderen handelte es sich bei der Software um eine neu aufgesetzte Plattform, die technisch exzellent (insbesondere in Bezug auf Architektur, Entwicklungsumgebung und automatisierte Testbarkeit) gestaltet war. Nur dadurch konnte bei neuen Erkenntnissen zu den Anforderungen immer wieder zu überschaubaren Kosten nachgesteuert werden. Dazu wurde auch die Maschine modular gestaltet.

Das Projekt dauerte insgesamt etwa zwei Jahre. In der Hochphase waren etwa 50 Entwickler gleichzeitig beschäftigt. Natürlich hatten alle Entwickler parallel auch noch andere Projekte. In dem Projekt gab es daher keine systematischen Daily Stand-ups. Statt selbstorganisierter Teams wurden Komponententeams gebildet, die bei der Umsetzung der einzelnen Anwendungsfälle einige Freiheiten hatten und eng zusammenarbeiteten. Statt des Einsatzes eines Task Boards wurden die Tasks mit Excel verwaltet. Statt eines Burn Down Charts wurde in Excel automatisch ein stets aktuelles Earned-Value-Diagramm erzeugt.

Da dieses Projekt die wesentlichen Aspekte (anwendungsfallgetrieben, iterativ) des Unified Prozesses erfüllte, kann es auch als agiles Projekt gesehen werden. Sicherlich wäre es manchen Experten, die ein agiles Vorgehen mit Scrum assoziieren, in diesem Sinne nicht agil genug. Solche Diskussionen sind letztlich jedoch müßig. Pragmatisch betrachtet ist das Projekt ein gutes Beispiel für ein agiles Vorgehen mit Augenmaß, so wie es in dem existierenden klassischen Projektumfeld möglich und sinnvoll war.