Agil trotz klassischen Projektmanagements?

Agil trotz klassischen Projektmanagements? Das kann doch nicht gehen! Agil und klassisch, das sind doch zwei Welten, die nichts miteinander gemein haben! Agil, das ist Scrum! Und Klassik, das ist das Wasserfall-Modell!

Solche oder ähnliche Meinungen und Vorurteile kann man immer wieder von denjenigen hören, die in der klassischen Welt zu Hause sind und von agiler Arbeitsweise bislang nur gehört haben. Oder von solchen, die bisher ausschließlich agil gearbeitet haben und das klassische Projektmanagement nur vom Hörensagen kennen.

Keine Frage, agil ist in, ist hip. Wer heute modern sein will, macht „in agil“. Und das prinzipiell auch aus gutem Grund, denn die Vorteile agiler Vorgehensweisen haben sich in den letzten Jahren – bzw. Jahrzehnten – für eine ganze Reihe von Aufgabenstellungen bewährt.

Aber … insbesondere in großen Konzernen und Organisationen ist manchmal eine bestimmte Arbeitsweise vorgeschrieben. Viele große Unternehmen besitzen ein Projektmanagementhandbuch („PM-Handbuch“), das Prozesse, Ergebnistypen, Rollen und Gremien verbindlich vorschreibt. Ohne einen ausgearbeiteten Projektplan mit Phasen, Phasenabschlüssen, fixem Releasetermin, Budgetplanung, Ressourcenplanung und vorab fertiggestelltem Lastenheft erhält man keine Freigabe für sein Projekt, egal wie „agil“ sich der direkt zuständige Auftraggeber sein Vorhaben möglicherweise vorstellt.

Dazu kommt, dass nicht jedes (Entwickler-)Team für Scrum geeignet ist. Gerade in großen, gewachsenen Organisationen trifft man auch diejenigen Mitarbeiter, die ihr Leben lang nach klarer Vorgabe gearbeitet haben und das nicht ändern wollen oder können.

Aber: Heißt das, dass in einer solchen Umgebung eine agile Vorgehensweise unmöglich ist? Dass man stets streng nach dem Wasserfallmodell arbeiten muss?

Das Wasserfallmodell

Das Wasserfallmodell ist – wie der Name schon sagt – eine modellhafte Darstellung eines möglichst gut vorab geplanten Vorgehens . Kernidee ist, dass das Vorhaben in aneinander angrenzende Phasen zerteilt wird, die in der strengen Auslegung stets vollständig durchlaufen werden müssen, bevor eine neue Phase begonnen wird. Häufig schreibt das PM-Handbuch vor, dass die Ergebnisse einer Phase einzeln von einem Lenkungsausschuss abgenommen werden müssen.

Arbeitet ein Unternehmen nach Wasserfall, so muss die komplette Kaskade von Tätigkeiten für jede Phase vorab soweit ausgeplant sein, dass Aufwand, Kosten und Zeit klar sind, ebenso wie der Inhalt der zu leistenden Arbeitspakete. Und diese Gesamtplanung beauftragt der Auftraggeber zu den genannten Kosten bei Projektstart zur Ausführung.

Tritt während des Projektverlaufs eine Situation ein, die mit dem Plan kollidiert, so muss dieser aufwändig geändert werden. Der neue Plan wird dem Auftraggeber in Form eines Change Request (CR) vorgelegt, damit dieser die geänderte Planung akzeptiert. (Ein solcher CR betrifft in der Regel Kosten und Dauer eines Projektes. Die inhaltlichen Anforderungen werden nur selten im Projektverlauf geändert.)

Mehrere Iterationen oder frühe und kontinuierliche Produktivsetzung von Projektergebnissen sind im Wasserfallmodell nicht vorgesehen. Und das ist nun wirklich nicht agil.

Was heißt denn eigentlich „agil“?

In den letzten beiden Abschnitten haben wir viel von „agil“ geredet. Aber was ist das eigentlich?

Gerade in großen Organisationen trifft man zuweilen auf die Haltung: „Ich mache Dailys und habe ein Kanban-Board an der Wand, also bin ich agil“. Und das ist – offen gesprochen – absoluter Quatsch. Ebenso wenig stimmt es, dass nur dasjenige Projekt agil ist, das nach Scrum arbeitet oder streng die WIP-Limits des Kanban-Boards im Auge behält.

Was agil bedeutet, haben eine Reihe von Leuten im sogenannten „Agilen Manifest“ im Jahr 2001 festgehalten. Dabei geht es um Werte und Prinzipien und nicht um eine konkrete Vorgehensmethode.

Hier noch einmal ein Blick auf die vier agilen Werte zur Erinnerung:

Individuen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Zusammenarbeit mit dem Kunden über Vertragsverhandlung
Reagieren auf Veränderung über Befolgen eines Plans

Die Werte auf der rechten Seite sind wichtig, in der agilen Denkweise sind diejenigen auf der linken Seite aber wichtiger und gehen im Konfliktfall vor.

Widerspricht klassisches Projektmanagement den agilen Werten?

Auf den ersten Blick sieht es so aus, als würde das Wasserfallmodell das genaue Gegenteil der agilen Werte fordern, nämlich stets diejenigen Werte auf der rechten Seite denjenigen der linken Seite vorzuziehen.

Der Projekt- und Aktivitätenplan wird vorab aufgestellt und möglichst genau befolgt. Eine Änderung dieses Plans ist ein aufwändiges Unterfangen, das viele Dokumente, Zustimmungen und ein Einbeziehen des Lenkungsausschusses erfordert. Allein die dafür notwendigen Menschen innerhalb kurzer Zeit zu einem Termin zusammenzubringen, ist in manchen Unternehmen ein Ding der Unmöglichkeit.

Eine Phase ist beendet, wenn die Phasenabnahme erfolgt ist, ein späteres Zurückkehren zu einer vorherigen Phase ist nicht vorgesehen.

Wie kann man da agil sein? Wie kann man so auf Veränderungen reagieren?

Doch, es geht!

Zunächst einmal muss man wissen, dass kaum ein Wasserfallmodell in der Realität so idealtypisch abläuft, wie es im obigen Bild suggeriert wird. Normalerweise überlappen die Phasen einander.

Auch in anderer Hinsicht kann und darf man von der „Ideallinie“ abweichen. Und genau an diesen Stellen kann man ansetzen – wenn die Organisation und die Auftraggeber mitspielen.

Was kann man wie justieren?

Zunächst einmal sollte man frühzeitig bei der Planung die verlangten Phasen möglichst weit überlappen. Alle Beteiligte sollen sich von Anfang an daran gewöhnen, dass die Konzeptionsphase bis kurz vor Ende der Realisierung läuft, und dass der Test schon wenige Wochen nach Beginn der Konzeptionen startet.

Der nächste Schritt besteht darin, die gewünschten Funktionen in möglichst unabhängige Einzel-Features zu schneiden. Mindestens ein ausführliches Lastenheft – auch „Fachliches Grobkonzept“genannt – besteht ja vor Beginn des Projektes, sonst könnte das Projekt nicht geplant werden. Also weiß ich, was sich der Auftraggeber alles an Funktionen, an Features wünscht.

Diese Features werden dann nach folgenden Gesichtspunkten bewertet:

• Sind andere Features davon abhängig?
• Wie wichtig ist das Feature für den Gesamterfolg?

Fühlt sich jemand an Aufstellen und Priorisieren eines Product Backlogs erinnert? Das, was wir hier tun, ist sehr ähnlich. Allerdings rate ich davon ab, diese Featureliste „Product Backlog“ zu nennen. Begriffe erzeugen Realität, und wenn die Projektcontroller, die auf einem Wasserfallmodell bestehen, derartige Begriffe hören, könnten Alarmsignale angehen.

Ist diese Vorarbeit getan, habe ich eine Liste von Features, die in eine Reihenfolge gebracht sind.

Der nächste Schritt ist absolut entscheidend: Ich teile das gesamte Projekt in (mindestens) zwei Teile, jeweils mit einem Release am Ende.

Was gibt mir die Erlaubnis, das Projekt so zu planen? Die Auftraggeber möchten in der Regel sehr schnell Resultate erzielen. Gleichzeitig möchten sie nicht auf die von ihnen anfangs aufgestellten Features verzichten. Aber beides muss nicht notwendigerweise zum gleichen Zeitpunkt passieren. Wenn ich geschickt argumentiere, kann ich die Auftraggeber von den Vorteilen mehrerer Releases überzeugen.

Wie ich das Projekt aufteile, ist situationsabhängig. Vielleicht orientiere ich mich an den Features, teile sie in „Release 1.0“ und „Release 1.1“ (oder weitere) auf. Vielleicht teile ich auch den Aufwand oder die Zeit linear – z. B. zu 70 % bzw. 30 % – und ordne die Features danach zu. In jedem Fall muss dem Auftraggeber und dem Lenkungsausschuss bewusst werden, dass sie beim ersten Release nicht die komplette Funktionalität haben, diese aber in weiteren Releases bekommen werden.

Insbesondere die Liste der Features, die im ersten Release vorgesehen sind, stimme ich intensiv mit den Auftraggebern ab. Gleichzeitig behalte ich im Hinterkopf, dass diese Liste nur ein „erster Aufschlag“ ist. Warum, das erkläre ich gleich.

Sobald diese Vorarbeiten einvernehmlich geklärt und bestätigt sind, kann das Projekt starten und die Projektarbeit beginnen. Dabei werden die Features in der aktuell entschiedenen Reihenfolge bearbeitet.

Jedes Feature durchläuft jetzt für sich genommen den Wasserfallprozess:

Anpassungen während der Projektlaufzeit

Jetzt läuft also das Projekt. Das Team ist dabei, die einzelnen Features nacheinander (oder auch parallel) zu konzipieren, zu entwickeln und dem Komponententest zu unterziehen.

Und auch wenn es diejenigen, die an Pläne glauben, nicht wahrhaben wollen: Es ist vorhersehbar, dass dabei etwas Unvorhersehbares geschieht.

Zum Beispiel fällt bei der Entwicklung auf, dass die DV-Konzeption unvollständig gewesen ist oder verändert werden muss. Kein Problem. Da alle Phasen nahezu gleichzeitig laufen, kann ich mit einem einzelnen Feature jederzeit Schritte zurück machen.

Nur führt das häufig zur nächsten Herausforderung:

Ein Feature benötigt mehr Aufwand / Zeit als ursprünglich geplant!

Das allererste Mittel, dieser Situation zu begegnen, ist Ruhe bewahren. Manchmal gleicht sich eine Aufwanderhöhung an einer Stelle durch Einsparungen an anderer Stelle aus. Vielleicht habe ich vorsorglich einen Aufwandspuffer eingebaut, aus dem sich das Projekt bedienen kann. Häufig genug reichen diese Maßnahmen aber nicht (mehr), und ich muss handeln.

Im „normalen“ Wasserfall muss ich an dieser Stelle einen Change Request vorbereiten. In der angepassten Vorgehensweise habe ich noch andere Optionen.

Als Grundsatz gilt: Jedes noch nicht begonnene Feature steht zur Disposition.

Ich habe einige Handlungsmöglichkeiten, um auf die neuen Anforderungen zu reagieren:

• Ein Feature wird auf ein späteres Release verschoben. Ich muss nach jedem Release das Folgeprojekt sowieso neu bewerten. Es ist einfacher, einen gemeinsamen CR nach dem Release zu erstellen, als mehrfach während der Projektlaufzeit.
• Features können in der Reihenfolge verändert werden. Manchmal löst das schon den Knoten, weil Abhängigkeiten, die ich vorher nicht gesehen habe, sichtbar werden.
• Der Projektverlauf zeigt, dass einzelne geplante Features nicht unbedingt sinnvoll sind. Wir können dem Auftraggeber vorschlagen, als Kompensation unnötige Features wegzulassen. Erstaunlicherweise ist ein Auftraggeber bei einem laufenden Projekt häufig bereiter, über so etwas zu reden, als vor dem Start eines Projektes.

In jedem Fall habe ich Handlungsspielraum, den ich nutzen kann.

Häufig werden auch komplett neue Anforderungen an das Projekt gestellt. Und hier kann man mit einer angepassten Vorgehensweise richtig punkten.

Ein „klassischer“ Projektleiter, der die agilen Werte nicht berücksichtigt, wird sich gegen eine solche neue Anforderung stets sperren. Das muss er oder sie sogar tun, denn schließlich gibt es ja einen vereinbarten Projektauftrag, den der Auftraggeber nicht einseitig ändern kann, und den der Projektleiter verteidigen muss.

Die neue Anforderung ist aber möglicherweise gut und sinnvoll. Bleibt also wieder nur der CR?

In unserem Szenario kann ich als Projektleiter jetzt für den Auftraggeber deutlich positiver reagieren. Ich nehme die neue Anforderung positiv zur Kenntnis, gemäß dem agilen Prinzip, Veränderungen zu begrüßen. Als Erstes bewerte ich sie zusammen mit dem Team.

Und dann biete ich eines der bereits geplanten Features zum Streichen an. Natürlich kann ich als Projektleiter nicht einfach die Ausweitung des Scopes akzeptieren. Aber ein Tausch, bei dem die übrigen Parameter (Aufwand, Zeit) in etwa gewahrt bleiben, den kann ich akzeptieren.

Wieder gilt der Grundsatz: Jedes, noch nicht begonnene Feature steht zur Disposition.

Wir arbeiten agil

Ein Projekt, das auf die oben beschriebene Weise geführt wird, wird beim Auftraggeber gut ankommen, denn er oder sie wird das Gefühl haben, Einfluss nehmen und das Projekt gestalten zu können. Und das, auch ohne jedes Mal einen CR ertragen zu müssen.

Als Projektleiter hat man größere Freiheiten, um im Projektverlauf auf diejenigen Ereignisse zu reagieren, die mit deutlich größerer Häufigkeit auftreten, als es die Projektcontroller und die Damen und Herren des PM-Handbuches vermuten.

Werfen wir noch einmal einen Blick auf die agilen Werte. Der Fokus des oben gesagten liegt dabei vor allem auf den Werten „Reagieren auf Veränderungen“ und „Zusammenarbeit mit dem Kunden“. Wie gezeigt kann man beide Werte auch in klassischer Vorgehensweise den Werten „Vertragsverhandlung“ und „Befolgen eines Plans“ vorziehen.

Und wie steht es mit den anderen Werten und Prinzipien?

Auch in einem klassischen Projekt sollten alle Projektmitarbeiter häufig – im besten Fall täglich – zusammenarbeiten. Besonders effektiv ist es, ein Projektteam an einem Ort zu konzentrieren, um miteinander zu kommunizieren, anstelle anonyme Konzepte „über den Zaun geworfen zu bekommen“ („Individuen und Interaktionen“ über „Prozesse und Werkzeuge“).

Und automatisierte Tests helfen dabei, den Fokus auf „Funktionierende Software“ zu legen, anstelle auf „umfassende Dokumentation“.

Sehr empfehlenswert ist es übrigens, einige weitere Methoden des agilen Werkzeugkastens zu adaptieren. Dazu gehören sicherlich das Daily Stand-up (IT und Fachbereich zusammen) und die Retrospektive (Retro), also das regelmäßige Zusammensitzen des gesamten Teams, um die Vorgehensweise zu hinterfragen. Eine solche Retro empfiehlt sich mindestens nach jedem Release (nennt sich dann üblicherweise „Lessons learned session“). Es hindert einen aber niemand daran, sich alle 2-3 Wochen mit dem Team zu treffen und die eigene Vorgehensweise zu reflektieren.

Wo sind die Grenzen? Wie agil kann man werden?

Das agile Manifest untermauert die vier oben genannten Werten mit einer Reihe von Prinzipien. Einige davon sind in einer klassischen Projektumgebung vergleichsweise schwierig umzusetzen. Dazu zählen insbesondere diejenigen Prinzipien, die auf eine frühe und regelmäßige Auslieferung von Software zielen. Klassische Organisationen erlauben Auslieferungen von Software häufig nur nach Durchlaufen eines komplexen Genehmigungsverfahrens, mit mehreren Stufen der Abnahme und Qualitätskontrolle. Einen solchen Prozess durchläuft man nur sehr ungern alle 2-3 Wochen.

Trotzdem kann man auch hier sinnvolle Dinge tun:

Um frühzeitig Rückmeldung von Anwendern zu bekommen, gibt es zum Beispiel die Methode des Rapid Prototyping, um (zumindest von ausgewählten Anwendern) frühzeitig eine Rückmeldung zu erhalten.

Zusammenfassung: Es geht also doch

Was zunächst wie ein Widerspruch ausgesehen hat, muss bei näherer Betrachtungsweise keiner sein. Es ist durchaus möglich, mit den Methoden des klassischen Projektmanagements die Werte und Prinzipien der agilen Softwareentwicklung zu verfolgen. Dazu ist es allerdings notwendig, dass Projektleiter und Auftraggeber einvernehmlich einige Vereinbarungen treffen.

Das volle Potenzial von agilem Vorgehen wird man damit allerdings nicht erreichen können. Dafür muss eine Organisation bereit sein, die eigene Arbeitsweise zu verändern, mehr Transparenz zu wagen und mehr Kompetenzen von den Führungskräften auf die Mitarbeiter zu verlagern.

Trotzdem kann man auch in einem klassischen Umfeld eine Arbeitsweise verfolgen, die willens und in der Lage ist, auf Veränderungen zu reagieren und nicht erst drei Jahre nach Projektstart (inklusive vier Change Requests) Software abzuliefern, die dann niemand (mehr) benötigt.

Diese Ausrede gilt nicht mehr 😉