Scrum – the hard parts

Meine persönliche Favoritenliste der “hard parts” von Scrum und wie Sie sie gekonnt umschiffen. Weitere Inspirationen finden Sie hier: https://www.scrum.org/ScrumBut.

Nur die Entwickler schätzen

Laut Scrum Guide dürfen nur die Mitglieder des Entwicklungsteams Aufwände schätzen, also weder Scrum Master, noch Product Owner.

Als Product Owner sollten Sie daher versuchen, auf subtile Art und Weise die Schätzungen in Ihrem Sinne zu beeinflussen, indem Sie Fragen stellen: “Das schafft ihr doch in zwei Wochen, nicht wahr?”. Oder: “Ich kann mir nicht vorstellen, dass das viel Aufwand ist. Sieht das jemand anders?”.

So behalten Sie auch auf stürmischer See das Ruder fest in der Hand!

Done

Scrum fordert als Ergebnis des Sprints ein “potentiell auslieferbares Produkt-Inkrement”. Gemeint ist damit zum Beispiel eine lauffähige und getestete Software. Weil dies zu den härtesten Teilen von Scrum gehört, gibt es gleich mehrere Workarounds, mit denen Sie sich das Leben etwas einfacher machen.

Erstens: erklären Sie auch andere Artefakte zu möglichen Sprint-Ergebnissen. Wie wäre es mit einem abgeschlossenen Analyse- oder Architekturdokument? Damit das funktioniert, müssen Sie nur die Definition of Done anpassen.

Zweitens, ganz wichtig: vergessen Sie nicht die Phasen vor Scrum und nach Scrum.

Vor Scrum sollte zunächst eine mehrmonatige Planungsphase stattfinden, in dem der Weg durch die Instanzen beschritten wird, bis das Projekts genehmigt und der Scope fixiert ist.

Nach Scrum sollte eine mindestens mehrwöchige Testphase durch den Fachbereich erfolgen, bis das Produkt schließlich ausgeliefert werden kann – dieser Workaround ist besonders dann zielführend, wenn Sie auf jede Form von automatisiertem Test, Integration oder Deployment verzichten.

Der Product Owner priorisiert

Laut Scrum Guide ist der Product Owner derjenige, der das alleinige Entscheidungsrecht über die Priorisierung des Product Backlogs hat.

Das ist ungemütlich, weil damit dem niedrigen Management auf einmal eine enorme Entscheidungskompetenz zugesprochen würde – echte Manager halten sich aber von Entwicklern fern, um auch unliebsame Entscheidungen treffen und durchsetzen zu können.

Zum Glück gibt es aber mittlerweile etablierte Rollen wie den “Proxy Product Owner”. Richtig gelebt hat dieser keinerlei Entscheidungskompetenz, sondern gibt lediglich die Ansagen von oben an die Entwickler weiter und “übernimmt die Verantwortung”, falls etwas schief läuft.

Die anstrengende direkte Kommunikation zwischen Product Owner und Entwicklungsteam entfällt, der Entwicklungsprozess wird entschlackt.

—

Commercial Break: Wollen Sie Scrum in seiner Urform kennenlernen oder haben Sie weiteren Klärungsbedarf, was die agile Entwicklung angeht? Dann besuchen Sie eines unserer Trainings (http://www.hood-group.com/agile/training/).

Bertil Muth

Kontaktieren Sie Bertil Muth

Bertil Muth arbeitet als Agiler Coach, Scrum Master und Trainer. Mit Leidenschaft setzt er sich für konstruktive Zusammenarbeit, dezentralisierte Entscheidungsfindung und technische Exzellenz in der Produktentwicklung ein.