Ist agiles Projektmanagement immer anwendbar?

Im Umgang mit Komplexität sind agile Methoden heute in aller Leuten Munde. Wenn man unter einer komplexen Situation aber eine Situation versteht, die

  • unübersichtlich
  • vernetzt
  • unbestimmt

ist, dann sind agile Methoden im Umgang mit Komplexität meines Erachtens nicht notwendigerweise hilfreich. In Entwicklungsprojekten ist agiles Projektmanagement ein sehr nützlicher Ansatz, wenn man aus einem Produktebacklog gerade so viele Funktionen entnehmen kann, wie man in einer bestimmten Zeit entwickeln mag. Für Migrations- und Intregrationsprojekte (MIP) sind agile Techniken jedoch weniger geeignet1. Um das einzusehen, erinnern wir uns, dass Migrations- und Integrationsprojekte oft mit der Aufgabe starten, gelieferte Hardware zu entpacken, in einem Rack zu montieren, an ein Netz anzuschliessen und in Betrieb zu nehmen. Dazu gehören natürlich erste Funcional Tests, insbesondere Pingtests zu gewissen Servern in der bestehenden Umgebung.

Für die Montage und Grundinstallation sind z.B. 10 Tage geplant. Wenn die agile Projektmethodik eine Timebox von 4 Wochen vorgesehen hat, lässt sich aus der Montage keine Timebox machen.
Das agile Prinzip, innerhalb einer Timebox keine Changes zuzulassen, greift hier auch nicht, denn Changes sind in einem MIP nicht das grosse Schreckgespenst. Wenn der Kunde das Rack innerhalb des Serverraums zig Mal umplazieren will, nervt das zwar, ist aber weiter kein Problem. Changes machen auch noch keine Komplexität aus. Das Schwierige in MIP sind Ereignisse, die sowohl für den Kunden als auch für den Lieferanten gleichermassen unvorhergesehen sind. Eine typische Unvorhersehbarkeit während einer Montage ist die Tatsache, dass irgendwelche Firewalls nicht richtig konfiguriert sind (das ist mittlerweile derart typisch, dass es schon keine Unvorhersehbarkeit mehr ist, sondern als vorhersehbares Risiko behandelt werden kann. Aber sagen Sie das einmal dem Kunden…).

Ein weiteres agiles Prinzip ist der Kundennutzen. Jede Iteration soll einen bestimmten Kundennutzen haben. Jede weitere Iteration erhöht den Kundennutzen. Eine Reihe von Iterationen werden zu einem Release zusammen gefasst, der eigentlich schon ein fertiges Produkt darstellt. Das geht bei MIP nicht. Das Resultat der Monatge enthält kaum Kundennutzen, musst aber dennoch gemacht werden. Daraufhin folgt die Installation der Software und anschliessend monatelange Tests bis zur Migration oder der Abnahme. Man kann nicht eine Iterationfolge „ein bisschen Montage, ein bisschen Software, ein bisschen Tests“ machen, um einen ersten Release zu haben. Das geht in MIP nicht. MIP sind wie eine Schwangerschaft: man installiert einen bestimmten Release; alles oder nichts. Ein weiterer Release ist ein neues MIP.
Da eine vollständige Benutzerdokumentation zum Lieferumfang eines MIP gehört, gilt auch das agile Prinzip „funktionstüchtige Produkte vor umfangreicher Dokumentation“ hier nicht. Ob das Produkt funktionstüchtig ist, liegt nicht in der Macht des MIP, sondern des vorangegangenen Entwicklungsprojekts. Eine vollständige und umfangreiche Dokumentation ist jedoch ein typisches Deliverable eines MIP.

Für Entwicklungsprojekte mögen agile Techniken eine hervorragende Methode sein. Auf ein Entwicklungsprojekt kommen hoffentlich viele Migrations- und Integrationsprojekte. Schliesslich will man das entwickelte Produkt oft verkaufen und ausrollen. Agile Techniken sind aber für das Management von Migrations- und Integrationsprojekten nicht sehr geeignet.

1Addor, P. Projektdynamik – Komplexität im Alltag. Liebig Verlag, Frauenfeld 2010, S. 65ff

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.