Ist der Product Backlog ein Teambuilding Werkzeug

Ist der Product Backlog ein Teambuilding Werkzeug?

Die Problemteams

Wenn ihr schon Erfahrungen mit unterschiedlichen Teams gemacht habt, ging es euch wahrscheinlich wie mir. Bei  manchen Teams funktioniert alles reibungslos, Teambuilding passiert quasi von selbst und bei anderen beißt man sich die Zähne aus. Unsere „Problemteams“. Egal ob als Teammitglied, Führungskraft, Team Lead, Scrum Master oder Product Owner. 

Man hört sich in diesen Fällen oft sagen „Bei dem Team ist eh alles umsonst“, “Die verstehen agil ja gar nicht“ oder die „Wollen ja gar nicht“. Man sucht den Fehler bei den Teams oder besser gesagt deren Mitgliedern. Auch ich habe diesen Fehler, vor allem in meinen Anfangszeiten als Scrum Master – gemacht. Heute glaube ich daran, dass es in den meisten Fällen an den Rahmenbedingungen, bzw der Umgebung liegt, die wir diesen Teams bieten. 

Eine dieser Rahmenbedingungen ist der Produkt Backlog. Der Einfluss den dieser auf Teambuilding hat wird oft unterschätzt, denn er ist weit mehr als die “reine ToDo Liste” all unserer Aufgaben und Ideen. Für mich ist er ein zentraler Bestandteil für Teambuilding. 

Der Einfluss von Product Ownership

Der Einfluss von einem gut gestalteten Product Backlog auf den Erfolg von Teambuilding ist mir im Zuge meiner Einreichung für den Certified Team Coach (CTC) der Scrum Alliance bewusst geworden. Dafür muss man sich intensiv mit seinen Glaubenssätzen und seinem Zugang zum Begleiten von Teams und Organisationen auseinandersetzten. 

Bei der Reflektion über meine bisherigen Erfahrungen hat sich schnell herauskristallisiert, dass die erfolgreichen Teams bzw. jene bei denen  ich viel Einfluss hatte, eins gemeinsam hatten: Einen Produkt Backlog der Teambuilding unterstützt. Bei den Teams wo ich auf Widerstand mit Scrum und Agilität gestoßen bin hatte der Backlog eine Struktur die nicht so unterstützend war. 

Warum ist Backlog Refinement wichtig für Teambuilding?

Wenn wir uns gemeinsam darum bemühen den Produkt Backlog in einer für uns passenden Qualität und passendem Umfang aufzubereiten, schaffen wir die Basis, um gemeinsam erfolgreich zu sein. Backlog Items werden nicht mehr kurz vor dem Sprint Planning „über den Zaun geworfen“ und somit nehmen wir Risiko und Unruhe aus den Iterationen heraus. 

Für mich sind dabei zwei Gründe im Vordegrund:

1. Auch die besten Prozesse bringen nichts, wenn sie mit schlechter Qualität befüllt werden.
2. Gemeinsame Aktivitäten und Ziele schweißen zusammen.

Prozesse

Wir können die besten Prozesse und das beste Team haben, aber wenn dieses Team nicht mit der passenden Qualität gefüttert wird, dann dürfen wir uns auch nicht wundern, wenn wir nicht die Qualität am Ende herausbekommen, welche wir uns gewünscht haben. 

Um dies zu erreichen, müssen die Teammitglieder aber in den Prozess des Backlog Refinements involviert sein. Natürlich hängt es von der Rolle des Teammitglieds ab, zu welchem Zeitpunkt man involviert wird. Zum Beispiel werden Product Owner, Produktmarketing und Business Analysten sicher früher involviert sein als Entwickler. 

Mein Gradmesser für erfolgreiches Backlog Refinement ist die Dauer des Sprint Planning Topic 2 mit der Frage: Welche Items übernehmen wir in den Sprint. Diese Fragestellung sollte uns nicht mehr als 30 Minuten beschäftigen. Das schaffe ich aber nur, wenn alle im Team die Backlog Items der nächsten zwei bis drei Sprints kennen und ich mich auf die Frage wieviele Items schaffen wir in der nächsten Iteration fokussieren kann. 

Wenn man im Gegensatz dazu noch Details klären, Teammitglieder auf einen Stand bringen oder gar schätzen muss, explodiert das Meeting unnötig und ich nehme Risiko mit in den Sprint. 

Mit meinen Teams lebe ich meist noch die strikte Trennung der Planungsmeetings wie sie früher im Scrum Guide waren (Sprint Planning I und Sprint Planning II) um den Fokus auf die jeweilige Aufgabe zu halten. 

Gemeinsame Ziele und Aktivität

Den Vorteil den ich bekomme, wenn wir gemeinsam an der Gestaltung des Backlogs arbeiten ist, dass es „unser“ Backlog ist und nicht die Wunschliste von jemand anderen. So können wir gemeinsam unserer gesetzten Ziele verfolgen und da wir Risiko minimiert haben, steigt auch noch die Chance gemeinsam Erfolge im Sinne eines erfolgreich abgeschlossenen Sprints zu feiern. 

Mein Fazit ist: Wenn wir unsere Hausaufgaben im Refinement gut erledigen, können wir einen viel fruchtbareren Boden für unsere Teams schaffen. 

Leading Teams

In seinem Buch Leading Teams hat Richard Hackman ein Modell für effektive Teams beschrieben. Diesen schreibt er drei Merkmale zu:
) Sie produzieren von Kunden akzeptierte Produkte
) Die Fähigkeiten des Teams nehmen zu und damit auch die Leistungsfähig
) Die individuellen Teammitglieder lernen konstant


Um in diesen Zustand zu kommen. Müssen fünf Grundvoraussetzungen geschaffen werden:
 

) Es muss sich um ein echtes Team handeln

) Das Team brauch eine überzeugende Vision oder Richtung

) Es braucht ermöglichende (enabling) Strukturen,

) Einen unterstützenden Kontext und

) Coaching durch Experten

Echte Teams

Ein echtes Team ist halbwegs stabil und die  Mitglieder teilen sich die Verantwortung für die Aufgaben und das Erreichen der gesetzten Ziele. Zudem arbeiten sie gemeinsam an diesen Aufgaben! Dadurch sind sie weit mehr als eine Ansammlung von Personen die zufällig im selben Raum arbeiten oder denselben Teamnamen haben. 

Ermöglichende Strukturen

Die Prozesse und Strukturen in Team müssen es ermöglichen, dass die Arbeiten gemeinsam ausgeführt werden können. 

Überzeugende Vision

Die gesteckten Ziele sollten klar, herausfordernd und wichtig genug sein, um das Team zu motivieren. Locke und Latham haben sich im Zuge der Goal Setting Theorie intensiv mit dem Einfluss von Zielen auf Teams auseinandergesetzt. 

Unterstützende Organisation

Um effektiv sein zu können, benötigen Teams Unterstützung aus dem Umfeld, indem sie eingebettet sind. In der Regel ist das die übergeordnete Organisation. Zum Beispiel benötigen sie Budget, Materialien, Boni basierend auf Teamerfolg, leichter Zugriff auf die nötigen Informationen, Training und technische Unterstützung.  

Verfügbares Coaching durch Experten

Effektive Teams haben Zugang zu einem Mentor oder Coach der dem Team hilft die täglichen Herausforderungen zu überwinden ohne das Team selbst aus der Verantwortung zu entlassen. Das können Themen aus dem Business, Team Strukturen und Prozesse sowie interpersonelle Fragestellungen sein. 

Interessant ist dabei, dass Ruth Wageman in ihrer Studie herausgefunden hat, dass der erfolgreiche Einsatz von Coaching von zwei Faktoren maßgeblich beeinflusst wird. 

Effektives Coaching

Offensichtlich ist, dass es von der Qualität der Unterstützung und den Interventionen selbst abhängig ist. Der Coach und die vom Coach eingesetzten Methoden müssen zum Team passen. 

Team Design

Der zweite Faktor ist, dass es einen Unterschied macht ob das Team im Sinne der gerade beschriebenen Faktoren schon vor dem Coaching gut aufgestellt ist. In einem Blogpost empfiehlt sie daher, dass Leadership Teams 60 % auf die Vorbereitung, 30% auf den Launch und 10% aufs Coaching verwendet werden sollte. 

In der Praxis musste ich leider feststellen, dass viel zu oft Teams „schnell“ auf die Reise geschickt werden und wichtige Fragen – wie zum Beispiel die Vision des Teams – erst im Nachgang geklärt werden. Dadurch entstehen viel Unruhe und Aufwand den man deutlich verringern könnte, wenn man die wichtigen Fragen rechtzeitig klärt. 

Wie kann ich den Product Backlog sinnvoll für Teambuilding gestalten?

Natürlich kommen bei der Gestaltung des Product Backlogs viele Dinge zusammen und wenn ich dabei eine Veränderung herbeiführen möchte, braucht es manchmal auch den Rückhalt von außen. ABER ich glaube auch daran, dass man als Scrum Team einiges selbst in der Hand hat. Wenn sich Product Owner und Scrum Master zusammentun kann man zum Beispiel über das Splitten und Priorisieren von Backlog Items einiges erreichen! 

Splitten von Backlog Items

Wenn wir uns das Beispiel der User Stories anschauen, dann sind “richtig” geschriebene Stories immer aus der Sicht des tatsächlichen Nutzers geschrieben. Für viele mag das rumreiten auf dem Schreiben von korrekten Stories nur der Hang zur Perfektion sein. 

Doch wenn man das auch aus der Sicht von Teambuilding betrachtet, erfüllen sie einige wichtige Kriterien: 

Wenn wir ein Backlog Item aus Kundensicht abgeschlossen haben, gibt es für unsere Nutzer neue funktionstüchtige Features, die sie verwenden können. Ein schönes Erfolgserlebnis, dass wir als Team feiern können. Vor allem da wir mit ziemlicher Sicherheit mehrere (oder alle) Teammitglieder zur Fertigstellung benötigt haben, weil nicht jeder im Team dieselben Fähigkeiten und Fertigkeiten besitzt. Noch schöner wird es, wenn wir das regelmäßig schaffen. 

Gut geschnittene Items “zwingen” uns also zu Teamarbeit und wir können fertige Arbeit feiern. 

Priorisierung

Über die Priorisierung kann ein Product Owner auch einiges zur Teamarbeit beitragen. Ich hatte einmal einen Product Owner der zu mir 1-2 Tage vor Sprint Beginn gesagt hat: “Ich brauch noch ein Backlog Item für Person X, sonst hat er nichts zu arbeiten”. Ein klares Symptom, dass dieses Team nicht als Team Backlog Items abgearbeitet hat, sondern jeder für sich. Die Frage die damit einher geht: Waren das immer die wertvollsten Backlog Items? Oder wurde eher nach Skill, Vorlieben, etc. priorisiert. 

Wenn nach Wert priorisiert wird müsste die zuvor angesprochene Person ev. aus dessen Komfortzone gehen und in anderen Bereichen (Frontend,Backend, …) oder anderen Bereichen des Codes (andere Komponenten) lernen um gemeinsam mit anderen Kollegen des Teams Aufgaben zu erledigen. 

Manchmal geht man dann lieber den Weg des geringeren Widerstands und sucht Backlogitems die “passend” sind anstatt hart zu bleiben und bringt damit das Team um Chance zu lernen als Team zu agieren. 

Fazit

Daher glaube ich daran, dass der Backlog ein wichtiges Werkzeug für Teambuilding ist, aber leider nur als unserer Liste an Aufgaben gesehen wird. Wenn man den Backlog aber nicht richtig gestaltet, kann Teambuilding sehr mühsam werden. 

Zum Nachschauen sein Talk bei der Agile Austria Conference 2022 zum Thema:

YouTube

By loading the video, you agree to YouTube's privacy policy.
Learn more

Load video

TEILEN SIE DIESEN BEITRAG MIT IHREM NETZWERK

Scroll to Top