Statt auf bessere Anforderungen zu pochen, sich besser zu mĂ€ĂŸigen Anforderungen aufstellen

Podcast Scrum meistern Folge "Statt auf bessere Anforderungen zu pochen, sich besser zu mĂ€ĂŸigen Anforderungen aufstellen"

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.

  1. Spannende Themen werden zurĂŒckgestellt, obwohl genau diese bei den Produkten den Unterschied machen

  2. 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

  3. 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

  4. Fachbereiche, die ihre Anfragen vorauseilend extrem granular und mit genauen technischen Formulierungen stellen (hier machen wir den Bock zum GĂ€rtner)

  5. 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?

  6. Dabei rutschen die Entwickler eher in die Rolle einer verlÀngerten Werkbank und sind doch stÀndig unzufrieden und am meckern

  7. 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 😉

 

 

Newsletter

Halte dich auf dem Laufenden

Community Events

Wir organisieren regelmĂ€ĂŸig Events in denen wir gemeinsam Themen aufarbeiten und uns Austauschen wollen.

Ralf Kruse