Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz (Teil 5)

Projektmanagement und agile Softwareentwicklung – allem voran mit SCRUM – in einem Atemzug zusammen zu nennen, das tönt auf den ersten Blick nach dem Versuch der Quadratur des Kreises, sprich: Das geht eigentlich nicht. Wieso ist dem so?

Projektmanagement bedeutet Vorgaben, Termine, Budget, Fristen, von Oben nach Unten, der Projektleiter als Antreiber, ZackZack!

SCRUM hingegen bedeutet: Alle Macht dem IT-Entwicklungsteam. Das Team kann dem Product-Owner erst nach einigen Sprints sagen, wann und mit welchem Aufwand das Produkt voraussichtlich fertig wird. Es gibt keinen IT-Projektleiter, da ist “nur” der Product-Owner quasi als mitbeteiligter Auftraggeber. Da ist das Team, welches so zusammengesetzt ist, dass es in der Lage ist, selbstständig das Produkt zur Serienreife zu bringen. Und da ist der Scrum-Master, welcher die Stolpersteine beseitigt und das Team auf gleicher Augenhöhe (nicht von oben herab) coachen tut. Die Schönheit und Genialität dieses Ansatzes offenbart sich einem erst auf den zweiten Blick: Aufgrund der kurzen Sprints, welche von Anfang bei Sprintende ein ausführbares Produkt liefern müssen (Auch wenn bei den ersten Sprints das lauffähige Produkt in einem absolut unbrauchbaren Zustand geliefert wird), kann der Auftraggeber bereits sehr früh darüber entscheiden, ob sich das Team auf dem richtigen Weg befindet. Und: Es gibt keinen Projektleiter, es ist das Team welches sagt, was es bis wann liefert. Somit gibt es keine “Von oben nach unten Direktive”, das Team commited sich quasi mit Haut und Haaren zu den versprochenen Lieferterminen und kann sich nicht mehr hinter dem PL verstecken und sagen: “Der Projektleiter hat uns unmöglich zu haltende Vorgaben gegeben”.

Somit könnte man schliessen, dass die Rolle des Projektleiters nicht mit dem Scrum-Team in Einklang zu bringen ist. Es ist wie Öl und Essig. So etwas bindet einfach nicht. Die Sache ist aber die Gleiche wie bei der Salatsauce: Ein Salat schmeckt nicht – nur mit Öl. Genau so wenig schmeckt er nur mit Essig! Was also tun?

Scrum & Projektmanagement – Es gibt eine Lösung dafür: Im Gespräch mit einem der Hermes Methoden Spezialisten, dem Bernhard Kruschitz von der BKI konnte der Geschäftsmann einen absolut machbaren Approach umreissen, um Projektmanagement und agile Softwareentwicklung vereinen zu können!

Also: Der Auftraggeber und der Gesamtprojektleiter / Programmleiter braucht auf der einen Seite irgendwelche Planungsgrössen, Anhaltspunkte und Finanz- / Zeitschätzungen zum Produkt. Das Scrum-Team hingegen braucht die Freiheit bei der Produkteerstellung und die Möglichkeit, sich selber – ohne Zwang von oben – zu den Terminen und Aufwänden committen zu können (Das Team legt sich den Zwang selber auf). Und damit beides erfüllt werden kann, a.verfügbare Planungsgrössen für die Oberleitung und b. das Commitment und die Freiheit des Scrum-Teams, macht man während der Initialisierungsphase eben eine “IT-Studie” (früher hat man das Prototyp genannt).

Bei dieser Studie (dies ist ein mit Hermes5 neu eingeführtes Deliverable in der Phase Initialisierung) wird der Kern des Entwicklerteams gebildet und man gibt dem Team zwei oder drei Sprints frei. Mit jedem Sprint wird die Qualität der Storypoints besser und am Ende von Sprint 2 oder Sprint 3 sollte man dann ein Product Backlog haben, welches nicht mehr mit so grossen Unsicherheiten behaftet sein sollte.

Reserven – Jetzt hat man eine Planungsgrösse, welche man mit guten Reserven ausgestattet in den Projektmanagementplan übernehmen kann und das agile Scrum-Team hat bereits zu Beginn der Realisierungsphase eine viel höhere Sicherheit beim entwickeln und schätzen!

Hier noch ein Wort an die Auftraggeber: Die besten Auftraggeber, welche der Geschäftsmann bei seinen ca. 50 Projekten hatte, waren diejenigen, welche beim Projekt finanzielle und zeitliche Reserven eingeplant hatten. Es ist nicht nötig, diese Reserven zu kommunizieren, aber es ist gut, diese zu haben.

Fazit: Eine Entwicklungsstudie am Ende der Initialisierungsphase kann nicht nur dazu dienen einen funktionalen Prototyen zu entwickeln, sondern die dabei anfallenden Schätzgrössen (welche eine bessere Planungssicherheit bei der Projektplanung ermöglichen) können auch den Einsatz von agilen Softwareentwicklungsmethoden wie Scrum während der Realisierungsphase (welcher nun ein definiertes Zeitfenster eingeräumt werden kann) ermöglichen.

Zu guter Letzt: SCRUM & Hermes 5

So stellt sich Hermes Agile Softwarentwicklung im Hermes-Kontext vor
So stellt sich Hermes Agile Softwarentwicklung im Hermes-Kontext vor Quelle: Hermes 5

Agiler SW-Entwicklung wird im Hermes 5 Referenzhandbuch ab Seite 161 ein eigenes Kapitel geschenkt. Dort ist ersichtlich, dass die Autoren es als nicht möglich erachten SCRUM für den ganzen Projektzyklus zu verwenden sondern nur für dein Teil, nämlich wenn Software entwickelt wird. Das ist durchaus ein legitimer Ansatz. Nur dann gibt es für die Zeit, wenn Software entwickelt wird zumindest im Umfeld der Entwicklung keinen Projektleiter, nur das sehen die Hermes-Autoren, sie können sich nicht vorstellen, dass es Projekte oder Teilprojekte ohne PL gibt. So ist es auch irgendwie verständlich, dass im Hermes 5 Referenzhandbuch an folgenden Stellen aus Optik des Gmanns 2.0 Schwächen aufweist:

S. 63 / S. 51 Bei “Entwicklung Agil” führt der Projektleiter das Product Backlog, und er führt das “Protokoll” bei Sprints. Ein PL hat an beiden Orten eigentlich nichts verloren.

S. 113 “Die Einführung von SCRUM hat einen klaren Start und ein klares Ende”. Ja, SCRUM hat auch ein klares Ende, aber SCRUM kennt keinen vorgängig bekannten, klaren Endtermin das sieht man erst nach Sprint 2 oder 3 wann man etwa fertig sein könnte (Nämlich dort wo das Burndownchart die 0 Linie kreuzt)

S. 113 bei Sprints durchführen heisst es im Absatz “Hermes Spezifisch”: Die Projektleitung überträgt dem SCRUM-Team die Verantwortung für die Durchführung eines Sprints“. Hier sollte es eher heissen: “Der Product-Owner (den es im Hermes ja so nicht gibt) überträgt dem SCRUM-Team die Verantwortung für die Erstellung des Produkts.

Beitragsserie Hermes 5:

  1. Einleitung und Anlass 
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Fragen dazu oder Lust auf Mehr?: Update 18.3.2014 Aufgrund der regen Nachfrage gibt es nun dedizierten Hermes-Bereich mit Erfahrungen und Tipps: http://geschaeftsmann20.com/projektmanagement Fragen beantwortet der Geschäftsmann gerne hier.

So Long, Euer Geschäftmann 2.0, welcher neben dem zertifizieren PL auch zertifizierter Scrum-Master und Scrum Product Owner ist….