Phänomenologie des Impediments

Dieser Artikel ist aus der Vorbereitung eines Workshops für eines unserer Projekte entstanden. Mein besonderer Dank gilt dabei meinen werten Kollegen Mathis Christian und David Holzer, die mir geholfen haben, Impediments in ihrer ganzen Dimension zu verstehen.DefinitionEin Impediment ist erstens alles, was das Team bei der Arbeit behindert. Solche Impediments müssen beseitigt werden, um dem Team den Rücken frei zu halten. Beispiele: Die Monitore sind zu klein, die Räume zu warm, der ScrumMaster weilt oft im Home Office. Ein Impediment ist zweitens alles, was ein gutes Team davon abhält, noch besser zu werden. Solche Impediments werden meist durch Maßnahmen beseitigt, die auf eine Verhaltensänderung im Team abzielen. Beispiele hierfür: Agile Entwicklungspraktiken werden kaum genutzt, User Stories haben schlechte Qualität, Entwickler und Tester arbeiten wenig zusammen. RetrospektiveEine gute Retrospektive wirkt wie ein geschickt ausgeworfenes Fischernetz: Sie bringt allerhand Impediments zu Tage. Wer nur in seichten Gewässern fischt, der wird immer das Gleiche und manchmal einen Stiefel zu sehen bekommt. Die Retro soll Raum für Reflektion und Abstand geben, ungewöhnliche Perspektiven eröffnen und dem Team dabei helfen, sich als soziales Konstrukt zu verstehen (mehr zur Retrospektive in diesem Blog-Beitrag meiner Kollegin Stephanie Gasche). Gegen Ende der Retrospektive bittet der ScrumMaster sein Team darum, die identifizierten Impediments in interne oder externe zu klassifizieren. Impediments sind intern, wenn das Team selber sich zutraut, die Verantwortung für die Lösung des Impediments zu übernehmen. Für externe Impediments ist hingegen der ScrumMaster verantwortlich. Impediments - sichtbare und unsichtbareManche Impediments sind kaum zu übersehen. Die Wand, die ein Team in zwei teilt. Die engen Räumlichkeiten, die keinen Rückzugsort für einen entspannten Kaffeeplausch bieten. Andere Impediments liegen nicht sofort auf der Hand. Das Teammitglied, das im Daily Scrum immer wieder unterbrochen wird. Der Product Owner, der nur an drei Tagen in der Woche für sein Team da ist. Der ScrumMaster, der nicht moderieren kann. Das Management, das die Vergütung im Team von individuellen Leistungszielen abhängig macht. Nicht jedem fallen solche Situationen sofort als Impediments auf, obwohl sie das Team in ihrer Entwicklung behindern. 

 Impediment BacklogIm Daily Scrum erklärt das Team seine Arbeit anhand des Taskboards. Der ScrumMaster tut das gleiche anhand des Impediment Backlogs. Dort finden sich, analog zum Taskboard, die offenen und geschlossenen Impediments sowie diejenigen, die in Bearbeitung sind. Impediments sollten in einer priorisierten Reihenfolge aufgehangen werden. Hängt ein Impediment länger als einen Tag in Bearbeitung, bekommt es einen Punkt. Das Impediment Backlog sollte Platz für interne und externe Impediments bieten (zur Unterscheidung intern/extern, siehe Retrospektive). Impediments und MaßnahmenManche Impediments sind erstmal nur das, was ihr Name besagt: Hindernisse. Für andere Impediments bieten sich unmittelbare Maßnahmen an. Ist das Impediment ein internes, dann gehört die Maßnahme, gekennzeichnet mit dem Namen des verantwortlichen Teammitglieds und ihrer Impediment-Zugehörigkeit, ins Team Backlog. Sobald die Maßnahme in die Bearbeitung geht, wandert sie auf das Taskboard und hängt dort wie jeder andere Task auch. Parallel dazu wandert das Impediment auf dem Impediment Backlog in Bearbeitung. Ist die Maßnahme durchgeführt, überprüft das Team, ob das korrespondierende Impediment damit gelöst ist und auf erledigt gesetzt werden kann. Für die externen Impediments kann der ScrumMaster sich überlegen, ob er ein Taskboard für seine eigene Arbeit anlegen möchte. ZeitManche Impediments brauchen Zeit und mehr als eine Maßnahme, um gelöst zu werden. Trotzdem dranbleiben! Ein Team, das durch eine Mauer getrennt war, hat einmal 56 Punkte auf das Impediment gemacht, bis der Zettel Masern bekam und die Mauer abgerissen war. Die Sturheit wurde belohnt. Andere Impediments lassen sich schneller lösen, wenn man sie herunterbricht und ein klares Ziel festlegt. Das Team ärgert sich, dass das Testen immer ganz zum Schluss kommt? Frage nach, worin genau der Mangel liegt - und was dagegen unternommen werden kann (z.B. ein Code-Kata zur testgetriebenen Entwicklung). Schaue zu, dass die Maßnahme im neuen Sprint umgesetzt wird. Frage dann, ob das Impediment - mangelndes Know-How - nun noch fortbesteht. So kann das Team entscheiden, ob weitere Maßnahmen nötig sind. Skaliertes Impediment-ManagementWenn mehrere Scrum-Teams am gleichen Produkt arbeiten, wird der Koordinationsbedarf größer. Abstimmungen, die bei zwei oder drei Teams vielleicht noch zwischen Tür und Angel erledigt werden konnten, werden bei weiterem Wachstum nicht mehr ausreichen. Deshalb machen wir jeden Tag 15 Minuten lang ein Scrum of Scrums (SoS), in dem sich Vertreter aus jedem Team treffen und austauschen. Der Fokus liegt dabei auf Abhängigkeiten und Impediments. Nicht jedes Impediments ist für das SoS relevant. Ein Kriterium ist Betroffenheit: Sind andere Teams vom Impediment betroffen, gehört es auf jeden Fall ins SoS. Ein weiteres Kriterium ist der Lerneffekt: Wurde für die Lösung des Impediments ein neuer oder ungewohnter Weg beschritten, kann das für andere Teams höchst interessant sein (Wie hat das Team es geschafft, das Impediment zu lösen? Mit wem musste es dabei sprechen?). Impediments auf dem SoS-Board sollten parallel immer auf dem Impediment Backlog des Teams gepflegt werden. So kann der ScrumMaster dranbleiben und entscheiden, wann er seinem Team unter die Arme greifen muss. TIPP: "ImpedimentManagement" - das Training mit Dieter Rösner zum Erkennen und geschickten Entfernen von Hindernissen, die ein Team an der effizienten Arbeit hindern. Alle Infos hier.