Der agile PMBOK® Guide 4th edition – Scopemanagement

Jetzt kommt der Kern der Serie zum agilen PMBOK^® Guide. Agile Vorgehensweisen werden meist gewählt, weil der Scope ein moving target ist. Am Beispiel von SCRUM werden die Anforderungen vom Product Owner im Product Backlog gesammelt und priorisiert. Sie werden in User Stories heruntergebrochen, die das Entwicklerteam in der Sprintplanung heranzieht um ein Sprint Backlog zu erstellen und anschließend die ausgewählten User Stories in Tasks herunterzubrechen. Klingt erstmal wunderbar, bringt aber in der Praxis Probleme mit sich.

In der Praxis ist nicht die ganze Welt agil, deshalb müssen Schnittstellen zu klassischen Denkweisen gebildet werden. In weitesten Sinn muss ein Unternehmen in seiner Außendarstellung mit nicht-agil-denkenden Empfängern kommunizieren. Dies sollte relativ einfach sein, da man hinsichtlich neuer Produkte und Dienstleistungen selten von Beginn an alle Details kommuniziert. Schwieriger wird es bei den Lieferanten. Letztlich steuern Verträge die Zusammenarbeit und Verträge werden beispielsweise von Juristen erstellt, die überhaupt nichts mit Agilität zu tun haben.

Die Schnittstelle zu Lieferanten muss bei agilen Projekten von einer gewissen Konstanz geprägt sein. Auch bei time & material-Verträgen brauchen Lieferanten Planungsdaten für die Steuerung des eigenen Unternehmens. Die Schnittstellen innerhalb des eigenen Unternehmens können je nach Firmenkultur und Prozessen sehr unterschiedlich sein. Kaum ein Unternehmen wird von A bis Z agil denken. Eine Finance-Abteilung ist aus meiner Sicht ein exemplarischer Kandidat für eine weitere Schnittstelle in die nicht-agile Welt. Auch hier werden solide Planungsdaten benötigt. Deshalb müssen vor jedem agilen Projekt die Schnittstellen genau bedacht und resultierende Projektrandbedingungen und Regeln für das Projekt abgeleitet werden, um in diesem Rahmen agil agieren zu können.

Sehen wir uns die einzelenen Prozesse im Scopemanagement des PMBOK^® Guide 4th edition an:

• Anforderungen erfassen
  Im Gegensatz zu Wasserfallprojekten, können in agilen Projekten meist nur die wichtigsten Grobanforderungen erfasst werden neben einem Gesamtbild der gewünschten Projektergebnisse. Entsprechend der gewählten Methodik wird konform zu den Outputs dieses Prozesses eine Dokumentation der Anforderungen erstellt werden. Der Anforderungsmanagementplan wird von der Methodik vorgegeben oder muss passend zum Projekt definiert werden. Klassische Pläne können an dieser Stelle nicht benutzt werden, da der hohe Grad an Flexibilität in agilen Projekten einen ebenso flexiblen Umgang mit Anforderungen erfordert. Die Requirements traceability matrix sollte mit Vorsicht genossen werden, da eine zu detaillierte Verwendung durch übertriebenen Formalismus den Grundgedanken einer agilen Vorgehensweise zuwiderlaufen kann.

• Scope definieren
  Der wesentliche Output ist hier die Beschreibung des Projektscopes. Sie ist auf ausreichend hoher Ebene gehalten, um auch in agilen Projekten problemlos eingesetzt werden zu können. Auch hinsichtlich der Methoden bleibt hier alles beim Alten.

• Projektstrukturplan erstellen
  Bei SCRUM werden die Anforderungen zu einem Product Backlog und einem Sprint Backlog verarbeitet, ein Diagramm wie ein Projektstrukturplan wird hierbei nicht verwendet. Diesen Prozess kann man also in SCRUM-Projekten ersetzen durch den Prozess zur Erstellung des Product Backlogs. Auf der anderen Seite finde ich einen PSP als Landkarte eines Projekts äußerst hilfreich, eine priorisierte Liste von Anforderungen kann doch etwas dünn sein. In diesem Sinne plädiere ich für eine Abwägung und empfehle weiterhin die Erstellung eines PSP. Wie man nun ein PSP-Verzeichnis mit Arbeitspaketbeschreibungen gestaltet, ist dagegen relativ egal. Die Dokumentation im Sinne von User Stories und die Dokumentation im Sprint Backlog halte ich für ausreichend. Ein weiterer Output dieses Prozesses ist die Scope baseline. Sie ergibt sich bei SCRUM automatisch mit der Sprintplanung, d.h. umgekehrt muss die initiale Planung jedes Sprints unbedingt festgehalten werden.

• Scope verifizieren
  Die Verifizierung des Scopes dient im Wesentlichen der Abnahme der Liefergegenstände. In diesem Sinne wird der Prozess denn auch in agilen Projekten häufiger durchgeführt. Vielen agilen Vorgehensweisen ist gemeinsam, dass der Kunde Teilergebnisse abnimmt, z.B. kann dies jeweils nach einigen Sprints oder einer Iteration oder einem Inkrement erfolgen. Idealerweise sitzt der Kunde in agilen Projekten mit dem Projektteam zusammen und kann so im ständigen Dialog die Erstellung der Liefergegenstände vereinfachen durch umgehendes Feedback.

• Scope kontrollieren
  Dieser Prozess muss in agilen Projekten deutlich anders gelebt werden. Die Fortschrittskontrolle hinsichtlich des Scopes sowie Change Requests werden in SCRUM im Rahmen der Daily SCRUMs, burn-down charts und Aktualisierungen des Product Backlogs und Sprint Backlogs umgesetzt. Der grundsätzliche Rahmen des Prozesses kann beibehalten werden, die Ausgestaltung muss entsprechend der Vorgehensweise erfolgen.

An den Prozessen diesen Kapitels merkt man deutlich, dass man in einem Blog nur Denkanstöße geben kann. Und selbst die füllen dann gerne 2-3 Wochen des Blogs so gut wie exklusiv. Der PMBOK^® Guide ist wie immer nur ein Rahmen für eine Projektmanagement-Methodik und die Diskussion eines einzelnen Prozesses mit seinen Artefakten kann im Detail genauso umfangreich sein wie diese Serie von Postings. In diesem Sinne unterschätzen Sie nicht die Erstellung einer PM-Methodik in Ihrer Organisation, wenn Sie agile Projekte professionell umsetzen wollen.