Der komplette Projektmanager. Roel Wessels
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