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 (Siehe Headline). 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.
Der PmBok Guide bildet die Grundlage zur Zertifizierung zum Project Management Professional (PMP). Er wird im PMP Trainings oder Schulungen als zentrales Dokument genutzt, um auf die PMP Prüfung vorzubereiten. Die reine agile Lehre hat sich nur bedingt als erfolgreich erwiesen. Die Frage ist nicht „agil oder klassisch“. Die bisherigen Erfahrungen zeigen „sowohl als auch“. Der PmBok Guide 6th erlöst nun die agilen Frameworks vom Framework Dasein. Die Erweiterung um den Agile Practice Guide basiert auf dem PmBok Guide 6th und soll dieses Problem lösen. PMI und Agile Alliance gemeinsam, haben diese Erweiterung erarbeitet, um den agilen Methoden, speziell auch SCRUM, ein solides Projektmanagement Fundament hinzuzufügen.
Im Teil 1 haben wir uns primär mit den inkrementellen und iterativen Lebenszyklen beschäftigt.
Im Teil2 ging es darum zu zeigen, dass Projektstrukturpläne auch in agilen Umgebungen Sinn machen. Lesen Sie in diesem Artikel, wie das Integrationsmanagement im agilen Kontext zu interpretieren ist.
Integrationsmanagement als Team Kompetenz?
Integrationsmanagement ist im klassischen PM Aufgabe des Projektmanagers. Nach dem Kommunikationsmanagement, die zweit wichtigste Aufgabe des Projektmanagers. Integrationsmanagement beginnt bei der Einbettung der Projektorganisation im Unternehmen, beeinflusst die Entwicklung des Projektlebenszyklus und nimmt nicht zu Letzt, einen großen Einfluss auf die Entwicklung und Integration der Teams.
Einen Anteil der Integrationsmaßnahmen der Teams kann sicherlich der SCRUM Master übernehmen. Da das Team sich aber primär selbst organisiert, übernimmt das Team auch einen erheblichen Teil an Integrationsmaßnahmen.
Einerseits handelt es sich dabei um fachliche Elemente, da agile Teams auch häufig sehr interdisziplinär zusammengesetzt sind. Wenn bspw. „Dokumentation“ in agilen Frameworks kaum Beachtung geschenkt wird, muss man mutmaßen, dass interdisziplinär erarbeitete Lösungen maximal in der nächsten Retroperspektive verwendet werden. Aus Sicht des PmBok Guides, handelt es sich aber dabei um Assets, die im Prozessvermögen der Organisation erfasst werden sollen, um auch für zukünftige Projekte im Zugriff zu liegen. Solche Lösungen nicht langfristig zu konservieren, bedeutet „wasted time“ und das Gegenteil einer lernenden Organisation. Solche interdisziplinären Ergebnisse dienen dem Wachstum des „kollektiven Wissens“ im Unternehmen.
Andererseits entstehen auch in agilen Teams gruppendynamische Prozesse, die der SCRUM Master beurteilen und beeinflussen können sollte. Aber auch hier gilt es den hohen Selbstorganisationsanteil des Teams zu beachten. Das Team muss seine Fähigkeiten aufeinander abstimmen. Kommt es z.B. zu fachlichen Dissonanzen, sollten die Mitglieder der Gruppe in der Lage sein zu beurteilen, in welcher Phase der Team Uhr sich das Team befindet. Es ist ein großer Unterschied, ob sich das Team bspw. in der Phase Forming oder Storming befindet. Meinungsverschiedenheiten oder Konflikte werden in diesen Phasen vollkommen unterschiedlich gehandhabt. Hat das Team die Fähigkeit, auf der Metaebene den Entwicklungsstand des Teams zu beurteilen, kann es im Zweifel gezielter auf den Support des SCRUM Masters zurückgreifen. Dieses Thema wird aber noch intensiver im Wissensgebiet „Kommunikationsmanagement“ beleuchtet.
Die Prozesse des Integrationsmanagements
1. Projektauftrag entwickeln
Der Projektauftrag wird vor dem Start eines Projekts entwickelt und enthält aggregierte Ziele, an denen sich der Projektleiter orientiert. In Anlehnung an den klassischen Projektaufträgen, können im agilen Kontext hier folgende Punkte dokumentiert werden:
- Name de Product Owner mit grundsätzlichen Beschreibung zur Kommunikation mit dem Kunden.
- Name des SCRUM Masters, grober Aufgabenbereich.
- User Story und wichtigste abgeleitete Anforderungen. Auch wenn ein SCRUM Projekt keinen fest fixierten Zielen unterliegt, so haben doch die meisten Kunden eine klare Vorstellung von dem, was das Produkt einmal leisten soll.
- Liste der Stakeholder. Das Stakeholder Management wird in agilen Projekten nicht thematisiert. Aber gerade in agilen Projekten, in denen sehr viel Empowerment an das SCRUM Team übergeben wird, sollte das Stakeholder Management eine bedeutsame Rolle spielen.
- Risiken. Sicherlich werden in den meisten Softwareentwicklungsprojekten weniger Risiken auftreten als in einem Flughafenprojekt oder Bahnhofsprojekt. Das ist sicherlich auch der Grund warum die Erfinder agiler Methoden dieses Thema kaum frequentieren. Aber interkulturelle Risiken, Konflikte in der Matrix oder Ressourcenengpässe können auch in Softwareprojekten auftreten. Als quasi K.O. Risiko wird häufig die Nichtbeherrschung des “Mindset“ erkannt. Ich stelle immer wieder fest, dass im agilen Umfeld das Mindset immer als etwas optimal Funktionierendes a priori unterstellt wird. Das ist sicherlich Wunschdenken! Werte können nicht durch kognitive Vermittlung erzeugt werden und funktionieren schon gar nicht per Befehl und Gehorsam. Zum einen bringt der Mensch Werte durch seine Sozialisation von Haus aus mit, andererseits werden Werte durch Gelebtes und durch Situationen erzeugt oder entwickelt. Das agile Mindset ist nichts neues, ähnliche Werte galten auch schon immer im klassischen Projektmanagement und erzeugten hier ähnliche Probleme.
- Handover des Endprodukts. Ort, Art, Teilnehmer usw.
- Möglichkeiten der genaueren Ermittlung der Anforderungen im Rahmen der Iterationen innerhalb der Sprints. Agile Projekte leben von der Lernkurve innerhalb eines Sprints. Es kann notwendig sein, während eines Sprints, weitere Informationen der späteren User oder Bediener des Produkts zu erhalten. Näheres zu den Werkzeugen und Methoden finden sich im Wissensgebiet Inhalts- und Umfangsmanagement.
