Blog | Agiles PM

Scrum Zertifizierung = Silver Bullet oder Bauernfängerei zu honorigen Honoraren? (Teil 2)

Lesen Sie auch Teil 1

Ergebnisorientierung in Scrum: Scrum Artefakte

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.Scrum impossible

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?

Ich könnte mir als vertragliche Basis einen amerikanischen Vertragstyp vorstellen, der auf Basis des „Point of total Assumptions“ beruht.
Letztlich führt es in vielen Fällen wiederum dazu, von Anfang an bewertbare „Use Cases“ zu entwickeln um vor dem Hintergrund eines Festpreises den Auftrag zu erhalten.
Das Product Backlog unterliegt der Verantwortung des PO.
Am Anfang noch rudimentär mit Items gefüllt, im Verlauf des Projekts immer komplexer. Umso weiter unten eine User Story steht, desto weniger Details sind erkennbar und umgekehrt.
 
Das Backlog muss während der Sprints aktuell gehalten werden. Auch alle Änderungen werden hier dokumentiert.
Eine der wichtigsten Intentionen des Product Backlogs ist die Ergebnisorientierung. Es wird wenig dokumentiert (Beispiel siehe oben: Änderungen), wenig geplant (das erledigt sich im Rahmen der Kommunikation im Team unter der Prämisse der Items) und nur so viele Items für einen Sprint eingetragen, wie notwendig sind, um ein Inkrement fertig zu stellen.

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:

http://swd-rechtsanwaelte.de/blog/informationtechnologie/agile-softwareprojekte-in-der-vertragsgestaltung/

http://www.kanzlei.de/rechtsgebiete/it-recht/agile-softwareentwicklung-und-scrum-vertragsrechtliche-besonderheiten

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

Ein Sprint sollte nie länger als 4 Wochen dauern. Eingeleitet wird der Sprint durch ein „Sprint Planning Meeting“.
Das Sprint Planning Meeting dauert insgesamt 8 Stunden. Man spricht hier von einer „Time Box“. Auch der Sprint selbst ist eine Time Box, meistens 4 Wochen lang oder kürzer.
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-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 Risikomanagement wird 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 Risiken nicht versucht zu identifizieren und sich potenziell 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. 

 

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.“

Des Weiteren wird ein Zyklus aufgezeigt, der aus den drei Elementen "Apply-Inspect-Adapt" besteht. Apply beginnt mit dem Startelement „Endlich mal anfangen, etwas zu entwickeln“.
Projiziert man diesen Zyklus auf das im Blog enthaltene kulinarische Beispiel, könnte man analog sagen: „Hinsetzen und essen.“
Das ein gutes Gericht auch eine fundierte Vorbereitung und Planung resultiert, scheint nicht im Manifest vieler Agilisten zu erscheinen.
 
Ganz davon abgesehen, dass der o.g. Zyklus ziemlich genau dem 50 Jahre alten Zyklus Plan-Do-Check-Act von Edward Deming entspricht, mit der Ausnahme, das „PLAN“ fehlt.
Darüber hinaus grenzt der Blog Scrum von anderen Vorgehensmodellen ab, indem er es als Vorteil wertet, das mit dem „Done“ eines Inkrements auch die qualitativen Anforderungen des PO abgehakt sind.
In dem o.g. Zyklus werden Fehler oder Mängel erst durch Prüfung im Element „Inspect“ identifiziert. Und sicherlich treten Fehler auf, die auch erst durch Prüfung identifiziert werden können. Trotzdem wird den modernen Qualitätsmethoden hier überhaupt nicht Rechnung getragen:
„Qualität wird hineingeplant und nicht hineingeprüft!“ Darauf wird gleich näher eingegangen.

 

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

Für mich als begeisterter „Earned Value Management Trainer“ ist die Verwendung der Story Points sehr verwunderlich.

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 der Scope von den Anforderungen erheblich 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. 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. (Zu dem Thema finden Sie demnächst einen Artikel auf dieser Website)

 

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.

 

Renee Ossowski, PMP

Geben Sie uns Ihr Feedback! Bitte melden Sie sich an, um einen Kommentar zu posten!