👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine Wissenslücken, Erfahrungen und Ansichten geändert. Dennoch stehe ich hinter den Aussagen, die ich damals getätigt habe. Selbst dann, wenn ich sie mittlerweile anders tätigen würde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel Vergnügen!
Wie wir einen Impediment Backlog auch im klassischen Projektmanagement so einsetzen können, dass wir unsere Issues in den Griff bekommen.
Von unliebsamen Überraschungen #
Stellt Euch vor, Ihr managt ein Projekt, in dessen Verlauf kein einziges Problem auftaucht. Keine Issues, keine unabgedeckten Risiken, nichts. Eine schöne Vorstellung, oder? Und nun zur Realität. Jede und jeder von uns stößt im Laufe eines jeden Projektes auf Probleme und Hindernisse. Selbst die beste und feingraulierteste Risk/Impact Propability Chart kann nicht alle Risiken am Radar haben. Und auch, wenn wir Risiken vor Projektstart erfassen und reduzieren, tauchen im Laufe der Zeit immer wieder größere und kleinere Hürden für unsere Teams auf.
Man kann damit natürlich so umgehen, wie ich das oft erlebe, und die Issues einfach ignorieren. In der Hoffnung, dass sie dann von selbst verschwinden. Komischerweise (oder eigentlich tragischerweise) machen sie das aber nie.
Werfen wir mal einen Blick auf Scrum #
Alte Projekthasen lächeln ja, wenn Scrum Master ihnen stolz ihre Impediment Backlogs zeigen. Denn auch, wenn der durchschnittliche Scrum Coach meint, das Sammeln von Problemen, die das Team aufhalten, wäre ein Erfindung von Scrum, gibt es so Listen seit dem es Projektmanagement gibt: Issue Management ist das Zauberwort. So auftauchende Probleme gehören
- gesammelt,
- geclustert,
- priorisiert.
Und das Wichtigste, sie gehören gemanagt. Wie immer und überall im Projektmanagement: es braucht eine Kümmererin oder einen Kümmerer. Jemand, der diese Issues alle zusammensammelt und für ihre Abarbeitung sorgt.
Aber welches Format ist nun das richtige für so eine Issues-Liste?
Die Vorteile eines Impediment Backlogs #
Sehen wir uns das Format Impediment Backlog einmal genauer an. Da steckt nämlich sehr viel drinnen, das wir uns mitnehmen können. Zunächst einmal: was ist das überhaupt? Ein Impediment Backlog ist ein Dokument (analog oder digital), in dem ein Scrum Master alle Steine erfasst, die dem Team so im Weg liegen und die es wegzuräumen gilt. Gesammelt werden diese Impediments meistens beim Daily - also dem morgendlichen kurzen Meeting, bei dem jede und jeder sagt, was gestern erledigt wurde, was heute gemacht werden wird und gegebenenfalls, was sie oder ihn daran hindert, produktiv (oder noch produktiver) zu sein.
Viele kleine Steine räume ich leichter weg, als einen großen #
Und spätestens hier merkt man eines. So ein Scrum Master macht nicht (nur) Projekt-, sondern viel Operations-Arbeit. Tagesgeschäft. Natürlich im Projektumfeld. Und natürlich ist die Grenze schwammig und viel von handelnden Personen, Phasen und vor allem Notwendigkeiten abhängig. Aber in so einem Impediment Backlog stehen viele “kleine” Probleme. Issues am Tagesgeschäftlevel. Die großen - oft in der Form unlösbaren - Brocken tauchen da kaum auf. Das heißt, wir haben in so einem Impediment Backlog viele Issues, die sehr schnell und einfach aus der Welt zu schaffen sind. Viele kleine Steine räume ich leichter weg, als einen großen.
Priorisierung ist die halbe Miete... #
Ein weiterer großer Vorteil von so einem Impediment Backlog ist, dass der nicht einfach als Liste, sondern als Backlog, sprich als priorisierte Liste geführt wird. Das wichtigste - in dem Fall schwerwiegendste - Problem ist immer ganz oben zu finden. Das hilft mir dabei, meinem Team gewaltig weiterzuhelfen. Der Issue, der ihnen am meisten zu schaffen macht, ist der, den ich als erstes angehen werde.
..und geklärte Verantwortlichkeiten sind die zweite Hälfte #
Und so ein Impediment Backlog ist außerdem eine sehr elegante und einfache Lösung für Verantwortlichkeiten: der Scrum Master ist für alle Impediments, die auf dem Backlog stehen, verantwortlich. Keine RACI-Matrix, kein Herumgeschiebe und kein Abstreiten. Es gibt eine Person und die kümmert sich darum. Das heißt nicht, dass wir Themen, die auf der Liste stehen, nicht delegieren dürfen. Aber die Verantwortung sollte beim Projektmanagement liegen.
Das mag auf den ersten Blick unrund wirken. Warum sollen wir als Projektmanager alleine für etwas den Kopf hinhalten, wo wir für nichts, aber auch gar nichts etwas können? Aber wir reden hier ja auch von Issues. Das sind entweder Fleisch gewordene Risiken, oder überhaupt Probleme, die unvorhergesehen auftauchen. Da brennt in meinen Augen der Hut. Und die Klärung solcher Issues sollte für Projektleiter ein ganz besonderes Anliegen sein. Aber das seht Ihr auch alle so, oder? Und also ist es nur gerecht, wenn wir auch die Verantwortung für die Lösung der Impediments in unserem Backlog haben, meine ich.
Wo Licht, da auch Schatten #
Das klingt ja alles fast zu gut, um wahr zu sein. Und meiner Erfahrung nach, haben Impediment Backlogs auch ein paar Schwächen. Beziehungsweise eigentlich ihre Handhabung.
Ich sehe oft brav erzogene Scrum Master, die wirklich alle Themen aufschreiben, die vom Team an sie herangetragen werden. In Schönschrift, mit Kästchen davor. Und dann werden noch mit vielen bunten Finelinern Kringel drumherum und Linien zwischendrinnen gemalt. Meiner Meinung nach gehören Impediments (oder in unserem Fall Issues) in dem Moment erledigt, in dem wir davon erfahren. Sie sind viel zu wichtig, um nicht gleich mit der Erledigung zu beginnen. Erst, wenn ich auf etwas warten muss - sprich, von anderen abhängig bin - kommt es auf den Backlog.
Augen auf, Ohren auf, Helmi ist da #
In meiner Kindheit (lange ist es her) gab es eine Serie namens Helmi, die uns sorglosen Kinder den verantwortungsvollen Umgang mit der Straßenverkehrsordnung näherbringen sollte. Und im dazugehörigen Titellied hieß es, “Augen auf, Ohren auf, Helmi ist da.” Und das sollten wir uns alle zu Herzen nehmen. Selbst, wenn mein Team ein Daily Standup Meeting macht, wo über etwaige Steine im Weg geredet wird - wer sagt mir, dass sie da wirklich an alle denken? Und wer sagt mir, dass nicht ein Issue zwei Minuten nach Ende des Meetings auftaucht? Also sollten wir ein Ohr immer beim Team haben.
Und ganz wichtig: ein Punkt, der im Scrum Guide dezent verschwiegen wird. Wir dürfen vor lauter Impediment Backlog die Unterscheidung zwischen Issues und Risks nicht ignorieren. Auch, wenn die beiden Wörter ganz gerne synonym verwendet werden. Aber ein Risiko hat auf einer Issue Liste oder in einem Impediment Backlog rein gar nichts verloren! Für Risiken habe ich mein gutes altes Risk Management mit planen, identifizieren, analysieren, ausführen, und so weiter. Erst, wenn ein Risiko schlagend wird, wird es zu einem Issue.
Also #
Vielleicht sollten wir Projektmanager den Begriff Impediment Backlog in unseren Sprachschatz aufnehmen. So eine priorisierte Auflistung aller Issues, die unser Team blockieren - und somit auch unser gesamtes Projekt gefährden - und die wir nach und nach abarbeiten (lassen) können, ist ein wertvolles Instrument für unsere tägliche Projektarbeit. Denn die ist auch ohne so eine Liste bereits kompliziert genug.
#scrum #riskmanagement
Vielen Dank für Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von Hans-Peter Gauster und Cristofer Jeschke auf Unsplash.
← Vorheriger Artikel: Abhängigkeiten und wie ich sie verstehe und richtig mit ihnen umgehe
→ Nächster Artikel: Konfliktlösung im Projektmanagement - aber richtig
Veröffentlicht am