Dazu behandeln wird in der heutigen Folge:
- Welche Dysfunktionen entstehen durch das pochen auf ordentliche Anforderungen?
- Die drei Eckpfeiler, die eine Voraussetzung sind, damit wir mit leichtgewichtigen Anforderungen arbeiten können.
- Worauf es ankommt, den Weg zu leichtgewichtigen Anforderungen zu finden.
In erstaunlich vielen Umgebungen erlebe ich, dass immer mehr nach besseren Anforderungen geschrien wird und vieles einfacher wäre, wenn nur endlich mal diese ordentlichen Anforderungen gegeben wären.
Allerdings arbeite ich jetzt seit mehr als 10 Jahren als externer Begleiter und ich kenne leider keine Umgebung, wo nur ansatzweise diesem Wunsch nachgekommen wird. Mehr noch, ich habe folgende Dysfunktionen entstehen sehen aus dieser Forderung heraus.
Spannende Themen werden zurückgestellt, obwohl genau diese bei den Produkten den Unterschied machen
Entwickler sehen viele Anforderungen erst auf den letzten Drücker, wo viele Entscheidungen schon ohne sie getroffen wurden und jetzt Druck aufgebaut wird diese dann in dem angedachten Plan auch umzusetzen
Product Owner, die in der mundgerechten Aufarbeitung der Anforderungen ausgelastet bis überfordert sind und so keine Zeit mehr haben für die strategische Ausrichtung des Produktes
Fachbereiche, die ihre Anfragen vorauseilend extrem granular und mit genauen technischen Formulierungen stellen (hier machen wir den Bock zum Gärtner)
Eigentlich schaffen wir so in unserer Entwicklung eine sequentielle Abarbeitung, wie im Wasserfall, nur wenn dies vorher nicht funktioniert hat, warum denn bitte jetzt in Scrum?
Dabei rutschen die Entwickler eher in die Rolle einer verlängerten Werkbank und sind doch ständig unzufrieden und am meckern
Besonders gut kann man die Auswirkung dieser Arbeitsweise im Sprint Review sehen, was zu einem ziemlich öden Story-abhack-Meeting wird, statt eines lebhaften Austausches des aktuellen Produktes und der Reflexion der Produktausrichtung
Mit der eigentlichen Idee einer agilen Arbeitsweise hat das dann wenig zu tun. So wird Scrum eher wie ein Wasserfall mit einem Kringel in der Mitte, in dem wir uns vorgaukeln zu reflektieren.
Diese Probleme sind nicht neu, wir haben es mit der Forderung nach ordentlichen Anforderungen schon vor Scrum nicht geschafft besser Produkte zu entwickeln und auch in Scrum wird das so nicht funktionieren.
Statt auf ordentliche Anforderungen zu pochen, ist die Idee in Scrum, sich zur Arbeit mit mäßigen Anforderungen aufzustellen!
Was uns zu der spannenden Frage bringt, wie können wir uns richtig zu mäßigen Anforderungen aufstellen?
3 Säulen für die Arbeit mit leichtgewichtigen Anforderungen
- In einem Scrum Team haben die Entwickler alle notwendigen Fähigkeiten, um aus einer leichtgewichtigen Anforderung mit Nutzersicht eine einsetzbare Lösung zu entwickeln
- Der Sprint gibt ihnen Halt und wir lernen aus den geschaffenen Ergebnissen Schritt für Schritt
- Splitting und lernen aus Inkrementen
- Vertrauensverhältnis zwischen Product Owner und Entwicklern stärken
- Rückfragen während des Sprints
- Autorität für Entscheidungen klären
Enabler, um dort hinzukommen
- Refinement: Das Einbinden der Entwickler auch schon bei frühen groben Backlog Items forcieren, insbesondere durch das gemeinsame frühe schätzen, aus dem wir dann passende Splittings motivieren können
- Das Ziel ist nicht nur die Vorbereitung des nächsten Sprints
- Sprint Review: Die Aufgabe des POs ist es, den Kontext zu vermitteln an dem sich die Entwickler orientieren können. Wenn hier nur der PO eine Einordnung vornehmen kann und dieser dann das Review braucht, um Backlog Items abzunehmen, dann ist dies eigentlich nur ein klarer Indikator wie dringend hier Handlungsbedarf besteht
- Sprint Planning:
- Ausblick schaffen und genügend Optionen sammeln
- Absprache mit den Entwicklern machen, dass sie die Verantwortung im Sprint übernehmen
Der beste Ansatzpunkt dabei ist für mich aber, wenn wir es schaffen mit dem Product Owner sehr grobe frühe Anforderungen für einen Workshop vorzubereiten. In diesem Workshop klären dann gemeinsam, wie wir uns effektiv auf Basis der obigen Punkte effektiver aufstellen können. Fokus hier ist, nicht in alte Muster zurückzufallen, sondern diese die für uns neue Herangehensweise konsequenter zu nutzen.
-> Im CSM mache ich Mini-Sprints, wo wir mit mäßigen Items arbeiten
-> Im CSPO schaffen wir den Kontext, wie wir als Product Owner den Kontext aufarbeiten ohne übergriffig zu werden
Wenn du mehr erfahren willst, dann komm doch mal in eines unserer kostenlosen Webinare und mach dir ein eigenes Bild -> https://enablechange.de/webinare/
Bis bald 😉
