|
Die Selbstorganisation (die autodynamische Organisation ist der passende Begriff für agiles Projektmanagement) bedeutet, dass das agile Projektteam wie Scrum Team die Autodynamik von der Initiierung bis zum Abschluss lebt. Das Scrum Team ist operational geschlossen (2 bis 4 Wochen lang operiert das Scrum Team wie Hakan, der Freund von Kaya Yanar: "Du kommst hier ned rein!"). Strukturell ist das Scrum Team jedoch offen (während der Sprints zum Product Owner und Scrum Master. Jenseits der Sprints auch zu weiteren Stakeholder.)
→ Stakeholder identifizieren
Dass das Scrum Team die Stakeholder in seinen Umwelten von Anfang an kennen und die Stakeholder-Bewegungen während des Projektes verfolgen (kausal gekoppelt) bzw. spüren (strukturell gekoppelt) muss, ist ein kritischer Erfolgsfaktor für agiles Projektmanagement.
Zur Identifizierung der Stakeholder arbeiten Product Owner, Scrum Team und Scrum Master zusammen. Wir haben die Erfahrung gemacht, dass man bereits während der Identifizierung der Stakeholder die Aufgaben für den Umgang mit Stakeholder definiert und unter Product Owner, Scrum Team und Scrum Master verteilt.
→ Projektauftrag entwickeln
In unseren Kundenprojekten haben die Kunden -ohne Ausnahme- den Product Owner zum Prozesseigner für den PMI Projektprozess Projektauftrag entwickeln ernannt.
→ Tural on Management
Ein markanter Unterschied zwischen der PMI-Sichtweise und Scrum liegt in der Dauer der Iterationen. Scrum schlägt eine Sprint- Dauer von 2 bis 4 Wochen. Bei der Gestaltung der relevanten PMI-Projektmanagementprozesse muss diese Dauer als Constraint berücksichtigt werden
Das Scrum Team organisiert sich während der Sprints selbst (Self-Organisation), trifft eigenständig und ohne steuernde Anweisungen eines Projektmanagers Entscheidungen. Die feste Kopplung von Product Backlog und Sprint Backlog erzeugt ein kausales Machtverhältnis zwischen dem Product Owner und Scrum Team. Scrum Master und Scrum Team koppeln sich lose, so dass ihre Beziehung weniger kausaler, mehr struktureller Art ist. Die Macht der traditionellen Projektmanager als Steuerungsinstrument hat der Scrum Master nicht. Diese Eigenschaft vom Scrum Master wird von den meisten Scrum Experten und Scrum Trainern auf "Soft Skills" reduziert. Sie hat mit Soft Skills nichts zu tun.
Während der Projektmanager PMI® / PMP® sich ausschließlich den Projektmanagementprozessen widmen (sollen), verantwortet das Scrum Team an erster Stelle die produktorientierten Projektprozesse, d.h. die Leistungserstellungsprozesse. Dennoch müssen die Scrum Team-Mitglieder fragmental über Kompetenzen für Techniken und Werkzeuge der Projektmanagementprozesse verfügen. Der Umgang mit dem magischen Hexagon bleibt ihnen nicht erspart.
In Scrum-Projekten existiert die Rolle Projektmanager zwar nicht mehr, die Projektmanagement-Aufgaben lösen sich aber nicht in Luft auf und werden unter drei Scrum-Rollen verteilt. (In einem Workshop im Oktober 2010 klärte uns ein Teilnehmer mehrmals auf, dass Scrum Projekte keinen Projektmanager mehr benötigen. Er muss es auf einem Scrum User Group Treffen aus berufenem Munde eines bekannten Scrum-Vordenkers gehört haben.)
Für PMI® gestaltet sich die Rolle des Projektmanagers durch eine ganz andere Perspektive. Projektmanager, die sich an PMI® orientieren, können ein Scrum Projekt führen, wenn sie tatsächlich führen und nicht steuern, dass sie die Machtbefugnisse nicht haben. Die Selbstorganisation des Projektteams dürfen sie nicht stören. Unter diesen Bedingungen können sie als Scrum Master agieren, um den Mitarbeitern des Scrum Teams bei der Entscheidungsfindung den Rücken freizuhalten.
Projektmanager, die sich an PMI orientieren, sind für Monitoring und Controlling in ihrem Projekt verantwortlich.
Während der Sprints bzw. Iterationen in Scrum Projekten trägt das Scrum Team für Monitoring und Controlling selbst die Verantwortung, da es sich ja selbst organisiert. Iterationsübergreifend auf der Release-Ebene ist Product Owner als Product Backlog Owner für Monitoring und Controlling verantwortlich. Dem Product Owner geben wir den Ansatz Earned Value Management für Realese-Monitoring and -Controlling in die Hand.
Immer wenn wir in unseren Kundenvorhaben die Prozesse der Gruppe Monitoring und Controlling im Hinblick auf eine autodynamische (Selbst-)Organisation beleuchten, gewinnen die Beteiligten die Erkenntnis, dass Scrum Teammitglieder doch etwas mehr Projektmanagement können müssen als sie bis dato annahmen. Den Fortschritt zu messen und die Schätzqualität zu bewerten, sollte das Scrum Team nicht anderen überlassen.
Die zehn Projektmanagementprozesse im PMBOK® Guide sind:
- Projektarbeit überwachen und steuern
- Integrierte Änderungssteuerung durchführen
-
Inhalt und Umfang verifizieren
- Inhalt und Umfang steuern
-
Terminplan steuern
-
Kosten steuern
-
Qualitätslenkung durchführen
-
Arbeitsleistungen berichten
-
Risiken überwachen und steuern
-
Beschaffung verwalten
Wenn Sie die PMI Projektmanagementprozesse für agiles Projektmanagement
gestalten möchten, sollten Sie einige Begriffe durch passendere
ersetzen, z.B. überwachen durch beobachten, steuern durch managen. Dann steht Ihnen für agiles Projektmanagement mit PMI nichts mehr im Wege.
 BlueRocks Seminare für Agiles Projektmanagement mit dem PMI®
|
