Oftmals äußert das Management die Meinung, dass es mit Agile auch nicht besser geworden ist. Gefühlt dauert es immer noch zu lange, bis verwendbarer Output – auch Added Value genannt – erzeugt wird. Wurden vorher die langfristigen Zusagen zu Lieferterminen nicht eingehalten, werden heute die für kurz- und mittelfristig zugesagten Meilensteine gerissen. Was soll also an Agile besser sein, als am klassischen Vorgehen?
Eine Methode falsch anzuwenden ist, wie den Nagel mit dem Schraubenzieher in die Wand schlagen.
Was soll denn besser werden, wenn man es falsch macht?
Der Zweck hinter den Events
Das Sprint Planning
Wikipedia sagt, dass Planung die menschliche Fähigkeit oder Tätigkeit zur gedanklichen Vorwegnahme von Handlungsschritten beschreibt, die zur Erreichung eines Zieles notwendig scheinen. Der gesunde Menschenverstand sollte das bestätigen.
Wenn der regelmäßig erreichte Zielerreichungsgrad im Schnitt bei weniger als 50 % liegt, dann sollte man die Sinnhaftigkeit eines Plannings, so wie es durchgeführt wird, schon einmal hinterfragen. 30 % umgesetzt, schafft man bestimmt auch ohne jegliche Planung.
Siehe auch: Scrum und SAFe – KPIs auf Teamebene
Das Daily
Der primäre Sinn und Zweck des Daily ist die Klärung dessen, ob man im Plan ist. Dabei informieren die Developer des Teams sich gegenseitig darüber, was denn seit gestern schon umgesetzt wurde und an was man gerade arbeitet. Sollten Impediments – also Hindernisse für die Planerfüllung – aufgekommen sein, so kann man diese bei der Gelegenheit gleich auch mal dem Scrum Master mitteilen. Ein zumeist nur zuhörender Product Owner bekommt so die Info, wie es um den Plan – das Increment – steht.
Sofern die Zielerreichung gefährdet ist, könnte es auch sein, dass sich die Entwickler gegenseitig unterstützen, sofern es das vorhandene Know-How und gegebenenfalls verfügbare Kapazität zulässt.
Wenn aber nur stupide der Vorgabe des Handbuches gefolgt wird und jeder Developer stoisch sein Sprüchlein von sich gibt …
- seit gestern habe ich … gemacht,
- gerade bin ich dabei …,
- ansonsten keine / folgende Impediments
… und man bei genauer Beobachtung der Teilnehmer des Daily nicht wirklich erkennt, ob es dem Sinn und Zweck des Daily wirklich gerecht wird, sollte man sich schon fragen, warum man das Daily überhaupt abhält.
So manches Mal habe ich mir schon erlaubt, den Letzten der Runde danach zu fragen, was denn der Erste der Runde von sich gegeben hat und durfte dann in ein erschrecktes und nicht wissendes Gesicht blicken. An die Scrum Master dieser Nation, erlaubt Euch ruhig mal zu überprüfen, ob der Sinn und Zweck des Daily auch wirklich erfüllt wird. Das ist im Grunde genau ein Teil Eurer Aufgaben.
Das Review
Das Review sollte Stakeholder-spezifisch vorbereitet und abgehalten werden. Nicht jeder Stakeholder ist an jeder Message interessiert, die durch ein Review vermittelt werden soll. Eine Message für alle, wird nicht funktionieren.
Das Review dient dazu, für definierte Kreise an Stakeholdern den entwickelten Mehrwert – auch Added Value genannt – zu präsentieren. Für Manager kann das eine Funktionalität sein, die dem Unternehmen Zeit und Geld spart. Für den Anwender kann das mehr Übersicht über das angebotene Produkt sein. Ziel eines Reviews ist auf jeden Fall, dass die Stakeholder am Ende des Reviews zufriedene Gesichter zeigen. Ja, dass sie wenn möglich sogar Tränen der Glückseligkeit in den Augen haben. Das ist kein Scherz!
Was möchte man damit erreichen, wird so manch einer fragen? Sichtbar machen, was man geleistet hat und dass man das Geld wert ist, das man für sein Tun erhält. Bestätigung für das Geleistete durch die Stakeholder erlangen. Sich Lob von Kunden, Management und auch Anwendern abholen, weil Lob motivierend ist. Die Rechtfertigung dafür, dass man genau der Richtige für die geforderten Aufgaben ist. Sich damit das Budget für das nächste Jahr sichern. Anregungen für weitere Funktionalitäten einholen. Sich der (hoffentlich konstruktiven) Kritik der Kunden stellen. Überprüfen, ob man auf dem richtigen Weg ist. Etc.
Ein Review, das nur für die eigenen Kollegen abgehalten wird, ist Selbstbeweihräucherung. Ein Review, das Stakeholder nicht (annähernd) zu der oben beschriebenen Reaktion verleitet, wird oftmals nicht mehr von Stakeholdern besucht. Manager, für die Zeit zumeist ein knappes und wertvolles Gut darstellt, kommen nicht mehr zu Reviews, wenn sie da nicht dicken Mehrwert präsentiert bekommen.
Conclusio
Liebe Agilisten,
strengt Euch mehr an. Hinterfragt regelmäßig, ob das agile Tun der Teams auch wirklich seinen Zweck erfüllt. Stoisch dem Prozedere zu folgen, das die Theorie vorgibt, wird nicht den gewünschten Erfolg bringen.
Am Ende geht es immer noch darum, dass eine gesunde Kosten-Nutzen-Relation erreicht wird. Agiles Tun kostet ebenso Geld wie auch klassisches Vorgehen. Wenn der Nutzen im Verhältnis zu den Kosten nicht in einem günstigen Verhältnis steht, neigt ein Management dazu den Rotstift anzusetzen oder beschließt es ganz sein zu lassen.
