15
Jan 2016
Meilenstein – Der Projektmanagement-Blog

Wie Projektmanagement und Agilität zusammen mehr Nutzen bringen

Es begab sich zu einer Zeit vor Beginn dieses Jahrtausends, als das Wörtchen Scrum lediglich von Rugby-Fans geführt wurde und das Agile Manifest noch nicht geschrieben war… Vielleicht passt bei meiner heutigen Praxis-Rückschau das Wörtchen "neulich" nicht ganz rein, aber ich habe in den seitdem vergangenen Jahren immer wieder Projektsituationen erlebt, für die das folgende Beispiel exemplarisch stehen kann.

Anzeige

Nah am Standard und doch ganz individuell – geht das?

Damals ging es darum, ein Pilotprojekt für ein ERP-Template durchzuführen, das in der Folge dann seinen Roll-Out in alle Niederlassungen des weltweit operierenden Kundenunternehmens erfahren sollte. Das Template sollte zur Kostenminimierung nahe am Standard bleiben und dennoch möglichst gut die Markt-Besonderheiten und gesetzlichen Anforderungen in den Niederlassungen adaptieren. Eine Quadratur des Kreises?

Es kam, wie es kommen musste: Das Lastenheft erfuhr immer wieder Change Requests für neue oder geänderte Anforderungen aus den Niederlassungen. Die Abteilungen im Hauptsitz des Unternehmens nahmen dies als Einladung, auch ihre Sonderwünsche freizügig "einzukippen", so dass die prognostizierten Kosten über alle Budgetgrenzen hinausschossen. Nun machte das Projekt, was Piloten tun, wenn sie keine Landeerlaubnis bekommen: Es drehte Schleifen.

Agiles und "klassisches" Projektmanagement gehen eine Symbiose ein

Damit es sich nun von der Anforderungs- und Planungsphase einmal in Richtung Umsetzung bewegte, entschlossen wir uns, aufbauend auf den Kernfunktionalitäten des Standards iterativ vorzugehen. Als Strategie wurde vereinbart, nach einer jeweils festgelegten Zeitspanne ein funktionsfähiges Template fertig gestellt und getestet zu haben, das in folgenden Iterationen um priorisierte Inkremente ergänzt werden sollte, bis entweder der Zeit- bzw. Budgetrahmen erschöpft wäre oder das Template den Ansprüchen des Kunden hinreichend genügte.

Entsprechend wurden in der "klassischen" Projektplanung abgegrenzte Zeit- und Kostenblöcke eingesetzt, aus denen die Geschäftsleitung jederzeit belastbare Vorschauen erhalten konnte. Das gab dem Management Kalkulations- und Planungssicherheit.

Der Erfolg: Quick Wins, Flexibilität und Sicherheit

Auf diese Weise erreichten wir zweierlei: Erstens konnten wir mit der Entwicklung ohne weitere Verzögerungen beginnen, also ohne auf umfängliche Detailplanungen warten zu müssen, denn der Standard und die unstrittigen Grundfunktionalitäten für die ersten Entwicklungsphasen (Sprints) standen ja schon fest. Innerhalb von fünf Monaten hatten wir ein Deployment-fertiges Grundrelease, das ca. 70% der Prozesse unterstützte und für das die Mappings für die Datenmigration von den Altsystemen entworfen werden konnten.

Zweitens zogen wir so den "Anforderungsstreit" aus dem Team heraus. Der fand fortan unter den Product Ownern (so nannten wir sie damals natürlich nicht) aus den Niederlassungen und Fachabteilungen statt, die sich auf eine priorisierte Anforderungsliste (Stories) einigen und ein minimales Lastenheft (Product Backlog) definieren mussten. Später stellten wir in den Release-Planungen fest, dass wir um einen gemeinsamen Kern (das Template Backlog) durchaus individuelle, länderspezifische Erweiterungen in "Country Backlogs" entwickeln konnten, deren inkrementelle Freigabe von ihrer sauberen Integration mit dem Kern abhängig gemacht wurde.

Top-effizient: auf Entwicklungsebene agil, im Projektmanagement "klassisch"

Während der gesamten Entwicklungszeit waren die Entwicklerteams nur gebunden an das, was sie für die jeweils 4- bis 6-wöchigen Release-Zyklen vom priorisierten Backlog-Stapel von oben herab geschätzt und Deployment-fertig zu liefern zugesagt hatten. Das ging in 90% der Fälle auf. Die Entwicklung war in der Masterplanung des Projekts als Control Account zeit -und budgetmäßig eingearbeitet, Risiko- und Issue Management arbeiteten eng mit den Teamleitern (Scrum Masters) zusammen, die Projektleiter und Qualitätssicherer (Product Owner) intensiv mit den verschiedenen Stakeholdern.

Insgesamt konnten wir so nach 18 Monaten Projektlaufzeit etwa zwei Monate Entwicklungsarbeit einsparen. Diese Zeit steckten wir dann in ein gut vorbereitetes Change Management. Jenes ging zulasten von ca. 25% der Anforderungen des ursprünglichen Lastenheftes, die sich als Nice-to-Haves herausstellten und neuen, als wichtiger eingestuften Anforderungen weichen mussten.

Und noch etwas: Wir waren mit dem 14. Release des Templates um Monate früher live als mit dem ursprünglichen Endprodukt geplant. Viele der Niederlassungen hatten ihre Varianten schon im operativen Betrieb, bevor der ursprünglich geplante Roll-Out begonnen hätte. Alles zusammen genommen haben wir auf der Kostenseite zwar nicht viel gespart, auf der Produktivitäts- und Business-Seite jedoch viel gewonnen.

Ein Beispiel für Best Practice

Warum ich über dieses Projekt hier gerne schreibe? Weil wir damals noch nicht wussten, dass viele unserer Vorgehensweisen heutigen agilen Entwicklungsmethoden entsprachen. Und weil ich in vielen Projekten seither immer wieder feststellen konnte, dass sich diese mit dem "klassischen" Projektmanagement nicht beißen, sondern, richtig und versiert miteinander verknüpft, hohe Produktivitäts- und Effizienz-Potenziale in sich tragen, die so manchem Projekt und Business Case gut täten.

Bisher gibt es 5 Kommentare
Das Vorgehen war sicherlich angemessen. Agil wars nicht, eher itterativ.
vor 35 Wochen 4 Tagen Ilja
Ich freue mich über Ihren Erfolg mit agilen Methoden und besonders schön finde ich Ihren Satz, dass Sie auch schon agile Methoden eingesetzt haben, ohne es zu wissen. Das zeigt mir, dass agiles Arbeiten (und von den Begrifflichkeiten her haben Sie wohl Scrum verwendet) eher einem natürlichen, evolutionären Vorgehen entspricht als die künstliche Zerlegung in Phasen und übergreifenden Steuerungsprozessen.
 
Was ich nicht in Ihrem Artikel finde ist der Mehrwert klassischen Projektmanagements, den Sie nicht auch erreicht hätten, wenn Sie konsequent nach Scrum vorgegangen wären!
 
Sie führen aus, dass Sie durch klassische Projektplanung belastbare Vorschauen erhalten haben. Nachteil nach wie vor hierbei: Klassische Planung basiert auf Annahmen.
 
Hätten Sie auch hier gleich den Schritt zur Agilität gemacht und zum Beginn ein Release Planning durchgeführt und im Verlauf des Projektes Backlog Grooming (oder wie es im aktuellen Scrum Primer jetzt neu heißt: Backlog Refinement) betrieben, würden Ihre Planung sogar auf empirischen Werten beruhen.
 
Und auch Ihre Ausführung über den separaten Zeitaufwand für „ein gut vorbereitetes Change Management“ zeigt mir, dass Sie mit „pur Scrum“ noch größere Erfolge gehabt hätten:
1. Change Management ist eine integrierter Disziplin im Rahmen der Reviews & Backlog Refinement-Aktivitäten – also kein separater Aufwand nötig.
2. Sie haben aktuell also etwas ausgeliefert, was den Anforderungen der Kunden nicht entspricht – sonst gäbe es keine Change Requests (CRs). Nach „pur Scrum“ wären diese sofort in die Anforderungen eingearbeitet worden und sie hätten zum Projektende die Anforderungen gleich so umgesetzt, wie die Kunden sie wünschen (früherer ROI). Und den Aufwand für die CRs, die jetzt noch anstehen und deren Verwaltung (Management) hätten Sie gespart.
 
Und ich sehe noch einen großen Nachteil in der Kombination von klassischem und agilem Vorgehen: Hier müssen zwei gänzlich unterschiedliche Kulturen miteinander vereint werden; die klassische „Command- & Control“-Kultur mit "Colllaboration" und "Cultivation" in den agilen Teams (vergl. „Agile Survival Guide“, Michael Sahota, 2012).
 
Fazit: Meine feste Überzeugung ist, dass Sie mit „pur Scrum“ noch besser gefahren wären. Es zeigt mir jedoch auch wie schwer es zu sein scheint, alte Gewohnheiten loszulassen.
 
D. Bertsch
 
PS: Ein Scrum Master ist kein Teamleiter!
vor 35 Wochen 4 Tagen Dieter Bertsch
Hallo Herr Bertsch, danke für Ihre Analyse. Sie mögen ja in vielen Fällen Recht haben: Man kann mit purem Scrum in vielen Projekten noch viel effizienter arbeiten als mit der beschriebenen, hybriden Vorgehensweise. Aber vergessen Sie bitte nicht, wann ich dieses Projekt geleitet habe - da gab es noch kein pures Scrum ;-)
Ein anderer Aspekt spricht für mich auch weiter für eine gekonnte Mischung: Agil passt nicht immer und überall. In den Projekten, die ich üblicherweise leite, wäre Scrum in Reinkultur meist überfordert, allein schon weil man dazu Teams braucht, die sich selbst organisieren können. Das ist in vielen Unternehmen und Projekten aber nicht der Fall. Also spiele ich dort lieber weiter den Projektleiter, führe meine Leute und lasse ihnen soviel Freiräume wie nötig und möglich.
Beste Grüße
Henning Zeumer
P.S.: Man sollte aus keiner Lehre ein Dogma machen. Es ist noch kein Projekt erfolgreich geworden, nur weil es nach einer Methode oder einem Handbuch durchgeführt wurde. Es liegt immer an den Menschen und wie der, der sie führt, aus ihrem Können mehr als die Summe der Einzelleistungen machen kann...
vor 35 Wochen 4 Tagen Henning Zeumer
Hallo Herr Zeumer,
ja, dass sich Ihr Artikel auf eine Begebenheit aus dem letzten Jahrtausend bezieht, habe ich übersehen. Ken Schwabers erste veröffentlichte zu Scrum stammt dann wohl aus dieser Zeit (1995).
 
Dass Scrum nicht immer und überall passt, da bin ich voll bei Ihnen! Und mir ging es auch in keiner Weise um sklavisches Befolgen von Vorgaben aus Anweisungen (wobei mir der PMBOK Guide, 5th Edition mit 589 Seiten weniger den Eindruck von Freiräumen vermittelt als ein Scrum Guide mit 24 Seiten).
 
Methodenvielfalt (Scrum, Kanban, ggf. auch Wasserfall) ist auf jeden Fall nötig, um effizient zu sein. Je nachdem, ob das Vorhaben kompliziert/komplex ist, einen kontinuierlichen Fluss an Anforderungen bewältigen muss oder eben einfach ist weil alle Anforderungen bekannt sind und keine Änderungen erwartet werden. (Diese Abgrenzung ist übrigens angelehnt an einen Publikation vom PMI.)
 
Mir vermittelte Ihr Artikel aber den Eindruck, dass Scrum ohne die Anreicherung durch Elemente des klassischen Vorgehens nicht oder zumindest weniger erfolgreich wäre. Dem wollte ich etwas entgegen wirken.
 
Da die Methoden in sich schlüssig und das Zusammenspiel von Werten, Prinzipien und Praktiken aufeinander abgestimmt sind, empfehle ich meine Kunden lieber nicht „nur ein bisschen Schwanger“ sein zu wollen.
 
Und dass bei allen Vorhaben der Mensch im Mittelpunkt steht (oder besser: stehen sollte), steht außer Frage! Nur - Welches Vorgehen berücksichtigt diesen Fakt stärker: Scrum oder klassisches Vorgehen …
D. Bertsch
vor 35 Wochen 4 Tagen Dieter Bertsch
Hallo Herr Zeumer,
vielen Dank, dass Sie Ihre Erfahrungen hier teilen. Und Danke auch für den weiteren Hinweis: "Man sollte aus keiner Lehre ein Dogma machen. Es ist noch kein Projekt erfolgreich geworden, nur weil es nach einer Methode oder einem Handbuch durchgeführt wurde. Es liegt immer an den Menschen [...]" Da stimme ich Ihnen absolut zu.
Grüße
Birger Kontek
vor 34 Wochen 6 Tagen Birger Kontek
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link