Impediment
Impediment wird in der agilen Softwareentwicklung bzw. dem Verfahren Scrum verwendet. Übersetzt steht Impediment für „Hindernis“ oder „Behinderung“, im Impediment Backlog werden also Probleme dargestellt, die nach einer Lösung verlangen. Da es faktisch kein Projekt gibt, das vollständig ohne Fehler auskommt, ist der Impediment Backlog in der agilen Softwareentwicklung unverzichtbar. Doch das Thema bietet auch Konfliktstoff.
Allgemeine Informationen zum Thema
Im Zuge der Rollenverteilung bei Scrum ist es der Scrum Master, der für das Impediment Backlog zuständig ist (eine weitere Bezeichnung hierfür lautet Scrum Impediment). Der Scrum Master hat als Zielvorgabe die Eliminierung aller Störungen und Hindernisse, die das Projekt gefährden, verlangsamen oder sonst wie behindern. Es kann also als Aufgabe verstanden werden, die über die Arbeit des Entwicklungsteams hinausgeht und die dafür Sorge zu tragen hat, dass das Projekt fristgerecht erledigt werden kann. Zu nennen sind in diesem Zusammenhang infrastrukturelle oder logistische Probleme, aber auch Schwierigkeiten bei der Kommunikation.
Wenngleich der Scrum Master für die Dokumentation und die Behebung von Fehlern im Impediment Backlog zuständig ist, folgt die Ermittlung der Probleme durch das gesamte Team im Rahmen von Meetings. Sollte der Scrum Master ohne Hilfe die Schwierigkeiten nicht lösen können, nimmt er die Unterstützung beispielsweise des Managements oder anderer Stellen in Anspruch, die nicht direkt am Projekt beteiligt sind[1].
Der richtige Umgang mit Impediments
Bei der Frage, wie man das Problem mit Impediments am besten löst, beginnt die Problematik oft schon vorher. Denn nicht immer sind sich alle beteiligten Teammitglieder darüber einig, welches Problem überhaupt in das Impediment Backlog gehört. Zudem gibt es auf der einen Seite die Möglichkeit, Impediment analog aufzubauen und andererseits die, elektronische Versionen zu nutzen, die unter Umständen bereits existieren. Auch die Frage, ob Impediments öffentlich – also betriebsintern für jeden sichtbar – benutzt werden oder nur einer ausgewählten Personengruppe zugänglich gemacht werden, wird häufig konträr diskutiert. Nicht immer gibt die Unternehmensstruktur das öffentliche Vorstellen von Impediments her, doch in bestimmten Fällen kann es durchaus sinnvoll sein, den „Flurfunk“ zu nutzen, also alle Mitarbeiter potenziell an der Problemlösung zu beteiligen.
Im Beispiel eines Start-ups wurde entschieden, den Impediment öffentlich zu plakatieren. In diesem Fall fehlte ein Entwickler, schon nach kurzer Zeit hatte sich das Problem im wahrsten Sinne des Wortes herumgesprochen, verteilt auf vier Etagen und mehr als 150 Mitarbeiter. Im Folgenden dauerte es nicht mehr lange, bis das Problem behoben war. Nicht immer ist die Lösung eines Problems so reibungslos zu lösen, doch wenn die Voraussetzungen stimmen, ist diese Form der Problemlösung durchaus eine Option[2]. Obwohl die öffentliche Verwendung des Impediment Backlog nicht immer möglich oder sinnvoll ist, spricht doch einiges dafür, so zu verfahren. Zum einen wirkt es sich positiv auf die Teammitglieder aus, wenn ihre formulierten Probleme in das Dokument einfließen und sie sich selbst davon überzeugen können. Das hebt die Motivation und das Gefühl, ernstgenommen zu werden. Zum anderen fällt es dem Scrum Master leichter, alle Einträge im Blick zu haben und durch die Beteiligung aller Mitarbeiter leichter Hinweise auf Ursachen von Problemen und/oder deren Lösung zu erhalten.
Nicht zuletzt ist es für alle Teammitglieder motivierend, wenn sie sehen können, dass Einträge nach der Lösung von Problemen aus der Liste gestrichen werden können und das alles unternommen wird, um für ein produktives und wertschätzendes Arbeitsumfeld zu sorgen[3].
Weitere Artefakte neben dem Impediment Backlog
Da die Dokumentation bei der agilen Softwareentwicklung eine große Rolle spielt, gibt es neben dem Impediment Backlog weitere Anwendungen, die für die Realisierung von Projekten wichtig sind. Wenn ein Projekt begonnen wird, kommt zunächst „Definition of Done“ zum Einsatz. Dort wird gemeinsam im Team festgelegt, welche Aufgaben zu bewältigen sind und wann diese fertiggestellt sein müssen. Hier werden auch die Kriterien festgelegt, die erfüllt werden müssen, um das Projekt am Ende abzunehmen. Der Rolle des Product Owners wird die Organisation des Product Backlog zugeschrieben. Dieses Product Backlog stellt eine priorisierte Liste von User Stories dar, es beschreibt das zu entwickelnde Projekt.
Während der einzelnen Sprints beim Scrum werden die Aufgaben erledigt, die das Team zuvor besprochen hat. Diese Aufgaben werden im Sprint Backlog dokumentiert.
Für die Visualisierung der Fortschritte beim Sprint wird das Burn Down Chart verwendet. Es zeigt – abhängig von der verwendeten Software – auf, wo das Team im Zuge des aktuellen Sprints steht. Wie zu sehen ist, sind die Anforderungen und Aufgabenstellungen bei der agilen Softwareentwicklung komplex, die Wahrscheinlichkeit, dass sich Fehler und andere Probleme, einschleichen, ist daher sehr groß. Auf das Impediment Backlog kann daher nicht verzichten werdet, will man einen reibungslosen Ablauf sicherstellen[4].
Bedeutung für das Development
Ohne die Ermittlung von Impediments bzw. das Führen des Impediment Backlogs kommt die agile Softwareentwicklung bzw. die Arbeit mit Scrum nicht aus. Die Ermittlung von Fehlern und Problemen ist ein wesentlicher Bestandteil der Teamarbeit, um Projekte entsprechend der inhaltlichen und zeitlichen Vorgaben realisieren zu können.
Einzelnachweise
- ↑ Scrum Impediment Backlog agiles-projektmanagement.org. Abgerufen am 16.01.2018
- ↑ Impediment Management vom Opfer zum Täter blog.borisloger.com. Abgerufen am 16.01.2018
- ↑ Scrum Definition web.ti.bfh.ch. Abgerufen am 16.01.2018
- ↑ Scrum Methode alphanodes.com. Abgerufen am 16.01.2018