Commitment gerissen! Na und?

Sprint-Review. Das Scrum-Team hat sich für den Sprint einiges vorgenommen. Schnell stellt sich heraus: ein großer Teil davon konnte nicht erreicht werden. Doch scheinbar stört sich das Team nicht daran. – Wie sollte ein Product Owner darauf reagieren?

Dieses Szenario wurde vor kurzem bei einem OpenSpace besprochen und es sind einige Anregungen zusammen gekommen, wie darauf reagiert werden könnte. Im Kern steht dabei unsere Annahme, dass das Team vor allem deshalb relativ gleichgültig auf das Verfehlen ihres Sprintziels reagiert hat, weil sie nicht mehr erkennen konnten, dass es irgendjemanden interessiert. Die Geschäftsführung hatte sich schon seit Monaten in keinem Review mehr blicken lassen, die Ergebnisse wurden nicht nach außen kommuniziert und die Reviews wurden nur noch pro forma Team-intern durchgeführt.

  • In das Review für regelmäßige Beteiligung von Kunden und anderen Stakeholdern sorgen: Die Beteiligung der Kunden, Geschäftsführung oder anderer Stakeholder könnte dem Team aufzeigen, dass es diesen Teilnehmern wichtig ist, was an Software ausgeliefert wird.
  • Kosten eines Delays aufzeigen: Es könnte dem Team aufgezeigt werden, wie sich die Verzögerung über mehrere Sprints hinweg derart auswirkt, dass das kommende Release über deutlich weniger Funktionalität verfügt und damit auch die Zufriedenheit der Kunden klar gefährdet wird.
  • Gemeinsames Review mit mehreren Teams, wenn vorhanden: Sofern mehrere Teams im Unternehmen arbeiten, könnte ein Review mit mehreren Teams gemeinsam durchgeführt werden. Dies könnte es auch der bereits genannten Geschäftsführung ermöglichen, wieder an Review-Terminen teilzunehmen, wenn nicht jedes Team einen eigenen Termin hat.
  • Die Art des Reviews variieren, z.B. im Stil einer „Messe“: Damit das Review interessant bleibt, könnte das Setting von Zeit zu Zeit variiert werden. Einmal im Besprechungsraum mit allen gemeinsam an einem Tisch, mal im Büro des Scrum-Teams mit verschiedenen Stationen, an denen die einzelnen Arbeitsergebnisse präsentiert werden, … .
  • Kundenbeirat zum Review einladen: Wenn das Unternehmen über einen Kundenbeirat verfügt, könnte dieser einmal zu einem Review eingeladen werden, damit Kunden und Entwickler sich einander annähern und dem Team präsent wird, für wen sie das Produkt entwickeln.

Wie würdet Ihr in so einer Situation verfahren?

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Werbeanzeigen

Sprint-Review: Konstruktives Feedback geben, wenn es einmal schlecht läuft

Review / Demo / Sprint-Review / Scrum ReviewDer Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das Scrum-Team in den letzten Wochen geleistet hat und erreichen konnte. Der Product Owner ist gefordert, „seinem“ Team Feedback dazu zu geben, wie er mit den Arbeitsergebnissen zufrieden ist.

Doch wie sollte er damit umgehen, wenn es einmal wirklich schlecht gelaufen ist und das Team bei weitem nicht die Fortschritte erreichen konnte, die gemeinsam geplant wurden?

Dem Team zuhören

Zunächst einmal ist es wichtig, dem Team die Chance zu geben, aufgetretene Hindernisse im Sprint-Verlauf darzulegen. Womöglich waren sie durch größere Ereignisse im Live-Betrieb von der Arbeit am Sprint-Ziel verhindert, haben aber ihr bestes gegeben, das System am laufen zu halten. Dies kann z.B. der Fall sein, wenn ein ungewöhnlich starkes Nutzerwachstum aufgetreten ist, dass sich nicht vorhersehen ließ. Dadurch ändert sich nicht die Situation, dass das Sprintziel nicht erreicht wurde, es ist aber doch ein Unterschied, ob das Team alles gegeben hat und es trotzdem nicht geklappt hat, oder ob die Verfehlung des gemeinsamen Ziels andere Gründe hatte. Womöglich teilt das Team dabei auch wichtige Informationen mit, die dem Product Owner und dem ScrumMaster die Möglichkeit bieten, das Team bei der Erreichung zukünftiger Zielsetzungen zu unterstützen. Damit es dazu kommen kann, muss dem Team aber die Möglichkeit gegeben werden, eine Selbsteinschätzung zu geben.

Die eigene Perspektive erklären

Das Feedback des Product Owners sollte klar und verständlich zum Ausdruck kommen. Das sollte allerdings jederzeit sachlich und konstruktiv erfolgen. Wurde nicht nach den vereinbarten Prioritäten gearbeitet, kann noch einmal herausgestellt werden, warum sie so festgelegt wurden. Wurde einem Stakeholder gegenüber in Abstimmung mit dem Team eine Zusage gemacht, die nun nicht eingehalten werden kann, sollte das auch noch einmal betont werden. Die Konsequenzen des schlechten Sprintverlaufs sollten dargestellt werden. Da der Product Owner die wirtschaftliche Verantwortung für das Projekt trägt, sollte er gerade auch die betriebswirtschaftliche Sicht mit einbringen und die Interessen der Stakeholder vertreten.

Das Ziel nicht aus den Augen verlieren

Ein schlechter Sprint tut weh. Er tut dem Product Owner weh, der die wirtschaftliche Verantwortung für das Projekt trägt. Er tut dem Team weh, das seine selbst gesteckten Ziele nicht erreicht hat. Und auch dem ScrumMaster tut er weh, da ihm eine Menge Arbeit bei der Aufarbeitung bevorsteht.
Aus dieser schmerzlichen Situation heraus sollte das Ziel des Product Owners nicht sein, dass das Team sich noch schlechter fühlt. I.d.R. können sich die Teams auch selbst gut einschätzen und sind selbst unzufrieden, wenn das Sprintziel nicht erreicht wurde. Dennoch sollte er klar darstellen, wie die Erwartungshaltung war und wie das gelieferte Ergebnis sich dazu verhält. Es kann auch anhand eines Release-Burndown-Chart ermittelt werden, wie die Auswirkungen auf den Releasetermin (wenn der Umfang fixiert, das Datum variabel) oder den Releaseumfang (wenn der Umfang variabel, das Datum fixiert ist).

Gemeinsam nach Lösungen suchen

In der Retrospektive besteht noch einmal ausführlich die Möglichkeit, den zurückliegenden Sprint aufzuarbeiten und Verbesserungsmaßnahmen zu erarbeiten. Persönlich habe ich gute Erfahrungen damit gemacht, als Product Owner bei den Retrospektiven des Teams dabei zu sein. Das machen wir allerdings nur, wenn das Team dem zustimmt. Denn für einen offenen Umgang mit Kritik ist eine situative Ermöglichung der Kritik erforderlich. Die Teammitglieder müssen das Gefühl haben, dass sie Fehler offen ansprechen dürfen. Das ist meist eine Frage des Vertrauens.

Fazit

Gerade ein schlechter Sprint zeigt, ob das Team wirklich ein Team ist. Der Product Owner sollte seine Erwartungen und die Erwartungen des Stakeholder klar vertreten. Vertrauen ist die Basis für ein erfolgreiches Team.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: psd

%d Bloggern gefällt das: