Agile Projekte beherrschen

Klassische, auf Wasserfall- oder V-Modellen aufbauende Projekt-vorgehen stehen in den meisten Organisationen im Vordergrund. Dennoch fasst die Agilität Fuss und hat sich vor allem in der IT-Projektabwicklung etabliert. Im Umgang mit Projektmanage-mentdisziplinen wie Risikomanagement, Qualitätsmanagement, Planung, Controlling und Reporting häufen sich aber offene Fragen. In diesem Artikel beleuchten wir zwei wichtige Themen-blöcke und stellen Modelle in der Etablierung von Agilität vor.

Agile Projekte beherrschen

 

Ein agiles Projektvorgehen ist zeitgemäss und wird als Allheilmittel postuliert. Welches Unternehmen will nicht agil sein? Der Wandel hin zur (Teil-) Agilität in einer Organisation bedingt jedoch zwei funda-mentale Umstände:

 

  • Es muss sich lohnen: Mit agilen Vorgehen werden bessere Projekt­ ergebnisse erzielt oder die Projektergebnisse schneller mit genü-gender Akzeptanz zur Produktreife gebracht.
  • Es muss möglich sein: Agile Vorgehensweisen erfordern gravieren-de Anpassungen in der Organisationskultur, d. h. in der Einstellung und dem Verhalten von Personen aller Hierarchieebenen. Zudem muss sich ein Projektergebnis iterativ erweitern und schrittweise zur Reife führen lassen.

 

Detailliert auf alle Aspekte einer erfolgreichen agilen Transfor-mation einzugehen, würde den Rahmen dieses Artikels sprengen. Die wichtigsten Voraussetzungen sind in Tabelle 1 zusammengetragen. Ausserdem ist zu berücksichtigen, dass jede Änderung einer Organi-sation – also auch diejenige hin zur Agilität – neben einer guten Vorbe-reitung und Durchführung viel Reifezeit bedingt.

Anwendungsmodelle und Transformation
Organisationen gehen die agile Transformation – den Wandel von klassischem zu agilem Projektvorgehen – in der Regel mit viel Herz-blut und sorgfältigem Change Management an. Die vollständige Aus-prägung der Agilität passt jedoch nicht in jedes Umfeld. Grundsätzlich sehen wir drei verschiedene Modelle für die Anwendung von Agilität in Organisationen (vgl. Abb. 1):

 

  1. Das hybride Modell: Agil abgewickelte Projekte kombiniert mit klassischem Projektportfolio- und Programm-Management
  2. Das bi-modale Modell (auch Two-Speed genannt): Klassisch und agil abgewickelte Projekte existieren nebeneinander und werden durch klassisches oder agiles Projektportfolio- und Programm-Management priorisiert.
  3. Die vollständige Agilität: Agile Managementansätze auf den Ebe-nen Projektportfolio, Programme und Projekte

 

Klassische und agile Elemente lassen sich gut kombinieren und erzielen zusammen eine hohe Wirksamkeit. Die Mischung der Mo-delle ist entweder Endziel oder Zwischenstadium auf dem Weg der agilen Transformation. Dabei gibt es kein Richtig oder Falsch, sondern nur eine bessere oder schlechtere Adaption an die Bedürfnisse und Fähigkeiten einer Organisation.

Chancen, Risiken und Qualität
Bei unserer Kundentätigkeit werden wir häufig mit Fragestellungen konfrontiert wie: Sind Chancen, Risiko- und Qualitätsmanagement in der agilen Welt überhaupt vorgesehen? Wie können wir sicherstellen, dass unser Vorhaben nicht ausser Kontrolle gerät? Wer ist verantwort-lich, wenn es keine klassischen Projektleiter gibt?

 

Die agile Vorgehensweise setzt sich implizit aktiv und wiederholt mit Chancen und Risiken auseinander: mit regelmässigen Meetings (Sprint Planning, Daily SCRUM, Sprint Retrospective) und Sprint ­Reviews. Wir empfehlen, Chancen und Risiken so zu akzentuieren, dass der Product Owner eigene Chancen- und Risiko-Backlogs führt und bewertet. Die entsprechenden Backlog Items können als Anforde-rung in die Sprint-Planung einfliessen. Daraus ergibt sich der Vorteil, dass der Umgang mit Chancen und Risiken selbstverständlich und na-türlich in die operative Projektabwicklung integriert wird. Auch Hin-dernisse (Impediments) werden so aufgedeckt und zeitnah gelöst. Un-terstützt wird dieser Prozess durch den SCRUM Master in seiner zent-ralen Rolle als Lösungsfinder und Hürdenbeseitiger.

 

Das Qualitätsmanagement in der agilen Projektabwicklung ist ähn-lich gelagert (vgl. Tabelle 2): Qualität soll laufend geliefert werden. Quali-tätssicherung und allfällige Korrekturen erfolgen in jeder Iteration. Beur-teilt wird die Qualität über vorgängig definierte Akzeptanzkriterien zu den User Stories. Das Erfüllen der Kriterien erzeugt einerseits Business-nutzen und sorgt andererseits für das Erreichen der geforderten Qualität.

 

Unserer Ansicht nach stellen agile Vorgehensweisen gute Mittel zur Verfügung, um Chancen, Risiken und Qualität häufiger, transpa-renter und auf mehrere Rollen verteilt anzugehen. Gute Erfahrungen haben wir mit der empfohlenen expliziten Adressierung dieser The-men gemacht.

Controlling und Reporting
In klassisch geführten Projekten etabliert sich vermehrt das Control-ling anhand der QUARZ-Dimensionen (Q = Qualität, U = Umfang bzw. Scope, A = Aufwand bzw. Kosten, R = Risiken, Z = Zeit). Diese Dimensi-onen sind in agilen Projekten ebenfalls vorhanden, werden jedoch implizit behandelt:

 

  • Qualität: Qualitätsanforderungen sind Teil der Akzeptanzkriterien. Die Realisierung und Akzeptanz einer User Story in einem Sprint be-inhaltet somit neben dem Businessnutzen immer auch die Qualität.
  • Scope: Lieferumfang und Scope eines Projekts werden durch das Backlog Management bestimmt und im Sprint Review geprüft – vielfach in Kombination mit dem Kostencontrolling.
  • Kosten: Tendenziell sind die Projektkosten eher fix, dafür wird der Scope verändert.
  • Risiken: Chancen und Risiken finden sich in eigenen Backlogs wie-der und fliessen automatisch in die Sprint-Planung ein.
  • Zeit: Die Sprints sind terminfixiert. Terminabweichungen in Pro-jekten ergeben sich nur über die Durchführung zusätzlicher Sprints.

 

Wegen der Tendenz, die Kosten zu fixieren und den Scope vari- abel zu gestalten, reduziert sich das Controlling in agilen Projekten vielfach auf das Abarbeiten des Product Backlogs und die notwendige Anzahl Sprints. Durch eine adäquate Anwendung agiler Projektvorge-hen erfolgt das Controlling innerhalb der einzelnen Sprints quasi in Echtzeit, wodurch sich Transparenz und Reaktionsgeschwindigkeit erhöhen. Schwächen orten wir hingegen beim sprintübergreifenden, auf das gesamte Projekt bezogenen Controlling. Da auch in agil durch-geführten Projekten Investitionen getätigt werden, darf das projekt-bezogene Controlling nicht vernachlässigt werden. Wir empfehlen einen scharfen Blick auf alle QUARZ-Dimensionen, also auch auf die Kosten-Scope-Kombination.

 

Unter Berücksichtigung folgender Anwendungsbedingungen konnten wir für das Controlling und Reporting in agilen Projekten mit der Earned-Value-Methode sehr gute Erfahrungen machen:

 

  • Wir kommunizieren mit Grafiken, aus denen sich Trends ableiten lassen.
  • Die Planned-Value-Kurve wird als Gerade über die gesamte Anzahl oder einen Teil der geplanten Sprints ausgelegt. Sie repräsentiert die Summe aller Tasks, die zur Erfüllung der Backlog Items im jeweili-gen Sprint notwendig sind.
  • Zur Bestimmung der Earned-Value-Kurve berücksichtigen wir nur abgeschlossene Tasks (0/100-Ansatz) aus der Sprint-Planung.
  • Für die Budget-Burned-Kurve verwenden wir den kumulierten Ist-Aufwand, den das SCRUM-Team pro Woche leistet.
  • Damit alle Werte miteinander vergleichbar sind, stellen wir sie rela-tiv in Prozenten dar.
  • Die Earned-Value- und Budget-Burned-Kurve werden sprint-über-greifend gezeichnet und sind damit mit der Planned-Value-Geraden vergleichbar.

 

Abb. 2 illustriert dieses Vorgehen. Die so adaptierten Earned-Value-Methoden ergeben ein wirksames, sprint-übergreifendes Pro-jektcontrolling und sind einfach in ein Projektreporting zu integrie-ren. Das Ergebnis ist ein aussagekräftiger Überblick über Projektfort-schritt (Scope), Projektkosten und Trend pro Dimension. Die restli-chen QUARZ-Dimensionen hängen direkt mit Scope und Kosten zu-sammen und komplettieren das Projektcontrolling.

 

Hinweis: Um den Brückenschlag zu den wahren «Agilisten» zu erleichtern, verzichten wir meist auf die Earned-Value-Nomenklatur, beschriften die Kurven zum Beispiel mit «Plan-Fortschritt», «Ist-Fort-schritt» und «Ist-Aufwand» und benennen die Grafik «Projekt-Burn-down-Chart».

 

Fazit
Obige Beispiele zeigen, wie wertvoll klassische Methoden/Werkzeuge in agilen Projektvorgehen sind und dass sie sich gut integrieren las-sen. Unserer Erfahrung nach sind adäquat ausgeführte Projektma-nagementdisziplinen trotz oder gerade wegen der Agilität ein eigent-licher Erfolgsfaktor. Organisationen wie die International Project Management Association (IPMA) oder das Informatiksteuerungsor-gan des Bundes (ISB) haben agile Vorgehensweisen denn auch in ihre aktuellen Projektmanagementstandards integriert.

 

Wir wissen, wie sich die teilweise fast dogmatisch getrenn-ten Welten klassischer und agiler Vorgehensweisen gewinnbrin-gend kombinieren lassen. Nutzen Sie unsere Erfahrung zu Ihrem Vorteil.

 

 

 

(Visited 528 times, 1 visits today)

Weitere Artikel zum Thema