Impediment Backlog - Entwicklung ohne Hindernisse

Blog_action-1834465_1280

Über die Wichtigkeit des Impediment Backlogs

In diesem kleinen aber feinen Blog-Artikel wird auf die Wichtigkeit des Impediment Backlogs in agilen Software-Entwicklungsprojekten eingegangen. Fragen nach dem „wer", „wie", was" und „warum" werden beantwortet. Beispiele für Form und Inhalt dürfen dabei natürlich nicht fehlen.

Die Probleme des SCRUM Teams

In der agilen Softwareentwicklung mit SCRUM organisiert sich das Development-Team selbst. Dabei kommt, wie im realen Leben, kein Mensch ohne Hindernisse durch den Alltag. Und genau so ist es auch in der Softwareentwicklung. Da fehlen urplötzlich Berechtigungen oder die Abhängigkeit zu einer Bibliothek, die von einem anderen Team gepflegt wird. Diese Probleme stellen regelmäßig eine Behinderung bei der eigenen Entwicklung dar. Auf dem kurzen Dienstweg versuchen die Entwickler selbst, diese Probleme schnell aus der Welt zu schaffen. 

Die Stunde des SCRUM Masters

Gelingt dies nicht, schlägt die Stunde des SCRUM Masters. Er kommt immer dann ins Spiel, wenn Probleme, sogenannte „Impediments", einzelne Entwickler aus ihrer täglichen Arbeit reißen und die Lösung sich als langwierig oder schwierig erweist. Seine Aufgabe ist es, diese schnellstmöglich zu beseitigen, damit das Development-Team ungehindert seine Arbeit fortsetzen kann, das Sprint-Goal erreicht wird und alle Aufgaben im aktuellen Sprint bis zum Ende erledigt werden können. Andernfalls verlangsamt sich die Velocity des Teams bis hin zum Stillstand der Entwicklung.
Sein Werkzeug dabei ist das Impediment Backlog, wobei „Impediment" (aus dem Englischen) so viel wie „Hindernis" oder „Behinderung" bedeutet.

Aufbau eines Impediment Backlogs

Ein vorgeschriebenes Format für den Aufbau des Impediment Backlogs besteht nicht.
Allerdings sollten alle Impediments aufgeführt werden, egal ob groß oder klein, leicht oder schwer, wichtig oder anscheinend unwichtig.
Mindestens eine Beschreibung der Störung sollte jeder Punkt besitzen und sie sollte priorisiert sein. Ansonsten steht es jedem SCRUM Master frei, eine Liste nach seinen eigenen Bedürfnissen aufzubauen.
Im Internet lassen sich diverse Vorlagen dazu finden. Neben der kurzen Beschreibung des Impediments sollten folgende Angaben enthalten sein:

  • Wer ist betroffen?
  • Seit wann besteht die Störung?
  • Wer ist der Ansprechpartner?
Wichtig ist einzig und allein, dass sowohl das Team als auch der SCRUM Master mit dieser Liste zurechtkommen und alle relevanten Angaben zu einzelnen Punkten vorhanden sind. Eine simple Möglichkeit ist die Erfassung in einer Excel Liste. Post-its an einem Whiteboard oder an einer freien Wand sind ebenso oft gesehen wie die Verwendung eines Tools, z.B. einem Ticketsystem wie Atlassian Jira oder Microsoft TFS.

Einbau in den Arbeitsalltag

Immer wenn ein neues Hindernis auftaucht, nimmt der SCRUM Master dieses in die Liste auf und kümmert sich um die Beseitigung. Die Übersicht sollte für das Team öffentlich einsehbar sein und regelmäßig aktualisiert werden. Dabei sind die einzelnen Punkte nach Wichtigkeit sortiert. 

Übersicht Impediment Backlog

Zusammengefasst hier noch einmal die wichtigsten Merkmale eines Impediment Backlogs:
  • vom SCRUM Master gepflegt
  • Auflistung aller Störungen für das Team
  • Öffentlich einsehbare Liste
  • Priorisierte Liste
  • Wird täglich/regelmäßig gepflegt

Ein Beispiel ist in der folgenden Liste zu sehen:

Fazit

In diesem Blog-Artikel wurde das Impediment Backlog für agile Teams vorgestellt und auf die Wichtigkeit aufmerksam gemacht. Es sollte in keinem SCRUM Team fehlen. Im Gegenteil: Dieses Werkzeug sollte zum festen Bestandteil gehören und ihm sollte regelmäßig Aufmerksamkeit geschenkt werden!
Glauben Sie keinem die Aussage, dass es in seinem Projekt keine Probleme gibt. In der Literatur liest man häufig sogar, dass ein Projekt ohne Impediment Backlog in Wahrheit massive Probleme „unter der Haube" bzw. „unter dem Radar" hat. Und da ist sicher etwas Wahres dran. Oder wie ist das in Ihrem Projekt!?
 

By accepting you will be accessing a service provided by a third-party external to https://blog.ordix.de/