Sind wir zielgeil?

Wir leben in einer zielgeilen Zeit. Die zeitgenössische Management- und Komplexitätsbewältigungsliteratur suggeriert uns, dass alles ein Ziel haben muss. Aber wie können wir Ziele haben, wenn wir nicht wissen, was uns die Zukunft bringt? Oft wird unter einer komplexen Situation eine intransparente, vernetzte und ungewisse Situation verstanden. Wie können wir Ziele haben, wenn die Zukunft ungewiss ist?
In einem Blog habe ich folgende Geschichte gelesen:

Die Schüler fragen ihren Meister: »Wie also reist man zu seinem Ziel?« Der Meister antwortet: »Man reist nicht. Es ist eine Reise ohne Entfernung. Hört auf zu reisen, und ihr seid da.« Die Schüler können das nicht verstehen, und so erklärt der Meister: »Solange man unterwegs zu einem Ziel ist, kann man an einem Traum festhalten. Wenn man anhält, steht man vor der Wirklichkeit.« Verwirrt fragen die Schüler weiter: »Wie sollen wir uns je verändern, wenn wir keine Ziele oder Träume haben?« »Stellt euch der Wirklichkeit, und alles wird sich spontan verändern.«1

Letzte Woche habe ich mich mit einem Autor eines Buches über Komplexitätsmanagement unterhalten2. Er ist mit mir einig, dass Ziele nicht von Anfang an vollständig und starr sind, sondern sich mit dem Handeln konkretisieren. Er erzählte mir, dass sie vor einiger Zeit einen Industrieauftrag zum Themenkreis “Ziele, Zielbildung, Zielverfolgung” erhalten haben. Für mich bedeutet das, dass sich Manager vorstellen, man müsse nur Ziele haben und diese verfolgen, damit alles so werde, wie man es sich wünsche. Ein reichlich naiver Gedanke, der alle Kenntnisse über das Funktionieren unseres Geistes und die Enstehung komplexer Systeme ignoriert3.

1 Dieter Halbach, Wie geschieht Veränderung?

2 Reither, F. Komplexitätsmanagement – Denken und Handeln in komplexen Situationen. Gerling Akademie Verlag.
München 1997

3 z.B. Addor, P. Projektdynamik – Komplexität im Alltag. Reinhold Liebig Verlag, Frauenfeld 2010

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