Mission Impossible - Verbindung von Traditionellem und Agilem Projektmanagement?!

Immer öfters beobachte ich in Unternehmen jene Situation, dass agil geplante und gesteuerte Projekte bzw. Subprojekte (z.B. in der Methode Scrum) in traditionelle Projekte oder Programme (in der Methode  IPMA oder PMI), eingebettet werden müssen.

Die Schwierigkeit in diesen Vorhaben besteht in erster Linie darin, dass in der agilen Methode durch das iterative Vorgehen keine oder nur schwierig zu definierende Vorhersagen für den Leistungs-, Zeit- und Kostenrahmen zu treffen sind, während die traditionelle Methode von einer quasi-konkreten Vorgabe in Leistung, Terminen und Kosten ausgeht (Gloger, 2008, S. 60ff.; Pichler, 2008, S. 7ff.)

Mit folgenden Fragen- bzw. Aufgabenstellungen sehen sich die Verantwortlichen derartiger Projekte konfrontiert: 

• Geht das überhaupt? 
• Widerspricht das nicht einerseits den agilen Grundsätzen bzw. andererseits den traditionellen Projektmanagementmethoden? 
• Und wie sind agil geführte Projekte in einem unternehmensweitem Projektportfoliomanagement sinnvoll zu integrieren?

Agiles Release Management mittels Meilensteinsteuerung und Richtwertermittlung

Die Grundlage der nachfolgend beschriebenen Methode ist aus dem Bedürfnis heraus entwickelt worden, agile und traditionelle Planungs- und Steuerungsmethoden in Projekten zu kombinieren. Zusätzlich finden sich darin Erkenntnisse aus den Arbeiten rund um das Thema der Integrierten Kommunikation als Erfolgsfaktor in Projekten wieder (vgl. Brandstätter/Gölzner/Siems, 2008; Brandstätter/Stumpf, 2012).

Bei dem nachfolgend beschriebenen Fallbeispiel handelt es sich um ein abgschlossenes IT-Projekt. Dabei wird ein Projekt zur Entwicklung einer Software für ein Internet-basierendes Personalmanagement System eines Handelsunternehmens der Automobilbranche, beschrieben. Dieses Projekt ist im Kontext eines Change Management Programms eingebunden. Das Gesamtprogramm wird in der Stabsstelle des Unternehmens mit den traditionellen Methoden des Projekt- bzw. Programm Managements nach IPMA (vgl. IPMA, 2009) geplant und zentral gesteuert. 

Das darin eingebettete Projekt der Softwareentwicklung führt die unternehmenseigene IT-Abteilung ebenfalls via traditioneller PM-Methode nach IPMA durch (vgl. IPMA, 2009). Ein Teilprojekt daraus wird gemeinsam mit einem externen Unternehmen durchgeführt. Dieses externe Softwareunternehmen verwendet für Planung und Umsetzung ein agiles Rahmenwerk nach Scrum (vgl. Schwaber/Beedle, 2001).

Die Möglichkeit einer Kombination aus traditionellem Gesamtprojektmanagement und der agilen Vorgehensweise in einem Teilprojekt darin, liegt in zwei Aspekten begründet, der Richtwertermittlung und dem Meilenstein-gesteuerten Release Managment (siehe Abb. 1). 

• In der Ermittlung eines sogenannten Richtwertes werden die komplexen Anforderungen der Portalsoftware im Vorfeld mittels agiler Schätzmethoden qualitativ und anschliessend quantitativ bewertet (Cohn, 2005, S. 25ff.; Gloger, 2008, S. 165ff.; Pichler, 2008, S. 93). 

• Die Planung  und die Einbettung des Teilprojektes in das Gesamtprojektmanagement erfolgt im zweiten Schritt der Methode, nämlich in Form des Meilenstein-gesteuerten Release Managements. Dabei fliessen die Ergebnisse der Vorplanung (Richtwertes) in die Planung und Umsetzung des Release Managements ein. Es werden die Spezifikationen - wir sprechen dabei nur mehr von Product Backlog Items - kategorisiert, mit dem Kunden priorisiert und gemeinsam mit dem Projektmanagement des Gesamtprojektes in einzelnen Releases geplant. Die Releaseplanung findet daher in Relation zur nachfolgenden Release Umsetzung jeweils zeitversetzt statt. Das Gelingen dieses Vorgehensmodells bedingt ein hoch diszipliniertes Zusammenspiel zwischen Software-Entwicklungsteam, Produktverantwortlichem (Product Owner) und Anwender (Kunden). Die Releases werden anschliessend mit dem Software Unternehmen und dem zentralem Projektmanagement gemeinsam in einzelnen Meilensteinen geplant und gesteuert.

Abb. 1 Gesamtdarstellung der Methode des Agiles Release Management mittels Meilensteinsteuerung    

Folgende detaillierte Vorgehensweise liegt dieser Methode nun zugrunde:

1. Ermittlung des Richtwertes 

Die Methode zur Ermittlung des Richtwertes beschreibt jene Vorgehensweise, um ausgehend von einer herkömmlichen Funktionsbeschreibungen (z.B. in Form von Lasten- oder auch Pflichenheften), eine initiale Schätzung zu bekommen die einerseits dem agilen Vorgehen gerecht wird und andererseits dem traditionellen Projektmanagement eine ungefähre Orientierungshilfe gibt (siehe Abb. 2 im Pkt. 1).

• Das Softwareunternehmen erstellt im Vorfeld - entweder als eigenes Teilprojekt oder als Meilenstein im Rahmen des Gesamtprojektes organisiert - gemeinsam mit dem Projektmanagement und den Anwendern des Handelsunternehmen (nachfolgend als Kunden beschrieben) ein initiales Product Backlog. Dieses initiale Product Backlog ist eine Sammlung von User Stories und wird auf Basis eines klassischen Pflichentheftes erstellt. Im anfgeführten Beispiel wird diese Vorgehen in Form eines eigenen Teileprojektes durchgeführt.

• Im Folgenden schätzt nun das Software-Team die relative Größe der Funktionen (User Stories) auf Basis von Story Points, so dass am Ende eine initiale Schätzung des gesamten Software Projekts vorliegt. Das Schätzen kann entweder mit Affinity Estimating erfolgen, weil es am schnellsten und effektivsten ist – ggf. kann aber auch Planning Poker verwendet werden. Das Einbinden des Kunden bei dieser initialen Schätzung bewährt sich, weil dies auf beiden Seiten für ein besseres Verständnis der Funktionen sorgt und viele Missverständnisse schon früh ausgeräumt werden können (vgl. Cohn, 2005; Gloger, 2008; Pichler, 2008).

• Anschliessend stimmt sich das Softwareunternehmen mit dem Kunden zu einer sogenannten Definition of Done (DoD) ab, die insbesondere auch Qualitätskriterien definiert und festlegt, ob die Anwendung beispielsweise mit automatisierten Fachtests und/oder manuell durch ein Testteam geprüft werden soll (vgl. Cohn, 2004).

• Im darauf folgenden Schritt „brechen sie exemplarische Stories in der Bandbreite der möglich unterschiedlichen Schwierigkeitensgrade (Richtwert Stories) auf Tasks (Richtwert Tasks) herunter“ und entwickeln Design Ideen für die Umsetzung. Auf Basis der DoD erstellt das Team (hautpsächlich der Product Owner) eine Expertenschätzung für diese Richtwert Tasks und erhält so in Summe den Personalaufwand für die Richtwert Stories in Personentagen. Dann wird der Aufwand auf Basis der Schätzungen für die weiteren Stories ermittelt. Man  erhält so einen Umrechnungsfaktor von Story Points auf Personentage und umgekehrt (1 Story Point = X Tage Aufwand; 1 Personentag = X Story Points).

• Auf Basis dieser initialen Schätzung des Backlogs in Storypoints und des Umrechnungsfaktors kann nun der Personalaufwand für ein initiales Backlog ermittelt werden. Der Aufwand, multipliziert mit dem durchschnittlichen Tagessatz des Umsetzungsteams, ergibt die geschätzten Entwicklungskosten (diese Methode  kann durchaus auch zur Ermittlung eines Festpreises für agile Projetvorgehen verwendet werden). 

• Wichtig dabei ist folgende Ausssage: A) Diese geschätzten Entwicklungskosten gelten jetzt aber nicht für den Umfang des initialen Backlogs, sondern: B) für die Anzahl der initial berechneten Story Points. D.h. der Kunde kann den mengenmässigen Umfang (in Story Points) des initialen Backlog damit umsetzen, muss es aber nicht. Er kann auch jederzeit Stories austauschen, neue hinzufügen und andere streichen – solange er den Gesamtumfang der Storypoints nicht überschreitet. Aussage A und B lesen sich zwar im ersten Moment als sinngleich, sind aber im Detail unterschiedlich. Diese Art von Definitionen unterstreicht die Philosophie der agilen Bewertungsmethode, indem z.B. grobgranulare Spezifikationen nicht als Basis von feingranularen Kosten verwendet werden sollen. 

• Es gibt natürlich noch andere Varianten zur Ermittlung des agilen Richtwertes. Beispielsweise kann man den Aufwand für Storypoints alleinig durch das Umsetzen einiger weniger Testsprints (2 bis 4) auf Basis von Zeit und Material ermitteln. So kann man den Umrechnungsfaktor sehr präzise empirisch bestimmen und hat auf beiden Seiten höhere Planungssicherheit. I.d.R. arbeiten Dienstleister ohne diese Sicherheit mit einem “Risikoaufschlag” bei der initialen Schätzung, um das Risiko von Mehraufwänden z.B. im Festpreis zu berücksichtigen. 30% Aufschlag sind dafür ein realistischer Erfahrungswert. Dieses Verfahren unterscheidet sich in keiner Weise vom herkömmlichen Schätzverfahren.

• Eine weitere Variante ist die Methode Money for nothing – change for free, die Jeff Sutherland vorgeschlagen hat. Bei dieser Variante kann der Kunde jederzeit sagen, dass er das Projekt beendet, weil die gelieferte Funktionalität ausreichend ist. Die Differenz des Aufwandes wird geteilt, d.h. der Dienstleister erhält die Hälfte des Geldes für den nicht geleisteten Aufwand und der Kunde spart die andere Hälfte ein (vgl. Sutherland, 2008).

2. Planung und Kategorisierung der Release #1 (und nachfolgende)

Der nachfolgende aufgestellte Iterationsplan muss immer mindestens drei Monate im voraus, jedoch mindestens zwei Monate vor dem Release Start mit dem Sprint #1 geplant sein. Die Angabe in Monaten geht immer von einer definierten Sprintlänge von 4 Wochen aus. Bei einer allfälligen Änderungen der Sprintlänge müssten dann auch die Planungszeiträume adaptiert werden. In dieser Phase der Release-Planung und Kategorisierung werden nun gemeinsam mit dem Product Owner des Software Teams (in Abstimmung mit dem Kunden) nur kategorisierte Anforderungen (Backlog Items) in die nachfolgende Release-Planung  aufgenommen (siehe Abb. 2 im Pkt. 2).

3. Grobplanung des Sprints

Die Anforderungen (Backlog Items) müssen mindestens ein Monat vor der jeweiligen Umsetzung (in Form von Sprints) geschätzt werden. Die Grobplanung passiert durch den Product Owner, die Schätzung jedoch immer in Abstimmung mit dem Team innerhalb des  Softwareunternehmens (siehe Abb. 2 im Pkt. 3).

4. Teilangebot, Bestätigung und Start für Releaese #1 und (und nachfolgende)

Die inhaltliche Grobplanung für das Release umfasst:

• die Auswahl der Backlog Items des aktuell geplanten Releases,

• mit ergänzenden Funktionen, die bei eventuell nachfolgenden Realeases durch  Kunden oder Softwareunternehmen identifiziert wurden,

• der jeweilige Aufwand, der auf der initialen Schätzung basiert.

Diese inhaltliche Grobplanung des Release wird vom Softwareunternehmen entweder direkt an den Kunden (wird empfohlen) oder über das zentrale Projektmanagement in Form eines Teilangebotes (jeweils spätestens ein Monat vor Umsetzung eines Releases an den Kunden) gelegt. Sie muss für eine zeitgerechte Umsetzung eines Releases, bis spätestens zum 15. des jeweiligen Monats vom Kunden bestätigt sein (siehe Abb. 2 im Pkt. 4). Änderungen werden in jedem Fall vom Product Owner des Softwareunternehmens dem zentralen Projektmanagement in Form eines Change Requests (einer Änderung im Leistungsumfang) gemeldet. 

Die Umsetzung und Abnahme der jeweiligen Sprints wird im jeweiligen Entwicklungszyklus nach der Methode Scrum durchgeführt. Das diesbezügliche Prozedere wird daher hier in diesem Artikel nicht explizit beschrieben. Die darin erforderlichen Sprint Reviews und Retrospectives werden sofort im Anschluss an das Sprintende, jeweils gemeinsam mit dem Team, Product Owner und dem Kunden durchgeführt. Ist es dem Kunden terminlich nicht möglich, die Funktionen im Sprint Review zeitnah abzunehmen, dann muss dies, ohne einen Verzug zu erreichen, bis spätestens ein Monat nach Abschluss des Sprints  durchgeführt werden. 

Wichtig: Mögliche Änderungen im Sprintergebnis (z.B. unvollständig umgesetzte User Stories) werden dem zentralen Projektmanagement nach dem Sprint Review gemeldet. Ebenso werden auftretende Probleme innerhalb der Sprints (z.B. Abbruch eines Sprints, Anhäufung ungelöster Probleme) durch den Product Owner an das zentrale Projektmanagement sofort berichtet. Bewährt hat sich die Risikoprävention in Form eines wöchentlichen Reports via  Burn-Down-Chart vom aktuellen Relaese durch den Product Owner des Scrum Projektes an das zentrale Projektmanagement.

5. Releasetest und –abnahme

Der finale Test und die Abnahme des gesamten Release passiert gemeinsam mit dem Team, Product Owner und Kunden und schliesst als letzten Meilenstein den aktuellen Release ab (siehe Abb. 2 im Pkt. 5).

Abb. 2 Vorgehensmodell des Meilenstein-gesteuerten Agilen Release Managements und Richtwertermittlung im Vorfeld

Weiterführende Literatur

Brandstätter, M., Gölzner, H., Siems, F . (2008): Anspruchsgruppen-orientierte Kommunikation, Neue Ansätze zu Kunden-, Mitarbeiter- und Unternehmenskommunikation, Hrsg.,: Siems, F., Brandstätter, M., Gölzner, H., Siems, F. Gabler, Wiesbaden.

Brandstätter, M., Stumpf, M. (2012): Nachhaltigkeit im Projektmanagement – Bedeutung der Integrierten Kommunikation in der Innen- und Außendarstellung von Projekten. In: Umwelt-, 

Wirtschaftsforum, Heft 3-4/2012, S. 217-221. Springer, Heidelberg.

Cohn, M. (2004): User Stories Applied. For Agile Software Development, Addison-Wesley, Boston.

Cohn, M. (2005): Agile Estimating an Planning, Prentice Hall, New York.

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, Hanser, München.

IPMA  (2009): IPMA Competence Baseline Version 3.0. http://www.p-m-a.at/ICB-pm-baseline-und-pm-basic-syllabus/View-category.html. (Abfrage: 10.08.2012).

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, DPunkt, Heidelberg.

Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, Prentice Hall, New York.

Sutherland, J. (2008): http://scrum.jeffsutherland.com/2008/08/agile-2008-money-for-nothing.html (Abfrage: 10.08.2012).

Sterrer, C; Winkler, G. (2009): Setting Milestones, Projektmanagement, Methoden-Prozesse-Hilfsmittel, Goldegg-Verlag, Wien.