SCRUM im Vergleich zum PmBok Guide
Dieser Artikel wurde 2017 geschrieben und jetzt auf diese Website übertragen. PMI bietet inzwischen eine eigene agile Zertifizierung an, die einerseits eine anspruchsvollere Prüfung beinhaltet, andererseits ein weit aus breiter angelegtes Fundament an Werkzeugen und Methoden anbietet. Insbesondere der neue PmBok Guide 7, wird diesen Anspruch noch bedeutsamer untermauern.
Zu dem Artikel ist anzumerken, dass SCRUM nicht mehr das SCRUM ist, sondern inzwischen in diversen Varianten auftritt.
Das Product Backlog
Im klassischen Projektmanagement unterscheidet man zwischen Lastenheft und Pflichtenheft (Statement of work, Statement of Scope). Es existieren noch andere Namen für diese Dokumente, wichtig ist aber die Aufteilung in zwei Dokumente.
Das Lastenheft ist bei Kundenprojekten Teil der Ausschreibung. Potenzielle Auftragnehmer können auf dieser Basis ein Angebot erstellen. Die Erstellung eines Lastenthefts stellt heutzutage eine Kernkompetenz und extrem wichtige Vorraussetzng für den Erfolg eines Projekts dar.
Das Pflichtenheft, wird vom Auftragnehmer auf Basis des Lastenheftes erstellt. Das Lastenheft regelt das „Was“, das Pflichtenheft regelt das “Wie“.
In den Dokumentationen zu Scrum, konnte ich diese Zweiteilung nicht finden. Das Product Backlog vereint beide Dokumente. Da das Product Backlog aus Items besteht, die meistens anfangs aus User Stories und manchmal als Use Cases dargestellt werden, scheint dies auch sinnvoll zu sein, da das Lastenheft zu Beginn auch eher User Story bezogen startet und erst im Rahmen einer Anforderungsanalyse –falls nötig – in Use Cases umgewandelt wird.
Bei Scrum, bleiben die Items auch während der Durchführung des Projekts bestehen, wobei funktionale Anforderungen dann im Rahmen der Sprints in Use Cases umgewandelt werden. Hier geht es jetzt auch um das „Wie“, also ähnlich wie das Pflichtenheft, nur eben agiler. Hierfür trägt das Team die Verantwortung. Diese Systematik spiegelt auch das Sprint Planning und der Sprint Review wieder. Im Planning wird das „Was“ dokumentiert, im Sprint Review das „Wie“, um es zukünftig zu verbessern. In Scrum geht es ja primär um Empirie, d.h. das Erfahrungswissen aus den vorhergehenden Sprints fließt in die zukünftigen Sprints mit ein.
Die Vorgehensweise im Rahmen von Ausschreibungen von Scrum Projekten, ließ sich nicht wirklich eruieren. In Diskussionsforen wird das Thema ebenfalls kritisch und mit unterschiedlichsten Vorschlägen diskutiert. Aus meiner Sicht als klassischer Projektmanagementtrainer kann ich nur konstatieren: Umso weniger bewertbare Anforderungen am Anfang stehen, desto mehr Kostenrisiken enstehen im Projektlebenszyklus. Daran ändert auch Scrum nichts. Die Frage ist nur, ob die Kosten für den Kunden am Ende mit seiner Kostenvorstellung konform gehen oder nicht?
Kritische Bewertung
Die Reduzierung der Dokumente ist sicherlich ein Vorteil, wenn ein späteres Handling der Software aus fachlicher Sicht nicht zum Problem wird. Scrum dokumentiert im Rahmen der Tests, was aber dem User aus fachlicher Sicht wenig nutzt. Wenn man das Change-Management vom PmBok Guide mit Scrum vergleicht, ist nicht nur das Dokumentenaufkommen weit geringer, auch der Prozess des Änderungsmanagement schlanker.
Die Verfahrensweise mit dem Backlog wirft zumindest juristisch einige Fragen auf. Da scheinbar eine konkrete Anforderungsanalyse nicht vorgenommen wird und darauf basierend auch kein Eintrag in ein Lastenheft erfolgt, entsteht die Frage: Zu welcher vertraglichen Basis kommt es dann?
In den folgenden beiden Blogs können vertragliche Fragestellungen juristischer Art nachgelesen werden:
Was die Aktualisierung des Backlogs angeht, scheint es sich in der Praxis nicht so einfach darzustellen, wie es in den Scrum Vorschriften beschrieben wird.
Nebenbei bemerkt: Man kann zweierlei Blogs zum Thema Scrum unterscheiden. Zum einen Blogs, die Scrum als das „Wundermittel“ für agile Projekte glorifizieren, zum anderen Blogs, die aufgrund von Erfahrungen Scrum kritisch betrachten, aber selten als überflüssig oder nicht praktizierbar. So wird gerade auch häufig von der Problematik gesprochen, Backlogs aktuell zu halten. Priorisierungen sollen häufig ein Problem darstellen oder auch nicht „done“ gesetzte Use Cases, stapeln sich zu einem Problem.
Der PmBok Guide
Der PmBok Guide kennt das „Lastenheft und Pflichtenheft (Statement of work, Statement of Scope)“. Der Zweck dieser Dokumente wurde weiter oben schon beschrieben. Auf Seite 425 im PmBok 5th (englische Version, in der deutschen Version wurde „initial“ vergessen) findet man auch eine „initiale Beschreibung des Inhalts- und Umfangs“. Also durchaus vergleichbar mit einem anfänglichen Backlog. Auf Basis dieser initialen Beschreibung des Inhalts- und Umfangs sowie des Projektauftrags, entwickelt der Projektleiter mit dem Projektteam den Projektmanagementplan PMP (Seite 78, PmBok 5th).
Ein Projektmanagementplan PMP ist aber eine Dokumentensammlung, die nicht jedes Mal neu erfunden wird. Projekte, die in ähnlicher Form immer wieder durchgeführt werden, basieren auf einer Art PMP-Template (Assets). Diese Dokumentensammlung wird im Rahmen neuer Projekte nur im Rahmen der variablen Daten (Qualitätsanforderungen, Kosten-, Termin- und Scope Basispläne etc.) ergänzt oder erneuert. Prozessverbesserungen werden falls notwendig, ebenfalls vorgenommen. Also auch bei PMI spielt Empirie ebenfalls eine sehr wichtige Rolle. Für jede Arte von Lessons Learned und Assets existiert der Prozess „Phase oder Projekt“ abschließen. Die Tätigkeiten sind durchaus mit den weiter unten aufgeführten Sprint Review und Retrospektive vergleichbar.
Des Weiteren wird „Konfigurationsmanagement“ (PmBok 5th, Seite 96) benutzt, um den technischen Fortschritt, Änderungen und eine Rückverfolgbarkeit (Tracebility) von Anforderungen und deren Änderungen zu gewährleisten. Ich halte dies auch für komplexe Projekte, die als Endprodukt aus diversen interdisziplinären Technologien bestehen, für sehr sinnvoll. In überschaubaren Softwareprojekten mag ein Backlog ausreichen, in technisch interdisziplinären Projekten auf keinen Fall.
Der Sprint
Als Eingangsdokument dient das Product Backlog. Daraus wird das Sprint Backlog abgeleitet, das am Ende ein „Increment of Potentially Shippable Functionality“ liefern soll. Das Team bestimmt, wie viele funktionale Aktivitäten in einem Sprint enthalten sind. Das Team darf nicht überstimmt werden.
Kritische Bewertung
Die Festlegung auf 8 Stunden Planung in Form einer „Time Box“ für einen 4 aber auch 2-wöchigen Sprint scheint mir sehr wenig. Immerhin sind das bei 5 Entwicklern rund 175 Personenstunden. Allerdings wird von den Agilisten angeführt, dass viele Planungselemente durch das Team im Sprint erledigt werden – also agil.
Bohrt man aber etwas weiter, stellt man fest, dass vieles unter den Tisch fällt. Zum Beispiel wird Risikomanagement im Prinzip überhaupt nicht geplant. Hier geht man auch agil vor. D.h. dann wohl, dass Risiken erst eintreten müssen, bis die Agilität greift.
Um Kosten und Stress zu vermeiden, ist es aber immer gut, einen Plan B in der Tasche zu haben. Ich glaube, in privaten Projekten, sei es eine Reise, ein Hausbau oder auch eine Firmengründung oder andere Projekte in denen das eigene Kapital verlustig geht, würde kein Mensch agiles Risikomanagement betreiben.
Schon allein eine Risikobeurteilung in einer Gruppe, erzeugt einen „Risky Shift“, der nicht entstehen würde, wenn ein Einzelner ein Risiko bewerten müsste. Als externer Auftraggeber würde ich sehr kritisch über eine Projektdurchführung denken, die nicht versucht, potenzielle Risiken zu identifizieren und sich antizipierend auf Bewältigungsmaßnahmen einstellen würde.
Die Frage ist auch, wer sich für Risikoidentifikation zuständig fühlt. Keine Rolle unter Scrum, ist da eindeutig identifizierbar.
Der PmBok Guide
Ein Sprint Planning Meeting kann man mit der Initiierungsprozessgruppe einer Phase oder eines Projekts vergleichen. Jede Phase muss initiiert werden. Ob eine Phase 2 Wochen, 4 Wochen oder 5 Monate dauert, wird nicht festgelegt. Die Entscheidung liegt beim Projektmanager. Er kann aufgrund undurchsichtiger Anforderungen ähnlich kurze Phasen planen, wie das mit Sprints in Scrum möglich ist. Bezogen auf das Earned Value Management werden ähnliche Intervalle empfohlen.
Das Inkrement
Ein Inkrement ist das Ergebnis eines oder mehrerer vorab durchgeführter Sprints. Es muss die im Backlog formulierten Items erfüllen. Ob das der Fall ist, prüft der PO. Danach gilt es als „Done“.
Kritische Bewertung
In dem Blog „Grundidee: Entwickeln in Inkrementen“, findet sich folgendes Zitat:
„Worin sich Scrum von diversen anderen Vorgehensmodellen unterscheidet, ist die Tatsache, dass nicht nur Meilensteine in der Entwicklung gesetzt werden, sondern dass die Qualität eines Meilensteins (Increment) jeweils so definiert ist, dass vom Auftraggeber (Product Owner) immer erwartet werden darf, dass das in der abgeschlossenen Iteration (Sprint) fertiggestellte Stück Funktionalität in sich abgeschlossen und produktiv einsetzbar ist.“
Das o.g. „Done“ ist Kriterium für die Ergebnisorientierung. Eine Aufstellung der „Done“ Kriterien können Sie hier nachlesen. Im 1.Teil implizierte ich, dass gerade auch diese „Ergebnisorientierung“, ein Merkmal militärischer Kriegsführung ist. „Geländegewinne, Verlust feindlicher Ressourcen, Verteidigung eines strategisch wichtigen Ortes…alles stark Ergebnisorientiert“.
PmBok Guide
Inkremente entsprechen im PmBok Guide einem Liefergegenstand (Deliverable). Wobei der Begriff Liefergegenstand keinen Anspruch darauf erhebt, eine Aussage über die Quantität oder dem Zeitansatz zur Erzeugung des Liefergegenstands zu machen. Ein Dokument mit 10 Zeilen kann ein Liefergegenstand sein, ein Marketingkonzept als auch eine Turbine kann ein Liefergegenstand sein.
Auch das „Done“ aus Scrum, ist zu matchen. Der Prozess „Inhalt und Umfang validieren“ trägt dem „Done“ Rechnung. Dazu kommt der Prozess „Qualität lenken“, der dem Prozess „Inhalt und Umfang validieren“ vorgelagert ist. Das Wissensgebiet „Qualitätsmanagement“ verweist ausdrücklich auf Seite 231 auf die antizipierende Reduktion von Qualitätskosten über die Planung der Qualität. Eine wichtige Strategie modernen Qualitätsmanagements, sieht der PmBok Guide in der antizipierenden Qualitätslenkung: „Qualität wird hineingeplant und nicht hineingeprüft!“ Was natürlich nicht bedeutet, dass 0-Fehler-Qualität ausschließlich über Antizipation erreicht werden kann.
Storypoints
Wenn ich die Kommentare in einigen Blogs richtig verstanden habe, dann geht es bei den „Story Points“ primär um Psychologie. Man will nicht über „Echtzeiten“ sprechen oder pokern, sondern mit abstrakten Punktesystemen jonglieren, die dazu noch über schwer verständliche Fibonacci Formeln gewichtet werden. Anforderungen werden also nicht in Aufwänden erfasst, sondern „bepunktet“ mit der entsprechenden Gewichtung. Auch ist man der Meinung, dass aufgrund eines vergangenen Sprints und seiner „IST-Story Points“ der nächste Sprint entsprechend geschätzt oder hochgerechnet werden kann (Velocity). Auch wenn Sprints nur max. 4 Wochen dauern, dann kann sich der Scope erheblich von den Anforderungen unterscheiden, so dass die durchschnittlichen Punkte des Vorläufers nicht äquivalent zum nachfolgenden Sprint benutzt werden können. Umso mehr Sprints als Vorlage für eine durchschnittliche Punktzahl zur Verfügung stehen, desto signifikanter wird die Prognose sicherlich. Da auch hier Mittelwerte über die vorhergehenden Sprints genutzt werden, dürfte es auf der Hand liegen, dass die Hälfte der Werte unter dem Mittelwert liegen und die zweite Hälfte über dem Mittelwert liegen. Von daher wird der nachfolgende Sprint häufig dann entweder zu hoch oder zu niedrig bewertet.
Da sehe ich die empirischen Methoden des PmBok Guides als realistischer an. Hier baut man eine Historie über viele ähnliche Projekte der Vergangenheit auf und nutzt diese Daten in Verbindung mit statistischen Verteilungen oder Formparametern, um Vorhersagen über Aufwände für ein ähnliches Projekt vorzunehmen. Viele Projekte unterliegen beispielsweise einer PERT Verteilung.
Im Earned Value Management verfährt man genau umgekehrt. Man bewertet Anforderungen monetär, um Abstraktes von vornherein zu vermeiden, um der menschlichen Vorstellungskraft aufgrund eines „Geldwertes“, ein deutliches Bild zur Verfügung zu stellen, mit dem dann nicht nur ein „Wert“ erfasst wird, sondern auch ein Gefühl vermittelt wird. Wenn ich am Ende einer Phase (Ende eines Sprints) im Statusbericht lesen kann, dass wir im Projekt bis dato einen Wert (EV) von 80.000€ erzeugt haben und dies dem Planwert 95.000€ gegenüberstellen, kann man seine Minderleistung irgendwie besser erfassen und fühlen. Auch kann man die Ursachen, die zu der Minderleistung geführt haben, besser in Relation zu der fehlenden Wertschöpfung setzen. Eine nicht erbrachte Mitwirkungspflicht des Kunden, kann ich beispielsweise monetär ziemlich genau bewerten und damit zur Ursachenanalyse und Dokumentation beitragen. Abstrakte „Story Points“, die dann erst einmal umgerechnet werden müssen, helfen da nur sehr umständlich weiter.
Ganz abgesehen vom Nachforderungsmanagement (Claim Management). Auch in deutschen Großprojekten ein „großes“ Thema. Für einen externen Kunden gehört sehr viel Vertrauen dazu, den endgültigen „Kaufpreis“ für den Projektliefergenstand auf Basis von „Story Points“ zu akzeptieren. Schon allein im Rahmen einer Ausschreibung hat ein Auftraggeber kaum Vergleichsmöglichkeiten, wenn die Anforderung an eine Produkt nicht über bewertete Manpower kenntlich gemacht wird.
Der Burndown Chart
Der Burndown Chart definiert auf der X-Achse den Aufwand, auf der Y-Achse die Dauer in Tagen und bezieht sich immer auf einen Sprint. Der Aufwand „brennt oder schmilzt“ in Richtung Sprintende herunter. Das Gute daran ist, dass das Team sich regelmäßig Gedanken darüber machen muss, welcher Scope noch durch wieviel Aufwand erledigt werden muss. Diese Vorgehensweise ist besser geeignet, als einen prozentualen Fertigstellungsgrad zu melden. Daraus entsteht meist das 90% – 10% Fertig Syndrom.
Allerdings wird dieses Prinzip (Burn down) auch im klassischen Projektmanagement angewendet, falls man es richtig macht. Wenn man es richtig macht, dann muss eine Ressource in kurzen Abständen nicht nur den Fertigstellungsgrad melden, sondern auch eine Restwertschätzung für den verbleibenden Aufwand abgeben. Wenn dies über MS Project reported wird, errechnet MS-Project den Restaufwand für das Projekt automatisch. Lesen Sie dazu meinen Artikel „Earned Value Management – Methode mit sieben Siegeln?“
Die Königsdisziplin wäre dann bspw. der Einsatz der „Fixed Formula“ in Verbindung mit dem Earned Value Management (EVM).
Der Vorteil gegenüber der Scrum Methode liegt insbesondere darin, dass mit EVM von vornherein Aufwände mit Kosten assoziiert werden. Man muss also nicht auf Basis abstrakter erarbeiteter „Story Points“ den verbleibenden Aufwand berechnen.
Fazit
In vielen Blogs zu Scrum gewinnt man den Eindruck, die Vertreter diese Rahmenwerks wurden erst mit der Einführung Scrums geboren. Was vorher war oder rechts und links von Scrum existiert, ist meist nicht präsent oder unbeachtet.
Ich persönlich empfinde das, was über Scrum vermittelt wird, meistens als „einfach gestrickt“, die Story Points als zu umständlich und abstract. Allerdings mit Ausnahmen auch durchaus für das „normale Projektmanagement“ brauchbar.
Das Scrum als Framework einfach ist, ist auch allgemeiner Tenor. Als schwierig wird die Umsetzung in der Praxis gewertet. Ich denke, hier wird noch mehr Disziplin gefordert als im klassischen PM.
Projektmanagement ist in der Realität komplex und kompliziert, besonders wenn es um „nicht triviale Prozesse„ geht. Man kann Komplexität nicht einfach reduzieren auf einige „wichtige Parameter“ und den Rest agil aus dem Ärmel schütteln.
Ich prognostiziere, dass das Framework Scrum in wenigen Jahren durch erhebliche Werkzeuge und Methoden des klassischen Projektmanagements ergänzt wird. Aber auch dann wird es „Gurus“ geben, die das Ganze als etwas vollkommen Neues verkaufen werden.
Tip: Neben der PMP Zertifizierung bietet PMI jetzt auch eine Zertifizierung für agiles Projektmanagement.
Aktualisierung in 2021: Inzwischen haben sich sogenannte SCRUMBUTS etabliert, die aus dem klassischen Projektmanagement entlehnt werden.