Einführung

Agiles Projekt-Management in der Software-Entwicklung - geht das?

Blue Scrum - Das Prozessmodell beschreibt einen pragmatischen Ansatz wie bestehende Industriestandards und Normen dazu genutzt werden können, einen hybriden Ansatz aus agilen und klassischen Projekt-Management-Elementen so zu kombinieren, dass diese Frage bejaht werden kann. Hierbei werden agile Ansätze im Sinne eines umfassenden Projekt-Managements vervollständigt bzw. klassische Ansätze auf das Fundament eines agilen Mindsets gestellt.

Das Blue Scrum Prozessmodell besteht aus drei Säulen:

Das agile Wertesystem
Zeitgemäßes Projekt-Management kann nicht länger auf klassischen Denkmustern aufsetzen, wenn der Geschäftswert des Kunden, Qualität, Effektivität und Effizienz nachhaltig verfolgt werden sollen. Die Prinzipen des Agilen Manifests definieren die Basis.

Die agilen Werkzeuge
Agile Werte benötigen agiles Vorgehen. Basis hierbei ist die vollständige Etablierung des Scrum Frameworks. Mit Hilfe weiterer agiler Werkzeuge entsteht letztendlich ein vollständiger Software-Entwicklungsprozess.

Das agile Projekt-Management
Um größere Projekt-Kontexte verwalten zu können, werden Elemente des klassischen Projekt-Managements im agilen Sinne wiederverwendet und adaptiert.

Die Ausarbeitungen der Blue Scrum Buchreihe können als Blaupause für eigene Projekte genutzt werden.

Download

PDF

Diskussion

Diese Seite dient der Diskussion der vorgestellten Inhalte aus Blue Scrum - Das Prozessmodell. Ziel ist die Fortschreibung des E-Books auf Basis der neu gewonnenen Erkenntnisse aus der Diskussion mit der (agilen) Projekt-Management Community.

5 Comments

  1. So, liebe Kollegen, nun liegt es an Euch diesen Vorschlag zu verbessern. Bin gespannt auf Eure Themen.

    1. Hallo Rainer,

      erstmal ein herzliches Dankeschön für deine ehrgeizige Mission!

      Hier mein Feedback zur ersten Fassung des Prozessmodells:

      • Du bezeichnest Blue Scrum als Hybrid. Für mich ist Blue Scrum aber kein Hybrid und seine die Erweiterung eines agilen Modells. Hybrid heißt Kreuzung, Mischform, Zwitter und soweit geht Blue Scrum nicht. Es greift lediglich partiell klassische Methoden auf. Das ist natürlich weder schlecht, noch verboten, aber wenn es eine echte Zusammenführung sein soll, dann bleibt mir das Modell doch eindeutig im Agilen verhaftet.
      • Auf Seite 8 beanspruchst du das Disruptive als Merkmal der agilen Vorgehensweise. Dem würde ich widersprechen. Ich glaube sowohl klassische als auch agile Projekte können disruptiv oder nicht-disruptiv erfolgen. "Disruptiv" ist kein Merkmal für agiles Vorgehen.
      • Gelungen finde ich deine Zusammenfassung der DIN und der IPMA Baseline. Dürfen wir die Abschnitte als Stub für eigene Wiki-Artikel auf openPM nutzen? (Natürlich mit Quellenangabe (wink))
      • Schade, dass Klassisch mal wieder auf Wasserfall reduziert wird. Im "APM - Agiles Projektmanagement" von Oesterreich/Weiß (Literatur) findet sich sehr schöne die Anekdote, dass die Urheber des Wasserfalls diesen eigentlich immer nur als vereinfachte Darstellung gesehen haben und selber eigentlich ein iteratives Modell vertreten haben.
      • Bei den als obsolet gekennzeichneten Prozessen bist du mir zu schnell. Ich würde beispielsweise auch Vorgangsplanung oder so etwas wie einen PSP durchaus auch in den  zu modifizierenden Bereich schieben. Im Agilen heißt das Kind anders  und findet auf einer anderen Granularität statt. Statt zu streichen würde ich hier mehr modifizieren. Ein PSP kann ja auch eine strukturierte Featureliste sein und dann sind wir schon ganz nah am Backlog. Dann ist viel mehr die Frage wie ich PSP/Backlog einsetze und weiter nutze.
      • Du triffst/übernimmst einige implizite Annahmen ohne diese auszuführen. Beispielsweise die Trennung Product Owner/Customer, die du von Gloger übernimmst. Ich habe den Product Owner eigentlich immer als eine Stärke agiler Ansätze gesehen, weil er den Kunden zur aktiven Kommunikation und Beteiligung "zwingt". Mit der Trennung ist der Product Owner auch "nur" ein Demand Manager und die ganzen Themen wie Kundenabnahme, Claim Management, Kundentermine etc. sind plötzlich wieder relevant.
      • Was ich mich bei agilen Ansätzen und auch bei Blue Scrum immer wieder frage ist, wo kommt das Backlog eigentlich her? Irgendwie scheint es vom Himmel zu fallen. Die agile Kritik am immens unproduktiven Vorlauf klassischer Projekte ist zwar berechtigt, aber auch die grundlegende Architektur und das Backlog will entwickelt werden und deine ergänzenden Rollen (Architekt, Tester, ...) zeigen mir auch in diese Richtung. Natürlich ist alles eine Frage von Maß, Umfang und Detaillierung und die Handlungsunfähigkeit in der viele klassische (vor allem) Großprojekte in ihrer Planungsphase oft verfallen ist natürlich grotesk, aber ich glaube hier gibt es auf beiden Seiten noch Lernbedarf.
      • Bei den über die klassischen Scrum-Rollen hinausgehenden Rollen fehlt mir ehrlich gesagt die Herleitung, aber vielleicht kommt die ja noch in einem der folgenden Bücher.
      • Was die Übernahme von Meilensteinen angeht wäre ich hingegen viel schärfer als du. Klar machen einzelne sinnvolle Meilensteine auch im Agilen Sinn (wenn man sie sparsam und mit Bedacht einsetzt), aber umgekehrt bin ich auch in eher klassischen Umwelten ein Fan von Timeboxing
      • Die Reduktion von Business Values auf Features habe ich leider nie verstanden. Das Ganze ist für mich mehr als nur die Summe der Features. 
      • Warum heißt klassisch: Umsetzung spezialisierter Komponenten? Nach meinem Verständnis erlauben klassische Ansätze genauso ein Feature-orientiertes Denken.

      Freue mich schon auf mehr!

      Gruß

      Bernhard

  2. Servus Rainer,

    ich bin gerade mit deinem Buch durch. Sehr interresante Aspekte hast du da eingebracht. Besonders der Einstieg über den golden circle hat mir gut gefallen. Das Ende des Buches kam aber irgendwie sehr überraschend. Ich hätte mir noch eine Art Fazit oder famous last words gewünscht, wo auf die kommenden Bücher eingegangen wird.

    Zu der Grafik auf Seite 29 bei der du die Projekt-Management-Prozesse erweiterst und anpasst hätte ich noch eine Frage: gehören beim Punkt "Ablauf, Termine" nicht noch die Retrospektive und das Sprint Review mit aufgezählt? Dabei handelt es sich doch auch um feste Termine während der Steuerungs-Phase. Oder zählst du die zum Punkt "Sprint" mit dazu? Aber dann müsste man das Daily ja eigentlich auch nicht noch mal extra aufzählen.

    Gruß

    Sascha

     

  3. Hallo Rainer,

     

    ich finde den Ansatz echt spannend.

    Falls Du auf dem PMCamp in Dirnbirn bist, würde ich mir eine Session zum Thema wünschen.

    1. Hallo Ralf,

      vielen Dank für das Interesse. Allerdings werde ich nicht dabei sein können. Sorry.

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen