Inhalt : Blue Scrum - Das Prozessmodell

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

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

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 )
• 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

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.

Hallo Ralf,

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