Auch wenn's mal wieder länger dauert: Pull die wichtigsten Themen zuerst

Vor kurzem erläuterte ich den Umgang mit einem Product Backlog in einem skalierten Umfeld, das sich mitten in der Umstellung vom klassischem Projektvorgehen zur agilen Entwicklung befindet.Das Product Backlog bezieht sich auf das Gesamtprodukt und ist auch dementsprechend priorisiert. Die Teams arbeiten somit an den Top-Prio-Einträgen des Backlogs und stellen diese fertig, bevor sie anfangen, neue Items zu bearbeiten. Dabei ist, und hier liegt die große Änderung zu vorher, die Anzahl der Items, die gleichzeitig bearbeitet werden "dürfen" begrenzt. So viel zur Theorie.Jemand aus dem Teilnehmerkreis brachte dann den Einwand: "Wenn die Teams nur noch das nächste Item im Backlog bearbeiten "dürfen" hat das für mich aber nichts mehr mit PULL-Prinzip zu tun."Diese Äußerung machte mich im ersten Moment etwas verdutzt, da ich mich freute, dass wir nun endlich damit anfangen würden, dass sich jedes Team immer etwas von oben aus dem Backlog pullt.Definiert man das PULL-Prinzip "inhaltlich" - also so, dass sich ein Team immer genau das aus dem gesamten Backlog zieht, was es am schnellsten, am liebsten oder am besten umsetzen kann, wenden wir uns tatsächlich davon ab. Denn es führt leider in der Regel genau zu dem altbekannten Anforderungsstau. Es gibt viele Anforderungen, die nur ein Team umsetzen kann, diese sind aber sehr wichtig für das Business. Andere Teams pullen sich diese für das Business wichtigen Items nicht, weil sie wissen, dass es ein anderes Team gibt, das mehr Skills in dem Bereich hat, es anstrengend ist, sich durch fremden Code zu wühlen oder weil die notwendige absichernde Testautomatisierung nicht vorhanden ist, die verhindern würde, dass etwas Schlimmes passiert.Aus diesem Grund definiert man das PULL-Prinzip "zeitlich". Das Team entscheidet, wann es so weit ist, sich ein nächstes Item zu ziehen - nicht aber unbedingt welches. Wohlwissend, dass man nicht immer gleich alle Skills für die Herausforderungen des nächsten Items zur Verfügung hat, gibt man den Teams die Zeit, die sie brauchen, um es fertig zu machen und im Gesamtprodukt zum Funktionieren zu bringen. Einer der Reize des Commitments ist genau das: nicht alles vorab zu können, aber es schaffen zu wollen und einen Weg ausfindig zu machen.Damit will ich nicht sagen, dass es immer sinnvoll ist, dass alle Teams alles können und sich jedes Item ziehen müssen, das direkt an erster Stelle steht. Trotzdem plädiere ich dafür, an den für das Business aktuell wichtigsten Themen zu arbeiten - auch wenn's mal etwas länger dauert.Schnapp Dir nen Snickers und accept the challenge! Die ersten Male werden hart, aber das Durchbeißen lohnt sich.

Agile Toolbox
Scrum
Scrum-Begriffe
bgloger-redakteur
January 28, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen