Ein klaffendes Loch im agilen Requirements Engineering

• Produkteigentümer haben oft nur etwa 10% ihrer Zeit für diese Rolle zur Verfügung

• Eine Faustregel besagt, dass etwa 30% notwendig sind

• Entwickler, die vorverdaute Stücke von Anforderungen erwarten, wollen 100% und mehr.

• Das Prinzip der agilen Lösung basiert auf Inspect and Adapt

• Mein bevorzugter Ansatz zur Lösung des Problems besteht darin, dass das Team die 90% im funktionsübergreifenden Modus übernimmt

Die Rolle des Product Owners (PO) ist in agilen Teams schwer zu besetzen, die Ansprüche sind riesig. Was tun, wenn der PO der Rolle nicht gewachsen ist und sich ein klaffendes Loch bei den Anforderungen auftut? Für agile Teams eigentlich kein Problem: Dogmas entsorgen und gemeinsam das Loch füllen.

„Wer schreibt denn nun die User Stories? Das muss doch der Product Owner tun, oder nicht? Aber was ist, wenn der nicht will oder kann?“ Dies ist eine Frage von vielen, die elf Praktiker im Rahmen des Zühlke Trainings «Requirements in der agilen Software Entwicklung» diskutiert haben. 

Mit Product Owner ist dabei natürlich die entsprechende Rolle aus Scrum gemeint und diese ist immer wieder mit Personen besetzt, die – allen Forderungen der Gurus zum Trotz – diese Rolle nur beschränkt ausfüllen können. Schliesslich haben Product Owners gelegentlich auch ein Tagesgeschäft, welches sie eigentlich zu 100% ausfüllt (z.B. als Führungskraft), und ein Leben ausserhalb des Berufs. Dabei besagt eine Faustregel, dass ein Product Owner ca. 30% eines Arbeitspensums in diese Rolle investieren sollte. 

Nun kann sich natürlich das Team darüber ärgern und mit dem allseits beliebten Spruch „die Anforderungen sind unklar, so können wir nichts tun“ den Product Owner zur Mitarbeit zwingen. Diese Forderung ist allerdings unrealistisch und heizt den Konflikt nur weiter an. Der Product Owner ist verantwortlich, dass Requirements Engineering gemacht wird. Es ist nicht seine Aufgabe, dem Team die Anforderungen als User Stories vorzukauen. Das wäre dann auch schnell eine 100% Aufgabe.

Zusammengefasst der dargelegte Systemkonflikt: Product Owner haben oft nur ca. 10% Zeit für ihre Rolle. Die Faustregel besagt ungefähr 30% sind notwendig. Entwickler, die auf die vorverdauten Anforderungshäppchen warten, wollen 100% und mehr. 

Genau wegen solchen Situation wollen wir agil sein! Derartige systemische Konflikte sind nun einfach täglich Brot. Das agile Prinzip zur Lösung ist Inspect und Adapt. Also Situation verstehen und dann weg mit methodischen Dogmas, mit alten Hüten und anderen die Schuld in die Schuhe schieben. Hin zur Frage: Wie kriegen wir das bestmögliche Produkt hin?

Bei diesem Konflikt zeigt die Analyse ein Loch im Requirements Engineering von 90%. 

Also werden 90% der Aufgaben im Bereich Requirements nicht gemacht. Dabei enthielten 100% insbesondere auch die folgenden:

1. Gemeinsame Vision schaffen
2. VIPs ins Boot holen
3. Scope im Griff halten (Agile Slang: Backlog Management)
4. Nutzen und Kosten optimieren (Agile Slang: Conversation. Im RE auch bekannt unter Requirements Negotiation)
5. Lösung im Detail stimmig ausarbeiten (User Stories Slang: Card, Conversation, Confirmation) 

Ein 10% PO wird mit (1) und (2) bereits gut ausgelastet sein und kann im Groben bei (3) mitdiskutieren. Doch schon ein PO, der (1) und (2) leistet, bringt einen grossen Gewinn für das Team! 

Hier ein paar von den Teilnehmern in der Praxis angewandte Ansätze, wie die fehlenden 90% überbrückt werden können:
•    Product Owner ersetzen mit jemandem, der 100% leisten kann.
•    Product Owner aus dem Tagesgeschäft zu 30% freischaufeln. 
•    Product Owner Proxy einsetzen, der vor allem bei den Aufgaben (3) und (4) mitträgt.
•    Fachvertreter ins Team holen, insbesondere für (5).
•    Business Analysten ins Team holen, insbesondere für (3) bis (5).
•    Anderes Rollenmodell verwenden.
•    Team übernimmt die 90% als cross-functional Team.

Mein persönlicher Favorit? Der letzte Ansatz. 

Abschliessend bringt ein Teilnehmer dann seine Erkenntnis auf den Punkt: RE sei im agilen Umfeld ja genauso essentiell wie im nicht agilen. Es werde nur nach agilen Prinzipien durchgeführt und beispielsweise mit User Stories gesteuert. Und als eine Quintessenz für einen Kurs zu diesem Thema kann man diese Aussage auch getrost stehen lassen.

Vielen Dank an die Teilnehmer für die spannenden Diskussionen!

Produkteigentümer haben oft nur etwa 10 % ihrer Zeit für diese Rolle zur Verfügung. 
Eine Faustregel besagt, dass etwa 30% notwendig sind. 
Entwickler, die vorverdaute Stücke von Anforderungen erwarten, wollen 100% und mehr.
Das Prinzip der agilen Lösung basiert auf Inspect and Adapt
Mein bevorzugter Ansatz zur Lösung des Problems besteht darin, dass das Team die 90% im funktionsübergreifenden Modus übernimmt.