Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Die Kraft der Unzufriedenheit

Auf dem Weg zur Agilität haben wir glücklicherweise immer wieder mit den Widrigkeiten eingekrusteter Strukturen, langen, scope-fixen Releases, dem magischen Dreieck etc. zu tun. Releaseplanungen und Backlog Groomings unter diesen Bedingungen durchzuführen, macht besonders viel Spaß. Man muss nämlich das Beste draus machen und gleichzeitig versuchen, den nächsten Schritt Richtung Produktorientierung zu gehen.

Was es für einen Sinn macht, Backlog Groomings, Releaseplanungs-Meetings zu veranstalten und ein gemeinsames Releaseboard zu pflegen?

Im besten Fall halten die Teilnehmer der Meetings diese irgendwann für so sinnlos und nervig, dass sie selbst anfangen, sich Gedanken darüber zu machen, wie man die Zeit sinnvoller gestalten kann. Wichtig dabei ist aber, dass man sie nicht aus der Pflicht entlässt, dass sie die Zeit gemeinsam gestalten müssen.

Bei einem unserer Kunden haben wir damit angefangen, dass alle Teams im skalierten Umfeld ihre Backlogs teamweise für die nächsten drei Sprints auf Story-Ebene auf einem riesigen Board plakatierten. Alle zwei Wochen veranstalteten wir Meetings, in denen die jeweiligen POs die Stories vorstellten, an denen ihr Team in den nächsten drei Sprints arbeiten würde. So weit im Voraus sollte das Backlog ja einen recht stabilen Stand haben. Um diese Planung machen zu können, hatten die POs aber im Vorfeld die Aufträge schon in mehr oder weniger technische Arbeitspakete geschnitten und auf die Teams/Komponenten aufgeteilt. Im Meeting selbst wurden also keine Abhängigkeiten mehr entdeckt und bei der Vorstellung der User Stories für die nächsten drei Sprints schliefen die POs entweder aus Höflichkeit oder weil wir vor dem Board standen nicht ein.

Zuerst wurde viel über das Meeting gemeckert. Es würde nichts bringen, man würde ja eh auf die anderen POs zugehen, wenn man etwas von ihnen bräuchte. Außerdem sei es zu aufwendig, die Stories auszudrucken und aufzuhängen… Als klar wurde, dass wir das Meeting trotzdem beibehalten würden, wählten sie eine andere Strategie. Statt meckern: besser machen.

Anstatt schon vorab alles zu klären und auf die Teams zuzuordnen, will man nun versuchen, die unterschiedlichen Themen mit initialen User Stories in der Priorität des Company Backlogs abzubilden. Das Meeting kann dann dazu dienen sich bewusst zu machen, welche Aktivitäten nötig sind, um das Thema abzuschließen. Außerdem kann sofort gesehen werden, ob an den richtigen Prozessen gearbeitet wird bzw. ob sich ausreichend Teams aus den oberen Themen Stories ziehen. Die Endlichkeit der Wand führt außerdem automatisch zu einer Fokussierung. Es finden vielleicht gar nicht alle Themen Platz. Die wichtigsten können aber aufgehängt werden. Merkt man, dass die kleinen Stories für die Top-Themen ausgehen, kann man in kleineren Gruppen die Detaillierung durchführen. Burndown-Charts auf Themen-Ebene werden möglich. Die nächste Stufe könnte sein, nicht mehr Themen abzubilden, sondern vielleicht die Kernprozesse im Backlog zu haben, an denen Änderungen gemacht werden. Die Priorität richtet sich dann evtl. danach, welcher Prozess am wichtigsten für das Business ist, oder wo die größten Einsparungen realisiert werden können.

Sind das Meetings und Artefakte wie sie im Buche stehen? Sicher nicht, aber es sind Mittel, die dem PO-Team helfen, den Überblick zu behalten und anderen zu geben.
Welche Möglichkeiten habt ihr durch Unzufriedenheit mit dem Status quo gefunden?

  • bgloger

    Die Macht der Transparenz … ich finde es toll, dass Du gezeigt hast, dass das Festhalten am Prozess, dazu geführt hat, etwas besser zu machen.

  • Eddy

    Unzufriedenheit ist bei uns eigentlich immer der Startschuss für Veränderung. Allerdings ist es bei uns nicht üblich, an einem Meeting, was allgemein für wenig sinnvoll erachtet wird, festzuhalten. Es wird dann häufig die radikalere Variante gewählt, das Meeting nach ein paar Runden abzuschaffen. Falls es wieder gebraucht wird, kommt es eben wieder in den Kalender. Wir hatten eine zeitlang ein Epic Planning, was ungefähr dem entspricht, was du beschreibst. Da unsere Aufgaben irgendwann immer heterogener geworden sind, war es nicht mehr richtig möglich, Epics zu planen. Das Meeting wurde also erstmal ausgesetzt. Später dann kam natürlich der Wunsch auf, Aufgaben fokussierter abschließen zu können und ein homogeneres Aufgabenumfeld zu schaffen.