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.

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.

Wir empfehlen zum Thema Hybrides Projektmanagement
12.09.2024
1.395,00,-
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

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.

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.

Unsere Abos: für jeden Bedarf das passende Abonnement

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (7)

Guest

Das Vorgehen war sicherlich angemessen. Agil wars nicht, eher itterativ.

 

Dieter
Bertsch

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. &nbsp 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! &nbsp Sie führen aus, dass Sie durch klassische Projektplanung belastbare Vorschauen erhalten haben. Nachteil nach wie vor hierbei: Klassische Planung basiert auf Annahmen. &nbsp 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. &nbsp 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. &nbsp 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). &nbsp 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. &nbsp D. Bertsch &nbsp PS: Ein Scrum Master ist kein Teamleiter!

 

Guest

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...

 

Dieter
Bertsch

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). &nbsp 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). &nbsp 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.) &nbsp 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. &nbsp 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. &nbsp 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

 

Guest

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

 

Gerhard
Friedrich
Dr.

Hallo Herr Zeumer, gegen jede Form von Dogmatismus anzutreten und gleichzeitig nicht in völlige Beliebigkeit zurückzufallen ist sicher die ständige Herausforderung. Ich habe versucht, das etwas ausführlicher zu diskutieren und erlaube mir, einen Link zu diesem Beitrag einzufügen: http://bit.ly/agileArchitektur Wenn Sie nicht wollen, dass hier ein Link auf einen anderen Blog gesetzt ist, löschen Sie den Beitrag einfach wieder.

 

Guest

Hallo Herr Dr. Friedrich, nein, ist schon in Ordnung, denn Ihr Artikel unterstützt meine Erfahrung ja sogar weiter. Übrigens bemerkenswert, dass auch Sie Wert auf einen guten Projektmanager legen, der die Fäden in der Hand behält, obwohl es den ja bei den agilen Methoden angeblich gar nicht gibt... ;-) Beste Grüße Henning Zeumer