PmBok Guide oder SCRUM? Im Teil 3 lautete der Titel „PmBok Guide contra SCRUM“! Das ist natürlich Nonsens. Wenn ich provoziere, dann nur weil so manche „agilen Götter“ meinen, man könnte das prognostizierende Projektmanagement (pPm) durch agiles PM ersetzen. Und nicht nur das, durch die Hintertür werden sogenannte SCRUMBUTS eingeschleust, die zur Masse aus dem pPm entlehnt und diskret dem agilen PM zugeordnet werden.
In welchen Projekten Sie agile oder prognostizierende Methoden verwenden, entscheidet sich über die Komplexität, Kompliziertheit und Neuheit eines Projekts. Der PmBok Guide 6 und ebenfalls der PmBok Guide 7 im Bundle mit der PMIstandards+; hilft Ihnen und den Teilnehmern der PMP Zertifizierung, eines von beiden oder beides hybrid anzuwenden. Die Zukunft liegt in den hybriden Entwicklungsansätzen.
Die „Rootagiles“, agiles Projektmanagement außerhalb des PmBok Guides, eignen sich dazu nicht. Sie hinken nur auf einem Bein, dazu noch ohne Krücke oder passende Werkzeuge. Auch die Trainer des agilen Projektmanagements, werden es im Vergleich zu den PMP Trainern schwer haben, 2000 DIN A4 Seiten PmBok Guide Body of Knowledge, in Ihren Seminaren kausal einzubringen. Da gilt wieder die Bauernweisheit, „Wer PmBok Guide kann, kann sehr schnell agil. Wer nur ein Framework kann, hat einen langen Weg vor sich, PmBok Guide zu können!“.
Bevor Sie weiter lesen, lesen Sie die Teil1, Teil 2 und Teil 3.
PmBok Guide oder SCRUM: Ken und Jeff lassen sich inspirieren!
Ich stell mir das immer so vor: Ken und Jeff saßen am Samstagabend bei einer guten Flasche Wein zusammen und studierten den PmBok Guide.
„Ja Ken, jetzt haben wir ja das Kommunikationsmanagement sehr schön komprimiert. „Transparenz“ sagt eigentlich alles aus. Alles andere ist genau genommen Overhead. Sollte man das eine oder andere benötigen, holt man es sich als SCRUMBUT rein.“
„Genau Jeff. Schließlich ist das Wochenende kurz. Da muss ein Manifest reichen! Aber mal was anderes. Ich habe gestern im Qualitätsmanagement des PmBoks etwas über „Inspection“ gelesen. Die Inspection wird im PmBok Guide als reaktive Maßnahme beschrieben. Wir könnten die Inspektion ans Ende jeden Sprints setzen. Ähnlich wie im PmBok Guide die Abschlussprozessgruppe am Ende jeder Phase stattfindet.“
„Korrekt. PMI schlägt auch vor, den Kunden im Rahmen jeder Verifizierung der Anforderungen den Kunden zu beteiligen. Was allerdings in der Praxis kein Mensch macht. Man hält sich die Kunden vom Leib. Das müssen wir stringent in unser Manifest einarbeiten und drauf drängen, dass der Kunde anwesend ist.“
„Aber wenn der Kunde nicht kommt oder nicht will?“
„Hmm, Ok, dann müssen wir eine Art „Kunderolle“ definieren, ähnlich PRINCE2, da gibt es die Usergroup. Ob da wirklich der Kunde erscheint, sei dahin gestellt!“
„Richtig Jeff, wir brauchen jemanden, der sich aus Kundensicht für das Produkt verantwortlich fühlt. Was hälst Du von einem „Product owner“?“ Der SCRUM Master ist die Mutter der Kompanie, der Producht Owner der Kompanie Chef!“
„Super Ken, der Begriff geht richtig ins Ohr! Aber meinst Du, jemand der nicht wirklich der Kunde ist, vertritt wirklich die Interessen des Kunden? Nehmen wir mal an, da ist richtig was in die Hose gegangen. Der PO ist Teil des Projektauftragnehmers. Er, der SCRUM Master und das Team kennen sich seit Jahren. Meinst Du er vertritt zu 100% den Kunden, auch wenn es richtig Geld kostet, oder ein Teammitglied zum zweiten oder dritten Mal richtig Mist baut.“
„Offenheit und Ehrlichkeit sind unsere stärksten Treiber im agilen PM!“
„Ken, Du warst letztens aber gar nicht ehrlich, als Du mir wegen Kopfschmerzen abgesagt hast! Und später treffe ich Dich in einer Kneipe, he he.“
„Nun, das war eine Notlüge. Ich konnte Priscilla nicht absagen. Aber lass uns mal wieder über die Inspektion sprechen. Brauchen wir externe Inspektoren oder macht es das Team selbst?“
„Wir wollen doch schlank bleiben oder? Das Team macht es selbst.“
„Also dass das Team die Fehler gegenüber dem Kunden ausbügelt, davon gehe ich aus. Werden solche Fehler aber auch offengelegt, um daraus Lessons learned zu generieren? Wer rühmt sich schon gern seiner eigenen Fehler? Wie geht denn der PmBok Guide damit um?“
„Na ja, der PmBok Guide nennt das Prinzip der Governance, Führung und Aufsicht. Es wird nicht alles dem Projektteam überlassen. Auf Seite 49 wird bspw. das PMO genannt, das als integraler Bestandteil eines Projekts Kontroll- und Steuerungsmaßnahmen übernehmen kann. So eine „Manöverkritik“ im Rahmen der Abschlussprozessgruppe, könnte also durch ein Mitglied es PMO moderiert werden, um eine möglichst neutrale Bewertung von Problemfällen im Projekt zu gewährleiten. Schließlich sind Fehler oder Probleme in einem Projekt die besten Lehrmeister für zukünftige Projekte.“
„Paperlapap! Wie schon gesagt, Vertrauen und Offenheit sind unserer stärksten Treiber. Inspektion wird im eignen Saft durchgeführt!“
Adaption, das dritte Prinzip SCRUMS.
Das dritte Prinzip, „Adaption“, trifft eben nicht nur auf die Interaktion der Sprints zu, sondern eben auch auf die Einführung der SCRUMBUTS, die im wesentlichen dem pPm entlehnt sind.
Was die Adaption in agilen Projekten von Sprint zu Sprint angeht, kann man hier einen durchaus berechtigten wesentlichen Unterschied zu den pPms erkennen. Schließlich basieren pPms auf Use Cases, also detailliert definierte Anforderungen, wobei agile Projekte auf User Stories basieren, die für die Adaption weit mehr Freiräume bieten, als Use Cases.
„Adaptieren“ bedeutet aber auch nichts anders als Anpassen. Im PmBok Guide kommt dieser Begriff in den verschiedensten Kontexten 16 Mal vor. Ich kann mir nicht vorstellen, dass Ken und Jeff nicht über diesen Begriff gestolpert sind. Auch pPm verschließt sich nicht vollständig der Adaption.
Im nächsten Teil: Was lassen sich Ken und Jeff noch so einfallen? Studieren sie weiter den PmBok Guide? Lassen sich noch weitere Elemente SCRUMS mit Elementen des PmBok Guides matchen? Man wird sehen.