Kurzgeschichten

Kleine Stories sind das, was wir uns wünschen. Aber warum? Was bringt uns das? Und warum schafft es der eine Product Owner, solche Kurzgeschichten zu schreiben und der andere schreibt ganze Romane? Diese Frage beschäftigte mich in einem Projekt, in dem wir skaliert mit mehreren Scrum Teams und daher auch mit mehreren Product Ownern arbeiteten.Um diese Frage zu klären, suchte ich einen dieser Product Owner auf, von dem ich wusste, dass er sich für kleine Stories ausspricht und auch solche schreibt. Im entsprechenden Scrum-Team herrschte sogar die Absprache, dass Stories mit mehr als 5 Storypoints nicht in einen Sprint aufgenommen werden. Das Team arbeitete in 2-Wochen-Sprints. Der Product Owner, nennen wir ihn „Peter“, lieferte ein interessantes und sehr anschauliches Argument für das Schreiben kleiner Funktionalitäten, das ich genauer beleuchten möchte. Er sagte: „Ich stelle mir vor, dass mein Scrum Team eine kleine, eigenständige Firma ist, die direkt an einen zahlenden Kunden liefert. Dieser Kunde bezahlt natürlich nur für fertige und laufende Funktionalität, nicht für Entwicklerstunden. Wenn nun aus unerfindlichen Gründen der Strom ausfällt, das Netzwerk lahmgelegt ist oder andere unvorhergesehene Dinge eintreten, so bin ich bei kleineren Stories einfach sicherer, dass eine Arbeit und damit Funktionalität auch abgeschlossen und somit bezahlbar ist. Die Gefahr, dass eine Story nicht abgeschlossen ist, weil sie zu groß ist, ist mir wegen der schwierigeren Planbarkeit einfach zu groß und ich möchte die Firma nicht gefährden."Dieses Argument fand ich sehr einleuchtend. Natürlich würde ein Geschäftsführer einer kleinen Entwicklerfirma mit sagen wir sechs Entwicklern nie etwas anderes wünschen. Sein eigenes Geld und die Arbeitsplätze seiner Mitarbeiter sind ihm natürlich wichtig. In sehr großen Unternehmen, wo Kunden, Stakeholder und Manager oft weit weg zu sein scheinen, ist das möglicherweise anders. Es gibt keinen unmittelbaren Bezug und somit fällt es schwerer, sich in die Lage der kleinen Firma um die Ecke zu versetzen. Umso besser also das Beispiel von Peter.Auch auf die Frage, warum nun der eine Product Owner kleinere Stories schreibt und der andere nicht, gab es aus Peters Sicht eine interessante und gar nicht so sehr fachliche Antwort: Er scheue sich nicht, im Gespräch mit dem Kunden in die Rolle des Beraters zu schlüpfen, der sich in den Kunden hineinversetzen kann. In deser Beraterrolle regelt er die Dinge so, dass sie funktionieren und nicht einfach nur gemacht werden, wie der Kunde es wünscht. Ich will nicht sagen, dass Peter seinem Kunden wiederspricht - er wagt es, auf sachlichem Niveau sinnvolle Diskussionen mit dem Kunden zu führen, um die richtige Lösung zu finden, ja sogar zu empfehlen. Aus Peters Sicht gibt es eben auch jene Product Owner, die den Weg des geringsten Widerstandes gehen, konfliktscheu sind und Diskussionen aus dem Weg gehen, was durchaus menschlich ist.Für mich wird aber dabei deutlich, dass es trotz aller Technik auch um das Thema Persönlichkeit und Charakter geht. Es ist durchaus nützlich, wenn man es auch mal wagt, sich auf sinnvollem Niveau „unbeliebt“ zu machen und Diskussionen einzugehen. Im Sinne des Produkts. Aus meinen Erfahrungen als Berater kann ich jedenfalls sagen, dass jeder Kunde dankbar ist, wenn man im Sinne des Nutzens auch mal „widerspricht“ und einen anderen Lösungsvorschlag empfiehlt.Provokativ könnte man also sagen: Die Tatsache, ob jemand große oder kleine Stories schreibt, beruht durchaus auf persönlichen Gründen und nicht nur auf technischen. Zusammengefasst und schlussendlich also die Frage: Was bringen uns kleinere Stories?

• Bessere Planbarkeit
• Höhere Zuverlässigkeit der Estimation
• Schnellerer Abschluss
• Größeres Verständnis der Story
• Häufigere Erfolgserlebnisse.
• Zufriedenere Kunden und Mitarbeiter
• Mehr Wirtschaftlichkeit

Ein Product Owner trägt die Verantwortung für die Profitabilität eines Produkts. Viel Spaß also beim Schneiden.