Читать книгу Der komplette Projektmanager - Roel Wessels - Страница 14

Funktioniert das Projektmodell auch in Situationen mit vielen Unsicherheiten (Cynefin komplex)? Die Anwort ist jein. Ja, weil auf der Ebene des Auftraggebers oftmals in der Struktur des Projektmodells gedacht und gehandelt wird:

Frage Plan/Angebot Vertrag Ausführung Abnahme

Ihnen bleibt demnach gar nichts anderes übrig, als auf dieselbe Weise zu denken und zu kommunizieren.

Nein, weil das Projektmodell im Prinzip auf dem Wasserfallmodell basiert. Dies bedeutet, dass die Phasen nacheinander durchlaufen werden müssen und Sie demnach erst dann mit einer neuen Phase beginnen können, wenn die vorherige zu 100% abgeschlossen ist. Und es empfiehlt sich nicht, später zurück in eine vorherige Phase zu springen. Darum werden wir das Projektmodell in diesem Abschnitt mit agilen Elementen erweitern. Wir gehen dabei weder von Wasserfall oder reinem Agile aus, sondern wir nutzen die Kombination (der eine Teil des Projekts als Agile, der andere Teil als Wasserfall), denn dies ist auch, was Ihnen häufig im wirklichen Projektleben begegnet.

Das Wasserfallmodell

Im Wasserfallmodell beginnen Sie erst dann mit dem Entwurf, wenn alle Forderungen bekannt sind. Und die Testphase wird erst dann durchlaufen, wenn der vollständige Entwurf realisiert wurde. Wird ein Fehler aufgedeckt oder muss etwas verändert werden, so begeben Sie sich zurück in die diesbezügliche Phase und der Projektpfad wird ab diesem Punkt erneut durchlaufen. Eine lästige Gegebenheit bei Situationen mit vielen Unsicherheiten. Diese bieten nämlich niemals eine 100%ige Vollständigkeit. Außerdem ist die Gefahr hoch, dass es doch noch zu Änderungen an den Spezifikationen kommt, während Sie bereits entwerfen. Wasserfall in Cynefin komplexen Projekten bedeutet also das Warten auf Deutlichkeit, während Sie wissen, dass weitere Korrekturen anstehen werden…?

Concurrent Engineering

Um die Schmerzen zu lindern, kann Concurrent Engineering, bzw. paralleles Entwickeln angewendet werden. Beim Concurrent Engineering dürfen Projektphasen nämlich parallel ausgeführt werden. Es wird dann bereits am Entwurf gearbeitet, während die Spezifikationen noch nicht ganz klar oder vollständig sind. Dies bietet die Gelegenheit, auch bei Unsicherheiten dennoch einen Fortschritt verbuchen zu können.

In aller Fairness muss gesagt werden, dass der wahre Grund für Concurrent Engineering oftmals ein Kürzen der Projektdauer ist. Indem die Beteiligten nicht nacheinander an Ihren Themen arbeiten, sondern gleichzeitig, wird das Projekt sozusagen zusammengepresst. Das ist keineswegs verkehrt, macht die Projektausführung aber komplexer. Denn das simultane Arbeiten an Aktivitäten, die eigentlich nacheinander geschehen sollten, verlangt viel Geschick der Mitglieder des Teams, sehr gute Einsicht in die Arbeiten des Anderen und ein hohes Maß an Kommunikationsfähigkeit von allen.

Abbildung 1.8 Das Wasserfallmodell

Abbildung 1.9 Concurrent Engineering

Agile: Unsicherheiten sind Tatsachen

Obwohl Concurrent Engineering also einen Schritt in Richtung Flexibilisierung bedeutet, wird dies durch eine höhere Ausführungskomplexität erkauft. Außerdem geht die Methode, genau wie das Wasserfallmodell, davon aus, dass jede Phase vollständig abgeschlossen sein und Unsicherheit zunächst aus dem Weg geräumt werden muss. Aber was ist, wenn dies nicht gelingt?

Die Agile Methodik (der italienische Musikbegriff “agile” bedeutet schnell bzw. beweglich) dreht dies ins genaue Gegenteil. Agile sieht Unsicherheiten als gegebene Tatsachen an und nicht als etwas Unerwünschtes. Es geht davon aus, die Welt könne eben nicht geformt werden und Projekte in einem unsicheren, dynamischen Umfeld sind demnach nicht vorhersehbar. Zusätzlich schafft agiles Arbeiten ein Umfeld, in dem das Tragen von Verantwortung durch die Mitglieder des Teams explizit stimuliert und ermöglicht wird. Hierdurch kann der Projektmanager eine eher coachende und fördernde Haltung annehmen und muss nicht mehr leitend oder direktiv sein. Agiles Arbeiten ist für die Softwareentwicklung entworfen worden, aber kann mit etwas Geschicklichkeit auch in anderen Umfeldern eingesetzt werden. Beispielsweise in der Mechatronik, im Bau- und öffentlichen Sektor, etc.

Obwohl PRINCE2 und andere Methoden den agilen Ansatz inzwischen integriert haben, werden das Wasserfall- und das Agile-Modell oftmals als Gegensatz wahrgenommen. Das ist schade, denn das hebt künstlich die Unterschiede hervor, während es doch in der Realität gar nicht praktikabel ist, entweder rein Agile oder nur nach dem Wasserfallmodell zu arbeiten. Die Modelle bestehen nebeneinander und das sollte die Projektausführung auch nicht erschweren. Dennoch tun sich viele Organisationen mit der Kombination von mechanischer Produktentwicklung (Wasserfall) und Softwareentwicklung (Agile) schwer. Die Teams sprechen nicht dieselbe Sprache und sehen den Prozess des jeweils anderen Teams als eine unbegreifliche Blackbox an. Hierdurch können selbst innerhalb einer Organisation verschiedene Welten entstehen, die einander unzureichend verstehen und nebeneinander her anstatt zusammen arbeiten.

Wie werden Wasserfall und Agile in Ihrer Organisation angewendet?

Schwarz-Weiß-Denken in Agile versus Wasserfall wird sich also kontraproduktiv auswirken. In diesem Buch möchte ich betonen, wie Sie beide Methoden miteinander kombinieren können. Dazu werde ich Agile nicht nur als Methode, sondern auch als Verhalten besprechen. Agiles Verhalten bietet nämlich auch innerhalb von traditionell organisierten (Wasserfall-)Projekten Möglichkeiten, um die Wendigkeit, den Fokus auf Produktinkremente und die Autonomie der Teammitglieder zu erhöhen.

Kurze Iterationen

Ein wichtiger Unterschied von Agile im Gegensatz zum traditionellen Projektansatz ist die Methode der Projektkontrolle. In einem traditionellen Projekt wird der Projektumfang meist als fix und unveränderlich angesehen. Bei Rückschlägen oder Änderungen bedeutet dies automatisch, dass das Projekt länger dauert und mehr Kosten entstehen. Dieser Druck hinsichtlich Zeit und Budget bewirkt anschließend die Reaktion, während der des Projekts den Plan zu korrigieren, wobei es nicht ungewöhnlich ist, dass Qualität eingebüßt wird: Zum Beispiel wird weniger Zeit für die Ausführung der Aufgaben veranschlagt, Reviews werden gekürzt, der Fokus liegt weniger auf dem Risikomanagement, das Testprogramm wird gekürzt, etc.. Der Druck entsteht dabei in der Regel besonders in der letzten Phase des Projekts.

In agilen Projekten werden Zeit, Geld und Qualität hingegen als feste Grössen gesehen. Der Projektumfang ist ebenfalls wichtig, aber in agilen Projekten verhandelbar. Er besteht daher aus einer Übersicht der zu liefernden Funktionalitäten, geordnet nach Priorität. Von diesen Funktionen wird realisiert, was innerhalb der zur Verfügung stehenden Zeit und des Budgets möglich ist. Gibt es Rückschläge, so fallen die am wenigsten notwendigen oder optionalen Funktionen weg. Zeit, Geld und Qualität der Umsetzung sind daher nicht verhandelbar, die Funktionalität dagegen schon. Dies bewirkt eine wesentlich andere Dynamik und Führungsverhalten als bei einer traditionellen Projektleitung.

Werden die weggelassenen Funktionen auch wirklich aus dem Umfang genommen? Oftmals nicht, denn anstelle einer einzigen, langen Ausführungsphase arbeitet Agile mit mehreren kurzen Iterationen. Funktionen, die dabei zunächst wegfallen, werden im Grunde in die darauffolgende Iteration mitgenommen. Vorausgesetzt es gibt einen ausreichenden Puffer (oder optionale Funktionalitäten) in den letzten Iterationen, so wird das Endergebnis die Funktionalitäten enthalten, die auch im Umfang besprochen worden waren. Ist kein Puffer vorhanden, dann wissen Sie auf jeden Fall, dass die wichtigsten Funktionen realisiert worden sind, ohne dass Sie Eingeständnisse an Zeit, Geld und Qualität machen mussten.

Mehrwert generieren

Der Fokus auf Qualität wird dadurch verstärkt, dass alle Iterationen funktionierende Produktinkremente liefern müssen, die der (End)Nutzer beurteilen kann. Obwohl die jeweiligen Iterationen somit nur einen Teil der Projektfunktionalität implementieren, durchlaufen Sie dennoch den gesamten Entwurfsszyklus von dem Entwurf bis hin zur Realisierung und der Testphase. Sie bearbeiten also nicht alles, aber das, was Sie bearbeiten, schließen Sie auch vollständig ab. Agiles Arbeiten ermöglicht dadurch während des Projekts bereits Feedback von Seiten des Nutzers. In Abbildung 1.10 ist die agile Arbeitsweise wiedergegeben.

Abbildung 1.10 Agiles Entwickeln. Die neun Funktionen werden inkrementell entworfen (E), realisiert (R) und getestet (T).

Das Arbeiten mit Iterationen liefert noch einen weiteren Vorteil. Der Auftraggeber darf nämlich vor jeder Iteration Veränderungen anbringen. Denn Agile beruht auf dem Wissen das Veränderungen normal und zu erwarten sind. Hierbei gilt jedoch die Absprache: Wenn eine Iteration einmal begonnen hat, dürfen die Teammitglieder nicht mehr gestört werden und weitere Änderungen sind verboten. So wird die Flexibilität für den Auftraggeber mit Effizienz im Team kombiniert. Da Iterationen nur eine Dauer von wenigen Wochen haben, wird dieses während einer Iteration geltende Veränderungsverbot von den Auftraggebern meist nicht als Einschränkung gesehen. Also wirklich eine schöne Kombination aus Flexibilität und Effizienz.

Außer dem Rhythmus von Iterationen kennt Agile noch einen täglichen Rhythmus: Das Teammeeting. Dies ist ein tägliches Standup Meeting mit allen Teammitgliedern, worin Effektivität und Effizienz hochgehalten werden. Die Haltung während dieser Sitzung ist aktiv und konzentriert, denn nur so kann eine Sitzung zu einer richtigen Abstimmung führen und auch nur kurz dauern. Nacheinander erklären die Teammitglieder, was sie realisiert haben, was sie als nächstes tun werden und wo sie Probleme erwarten. Jeder erhält also das Wort, aber muss sich kurz und bündig präsentieren. Eine gute Vorbereitung ist daher von wesentlichem Belang. Sollten Diskussionen zu tiefgründig werden und nicht mehr für die gesamte Gruppe von Nutzen sein, so werden diese durch eine aktive Moderation auf ein separates Gespräch nach der Teammeeting verlegt.

Durch das tägliche Teammeeting, die klaren Prioritäten hinsichtlich der zu liefernden Funktionalität und die direkte Beurteilung der Produktinkremente am Ende jeder Iteration, ist es möglich, dem Entwicklungsteam ein hohes Maß an Eigenverantwortlichkeit zu geben. Agile bietet auf diese Weise wichtige Voraussetzungen, um das Team selbstorganisierend arbeiten zu lassen. Das bedeutet, dass die Teammitglieder selber die Planung und Realisierung der zu liefernden Produkte organisieren, sowie die hierfür benötigte Zusammenarbeit und Koordination sichern. Eine Verantwortung, die bei traditionellen Projekten vor allem beim Projektmanager zu finden ist.

Die Rolle des Projektmanagers

Was bedeutet Agile in diesem Fall für die Rolle des Projektmanagers? Um es so konkret wie möglich zu machen, beziehe ich mich in diesem Buch auf Scrum, eine Anwendungsform von Agile. In Scrum heißen die Iterationen Sprints, nennt man die priorisierte Liste der Funktionen das Product-Backlog, den zugewiesenen Umfang pro Sprint das Sprint-Backlog und das tägliche Teammeeting das Daily-Scrum-Meeting. Die Planungssitzung zu Beginn eines jeden Sprints heißt die Sprint-Planungssitzung (PL in Abbildung 1.10). Scrum beschreibt weiterhin zwei Hauptrollen, wozu jedoch die des Projektmanagers nicht gehört: der Product-Owner und der Scrum-Master. Dies ist übrigens kein Nachteil für den Projektmanager, sondern bietet, wie Sie in kürze lernen werden, vor allem Möglichkeiten.

Der Product-Owner verwaltet und priorisiert das Product-Backlog. Damit berücksichtigt er die Wünsche des Kunden und muss hierfür das entsprechende Mandat vom Auftraggeber haben. Das Daily-Scrum-Meeting ist der Moment für den Product-Owner, um sich mit den Teammitgliedern über die Zwischenergebnisse und die dahinterliegende Welt des Kunden(wunsches) abzustimmen. Der Product-Owner ist also explizit Teil des Teams, wodurch gewährleistet wird, dass die Stimme des Kunden in die täglichen Absprachen integriert ist. Bei traditionellen Methoden befindet sich diese Rolle oftmals außerhalb des Teams, wodurch die Herausforderung, die Stimme des Auftraggebers bzw. Kunden bis ins Team durchdringen zu lassen, im Allgemeinen wesentlich beim Projektmanager liegt.

Das Team und somit auch der Product-Owner werden vom Scrum-Master unterstützt. Dies ist eine andere Rolle als die des Projektmanagers, da der Scrum-Master das Team nicht leitet, sondern coachend und fördernd agiert, das heisst in einem agilen Umfeld muss sich das Entwicklungsteam selbst organisieren können, um die zugewiesenen Ziele auf eine effiziente Art und Weise zu erreichen.

Die hinzugefügten Rollen Product-Owner und Scrum-Master bieten die Voraussetzungen für den expliziten Fokus auf das Business und die Unterstützung von sich selbst organisierenden Teams. Und hiervon profitiert gerade der Projektmanager. Er kann sich somit auf seine primären Aktivitäten konzentrieren. Beispielsweise auf die Leitung des Gesamtprojekts, die Synchronisierung der Teilprojekte (Scrum-Teams und andere Teilprojekte), das Managen der externen Schnittstellen, die Zurverfügungstellung von benötigten Ressourcen, die Abstimmung mit den externen Betroffenen und die Verwaltung des Budgets.

Abbildung 1.11 Der Scrum-Prozess (mit einer Sprintperiode von 30 Tagen)

Agile schafft also in einem Umfeld von Unvorhersehbarkeit einen vorhersehbaren Rhythmus von Zwischenergebnissen. Kurze Iterationen in festen Zeitfenstern und sich selbstorganisierende, multidisziplinäre Teams bilden hierbei die Basis. Der Gedanke hinter dieser Projektleitung ist wesentlich anders als der beim traditionellen Projektmanagement, aber es wird Ihnen schon aufgefallen sein, dass die agilen Elemente zum Großteil auf gesundem Menschenverstand beruhen. Es hält Sie nichts und niemand davon ab, diese auch in einer traditionelleren Projektorganisation anzuwenden.

Agile und das Projektmodell

Agile kann wunderbar im Projektmodell verarbeitet werden. Nur besteht dann der Projektaufbau nicht mehr nur aus einem einmaligen Entwurf-Realisierung-Test-Ablauf. Sondern bei jeder Iteration durchlaufen eine Reihe von Funktionalitäten (parallel zueinander) den gesamten Entwicklungsablauf und liefern so am Ende der Iterationen getestete Zwischenprodukte (siehe Abbildung 1.12). Dies bedeutet, dass die Nutzungsphase auch früher beginnen wird.

Darüber hinaus wird die Projekteinrichtungsphase etwas anders aussehen als im klassischen Modell. Denn es ist nicht praktisch, im Voraus bereits alle Details auszuarbeiten, wenn während der Ausführung noch weitere Anpassungen erwartet werden. Details werden folglich erst dann ausgearbeitet, wenn die jeweilige Iteration auch wirklich beginnt. Der Fokus während der Projekteinrichtungsphase liegt daher auf der Erstellung einer übersichtlichen Liste von Funktionalitäten (dem Product-Backlog), einer Architektur, welche eine iterative Entwicklung zulässt, einer Abschätzung der Größe der Funktionalitäten aus dem Product-Backlog und eines Plans, der beschreibt, welche Funktionalität in welcher Iteration realisiert werden soll.

Abbildung 1.12 Agile Entwicklung und das Projektmodell