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.