Verbesserungen mit dem Improvement Backlog tatsächlich umsetzen

Motivation

Das Scrum Team, mit dem ich aktuell arbeite, hat stark damit zu kämpfen, dass es zwar viele Ideen für Improvements gibt, diese aber nicht oder nicht fokussiert umgesetzt werden. Im Detail konnte ich folgende Probleme beobachten:

• Das Team arbeitet inhaltlich an einem IT-System, das schon seit einigen Jahren existiert. Im Wesentlichen werden Änderungs- und Wartungswünsche des Kunden umgesetzt.  Auf Grund der langen Historie des IT-Systems gibt es mittlerweile einige Altlasten wie z.B. mangelnde Testautomatisierung, eine Reihe anstehender, größerer Refactorings oder notwendige Verbesserungsarbeiten am Continuous Integration System.
• Es gibt viele Ideen des Teams für Improvements. Es ist jedoch völlig intransparent, welche Ideen genau da sind, welche Ideen die größte Priorität haben, und welche Ideen in Umsetzung sind.
• Wenn das Team mit der Umsetzung eines Improvements beginnt, werden meist keine klaren Ziele dafür definiert. Entsprechend passiert es oft, dass der Fokus fehlt und sich die Arbeiten verlaufen.
• Improvements, deren Umsetzung dem Team keinen Spaß machen, werden nicht umgesetzt.
• Es gab bereits den Versuch des Teams, Improvements in Form von Storys in das Product Backlog aufzunehmen. Die Abarbeitung in diesem Modus war jedoch leider wenig erfolgreich; als Gründe dafür sehe ich unter anderem, dass die Improvement Storys immer nachrangig zu den fachlichen Storys behandelt wurden (und so oft verhungerten) bzw. dass die Verantwortung für die Improvement Storys der PO übernehmen sollte, dieser jedoch kein unmittelbares Interesse an deren Umsetzung hatte.

Ich machte mich daher auf die Suche nach einem Weg, um diese Probleme zu lösen.

Die Idee des Improvement Backlogs

Ich erinnerte mich einerseits an die Idee der Improvement Community, die Mike Cohn in seinem Buch Succeeding With Agile vorstellt. Allerdings zielt diese Idee eher auf agile Organisation als Ganzes ab und nicht auf ein einzelnes Scrum Team.

Bei meiner Web-Recherche stieß ich dann auf einen Blog-Artikel von Charles Bradley, The Dev Team Improvement Backlog. Dieser Artikel beschreibt im Wesentlichen, wie man die Vorteile des Product Backlog (wie z.B. Transparenz, Priorisierung) auf Improvements anwenden kann, dabei aber einige der oben beschriebenen Probleme vermeiden kann. Im Wesentlichen lässt sich die Idee wie folgt charakterisieren:

• Improvements werden wie fachliche Storys in einem eigenen Improvement Backlog gesammelt, regelmäßig gegroomt und priorisiert.
• Die Verantwortung zur Pflege obliegt im Gegensatz zum Product Backlog nicht dem Product Owner, sondern dem Team.
• Das Management gesteht dem Team einen gewissen Anteil der Sprint-Kapazität (z.B. 10-20%) zu, um Items aus dem Improvement Backlog umzusetzen.
• Improvement Items werden am Scrum Board genau so wie fachliche Storys abgebildet; allerdings werden sie in Bezug auf die Priorisierung nicht mit den fachlichen Storys gemischt, sondern in einem eigenen Bereich (Swim Lane) dargestellt.

Erhoffte Vorteile für Verbesserungen

Aus diesem Vorgehen erhoffe ich mir folgende Vorteile:

• Mehr Transparenz bei der Priorisierung von Improvements: Durch die Führung und Pflege eines eigenen Backlogs wird das Team dazu angehalten, regelmäßig seine Ideen zu sichten, hinsichtlich der Priorität immer wieder neu zu bewerten.
• Mehr Transparenz bei der Abarbeitung von Improvements: Für Improvement Items gelten sie gleichen Qualitätsanforderungen (Formulierung von Akzeptanzkritierien, Erfüllung der Definition of Ready, Erfüllung der Definition of Done) wie für fachliche Storys.
• Improvements werden fertig: Durch das Sichtbarmachen geplanter Improvements am Scrum Board fokussiert sich das Team auf die geplanten Improvements in der definierten Qualität (Akzeptanzkritierien).
• Das Team übernimmt Verantwortung für seine Improvements: Das Team selbst ist ja mittelbar der Kunde von Improvements. Es erscheint daher sinnvoll, dass das Team selbst für das Improvement Backlog in die Rolle des Product Owners schlüpft.
• Für die Einbeziehung von Stakeholdern können die etablierten Mechanismen für fachliche Storys übernommen werden: Improvements haben neben dem Team selbst natürlich auch andere Stakeholder, beispielsweise das Management oder andere Abteilungen im Unternehmen (z.B. das Deployment Team). Inputs und Feedback dieser Stakeholder können auf dem gleichen Weg eingeholt werden wie für fachliche Storys (z.B. über Teilnahme am Grooming, oder Vorstellung umgesetzter Improvements in der Sprint Review).
• Als (durchaus wichtiger) Nebeneffekt soll das Führen eines Improvement Backlogs die Selbstorganisation des Teams verbessern: Das Management gesteht dem Team ja nicht unwesentliche Ressourcen dafür zu und übergibt dem Team die Verantwortung zur bestmöglichen Nutzung dieser Ressourcen.

Improvement Backlog Items

Was ist aber nun überhaupt unter einem Improvement zu verstehen? Das hängt von einigen Dingen ab, unter anderem den organisatorischen Rahmenbedingungen, unter denen das Team arbeitet. Grundsätzlich könnten folgende Aufgaben als Improvement verstanden werden und zu einem Eintrag im Improvement Backlog führen:

• Abbau von technischen Schulden: Hat das Team in der Vergangenheit bewusst technische Schulden gemacht (z.B. Abstriche bei der Testabdeckung mit Unit-Tests), können diese in Form von Improvements wieder abgebaut werden.
• Verbesserung der Qualität: Hierzu zählen etwa der Einsatz von Werkzeugen zur Anhebung der Codequalität, Code Reviews und Refactorings.
• Prozessverbesserungen: Darunter sind einerseits Verbesserungsmaßnahmen am agilen Projektvorgehen (wie z.B. die Einführung eines Improvement Backlogs) zu verstehen, andererseits Verbesserungen in den technischen Entwicklungspraktiken, wie z.B. rund um Continuous Integration, Testautomatisierung oder die verstärke Anwendung von Pairing.
• Verbesserung der Teamzusammenarbeit: Hier ordne ich beispielsweise eine Team-Retrospektive zu einem besonderen Thema ein, oder aber auch Maßnahmen zur Weiterentwicklung des Teams, wie etwa ein Team-Coaching.
• Weiterbildung für das Team: Weiterbildung ist hier weit gefasst: Abhängig von der Verantwortung, die dem Team in diesem Bereich zugestanden wird, kann das von Maßnahmen zum Wissenstransfer zwischen einzelnen Team-Mitgliedern über das Erforschen bzw. Ausprobieren neuer Technologien (wie z.B. einem neuen GUI-Framework) bis hin zur Teilnahme an Entwicklertrainings oder Fachkonferenzen reichen.

Praktische Durchführung

Vor etwa zwei Monaten haben mein Team und ich begonnen, die Idee des Improvement Backlogs praktisch umzusetzen. Konkret haben wir es so ausgestaltet:

• Zunächst habe ich die Idee dem Management vorgestellt. Die Problemlage war im Wesentlichen bekannt, die Idee und die erhofften Vorteile wurden positiv aufgenommen; letztendlich gab das Management das Commitment ab, dem Team in jedem Sprint 10% der Kapazität für die Umsetzung von Improvements zur Verfügung zu stellen.
• Das Product Backlog und das Improvement Backlog existieren gleichwertig nebeneinander. In zwei Dingen unterscheidet sich die Arbeit jedoch wesentlich: Für die Pflege des Improvement Backlogs ist das Team verantwortlich, und Improvement Backlog Items werden in Personentagen abgeschätzt (um zu verhindern, dass hier Äpfel mit Birnen verglichen werden).
• Product Backlog Items und Improvement Backlog Items werden im Sprint (z.B. hinsichtlich der Priorisierung) nicht durchmischt, sondern am Scrum Board in zwei gleichberechtigten Swim Lanes angeordnet. Die Items innerhalb der beiden Swim Lanes sind für sich jeweils priorisiert. Das Team beginnt gleichzeitig mit der Bearbeitung des am höchsten priorisierten Product Backlog Items und des am höchsten priorisierten Improvement Backlog Items. Zur besseren Übersicht werden Product Backlog und Improvement Backlog Items am Scrum Board auf Kärtchen unterschiedlicher Farben dargestellt.
• Die Erstbefüllung des Improvement Backlog Items haben die Teammitglieder vorgenommen, in dem sie Ideen aus diversen bereits existierenden Quellen (Product Backlog, Maßnahmenkataloge aus Sprint-Retrospektiven, eigener Kopf) gesammelt und zunächst nur stichwortartig als Items im Improvement Backlog eingetragen haben.
• Die Pflege des Improvement Backlogs geschieht durch das Team jeweils in Anschlussterminen an die bereits etablierten Grooming-Termine für das Product Backlog. Der Product Owner darf bei diesen Improvement Backlog Groomings mitmachen, seine Anwesenheit ist aber nicht verpflichtend.
• Umgesetzte Improvements werden durch das Team wie reguläre Product Backlog Items in der Sprint Review den Stakeholdern vorgestellt und mit diesen diskutiert (nicht zuletzt auch im Sinne des Marketings für die Idee des Improvement Backlogs). Die Sprint Review wurde dazu zeitlich etwas erweitert und in zwei Teile (Product Backlog Items, Improvement Backlog Items) aufgeteilt. Der Teilnehmerkreis für die beiden Teile der Sprint Review unterscheidet sich bei Bedarf.

Erfahrungen aus zwei Monaten

Was sind nun die ersten Erfahrungen, die sich nach zwei Monaten des praktischen Arbeitens mit einem Improvements berichten lassen?

• Dinge werden tatsächlich fertig: Im Gegensatz zur Vergangenheit werden die Improvements, die es auf das Scrum Board schaffen, auch tatsächlich umgesetzt. Dies führt zu entsprechender Zufriedenheit im Management, und auch das Team selbst erkennt den beginnenden Nutzen der umgesetzten Improvements, beispielsweise bei der Verbesserung der Testautomatisierung.
• Das Improvement Backlog hat sich als zentrales, für Teammitglieder und Stakeholder einfach zugängliches Sammelbecken für Improvement-Ideen etabliert. Die Leute tragen selbständig neue Ideen ein, egal ob sie im Rahmen einer Sprint-Retrospektive oder beim gemeinsamen Mittagessen geboren werden.
• Das Pflegen des Improvement Backlogs durch das Team war und ist eine Herausforderung. Aktuell hat sich das Team darauf verständigt, dass zwei Teammitglieder stellvertretend für das Team die Rolle des PO wahrnehmen. Hauptaufgabe dieser zwei Abgesandten ist es, das Improvement Backlog für die Grooming-Termine so vorzubereiten, dass dort effizient gearbeitet werden kann.
• Das Team hat erkannt, wie wichtig es ist, auch für Improvement Backlog Items klare Akzeptanzkritierien zu entwickeln, aber auch welche Knochenarbeit diese Tätigkeit oft darstellt. Ich habe auch den Eindruck, dass durch diese Lernerfahrung im Team auch der Respekt für die Arbeit des Product Owners gestiegen ist.
• Unter Druck (z.B. wenn absehbar wird, dass das Sprint Commitment in Gefahr ist, oder wenn es bedingt durch kundenseitig vorgegebene Abgabetermine in der Planung eng wird), ist der Impuls im Team vorhanden, doch einfach Improvement Backlog Items zurückzustellen. Hier bin ich als Coach immer wieder mal gefordert, diesen Impuls zu thematisieren. Dankenswerter Weise habe ich dabei die entsprechende Unterstützung aus dem Management.
• Das Management agiert (z.B. in der Sprint Review, aber auch mittels direkter Interaktion mit den zwei Improvement Backlog Abgesandten des Teams) als sehr aktiver Stakeholder. Das führt einerseits zu sehr befruchtenden Dialogen, auf der anderen Seite birgt dieses Verhalten auch die Gefahr, dass die beabsichtigte Verbesserung der Selbstorganisation darunter leidet. Auch hier bin ich als Coach entsprechend aufmerksam um bei Bedarf zu intervenieren.

Fazit

Für eine abschließende Bewertung des Erfolgs der Einführung des Improvement Backlogs ist es noch etwas zu früh, aber mit den bisherigen Erfahrungen bin ich durchaus zufrieden. Das Improvement Backlog sorgt für Transparenz und Klarheit im Team und bei den Stakeholdern, es ermöglicht dem Team ein fokussiertes Arbeiten an Verbesserungen. Insbesondere freut es mich zu beobachten, dass das Team seine Verantwortung, die es vom Management übertragen bekommen hat, sehr ernst nimmt.