Es mutet an, als würde man aus Kostengründen nur ein wenig Agile werden wollen. Nach dem Motto
“sparen, sparen, sparen, koste es was es wolle”,
wird die Agile Transformation halbherzig betrieben.
Eine dedizierte Rolle Product Owner scheint so manchem Kunden ein Dorn im Auge zu sein, weil jemand, der von seinem Erfahrungsschatz her vielleicht auch umsetzen könnte, nun ausschließlich administrativ tätig sein soll. Das ist doch Geldverschwendung pur. Und um die richtig Anwendung der Methode kann der sich doch auch gleich kümmern.
Analog dazu wird oftmals die Rolle des Scrum Masters gesehen. Immer wieder kommt die Frage auf, ob er / sie denn auch Java und SQL beherrschen würde. Und eines ist ohnehin klar, er / sie soll gleich für drei der in Agile noch recht unerfahrenen Scrum Teams tätig sein.
Ja geht’s denn noch?
Was auch immer man halbherzig macht, ist mit hoher Wahrscheinlichkeit zum Scheitern verurteilt.
Ein Product Owner, der sein Handwerk versteht, wird kaum Leerlauf haben; kaum Zeit dazu haben, mit dem Finger in der Nase zu bohren.
Continuous Exploration
… oder auch ongoing refinement. Nach dem Motto
“Nach dem PI Planning ist vor dem PI Planning”
sollte der Product Owner schon unmittelbar nach dem PI Planning des gegenwärtigen Program Increments (PI) das Refinement all der Anforderungen in die Wege leiten, die im nächsten PI umgesetzt werden sollen. Wann auch immer klar wird, dass eine Anforderung im nächsten PI umgesetzt werden soll, triggert er das Team dazu an das Refinement durchzuführen.
Die Anforderung, die oftmals high level formuliert ist, wird in handhabbare Einheiten – den sogenannten User Stories – heruntergebrochen. Jede User Story sollte nun so lange refined werden, bis sie gemäß DoR (Definition of Ready) fertig für die Umsetzung ist. Im Einzelnen heißt das:
- Man weiß Was umgesetzt werden soll,
- in etwa Wie man es umsetzen möchte und
- eine grobe Aufwandsschätzung ist auch durchgeführt worden.
Und weil der Product Owner ein guter Mann / eine gute Frau ist, erarbeitet er / sie für das Team schon einmal einen unverbindlichen Vorschlag für den Plan des nächsten PI’s und schiebt die DoR-konforme User Story in den Sprint des nächsten PI’s, in dem sie mutmaßlich umgesetzt werden soll. Vorbereitung ist das halbe Leben.
ABER, gegen Mitte des aktuellen PI’s
… kommt Ungemach auf. Wir stellen fest, dass die Pläne der ersten drei Sprints so gar nicht funktioniert haben. Das Team schiebt eine mächtige Bugwelle an nicht umgesetzten Anforderungen / User Stories vor sich her. Es wird mehr und mehr klar, dass vielleicht gerade einmal ⅔ des (PI-) Plans umgesetzt werden kann.
Ergo: Was in diesem PI nicht geschafft wird, wandert ins nächste PI.
Die bis dato vielleicht schon weit fortgeschrittene (unverbindliche) Vorbereitung des (PI-) Plans für das nächste PI muss nun in Hinblick auf den großen Spillover aus dem gegenwärtigen PI neu überarbeitet werden. All das, was im aktuellen PI nicht geschafft wird – oder zumindest vieles davon – muss mit hoher Wahrscheinlichkeit im nächsten PI umgesetzt werden.
Ach ja, da sind ja auch noch die Stakeholder, denen schonend beigebracht werden muss, dass der Plan nicht so funktioniert hat. Hmmm, wie sag ich’s denen nur, dass sie nur einen relativ geringen Teil dessen bekommen, was eigentlich committed war?
Gekonntes Stakeholder Management ist ein Kunst und auch diese Kunst kostet Zeit.
Ach ja, den Scrum Master gibt’s ja auch noch.
Das Sprint Health Gadget des gegenwärtigen Sprints wie auch das Velocity Chart der vergangenen Sprints sagt aus, dass das Team in steter Regelmäßigkeit das Ziel verfehlt. Im Durchschnitt werden gerade mal 37 % des Plans erreicht. Wow, das ist nicht gut.
Woran liegt das? Hier ist nun in erster Linie der Scrum Master gefragt. Er sollte für ausreichend Transparenz sorgen, damit die möglichen Gründe für den schlechten Zielerreichungsgrad ermittelt werden können. Wie möchte man den im Rahmen eines
Continuous Improvement
Conclusio
Leisten Product Owner und Scrum Master gute Arbeit, wird das (Scrum) Team einen qualitativ hochwertigen Output liefern. Die Verlässlichkeit in Bezug auf das Commitment wird signifikant steigen. Der erzeugte Output wird weniger Fehler / Bug haben. Das Kosten : Nutzen – Verhältnis des gesamten Teams wird sich verbessern. So spart man!
Wollen Sie mit professionellen RTE’s., Product Owner und Scrum Master arbeiten? Dann
