Agile Transition – wenn aus der Zeit des Wasserfalls noch Altlasten bestehen

Agile Entwicklungsmethoden gewinnen stark an Bedeutung und lösen zunehmend phasen- und dokumentengetriebene Vorgehensweisen ab. Werden agile Prinzipien und damit verbundene Entwicklungstechniken konsequent eingesetzt, wird die Qualität steigen und die Fehlerzahl tendenziell sinken. Aber es gibt auch noch die Zeit vor der Umstellung auf agile Entwicklungsmethoden. Aus diesen Zeiten werden – gerade in großen Organisationen – häufig große Fehlerberge in die neue Zeit überführt. Um diese Fehler kontinuierlich abzubauen gibt es verschiedene Möglichkeiten, die nachfolgend vorgestellt werden.

Fehler sind auch nur Items
Das Scrum-Framework [SS11] sieht nur Items vor und macht keinen Unterschied zwischen Anforderungen, User Stories und Fehlern. Jedes Items ist im Backlog zu priorisieren und in Sprints umzusetzen bzw. zu beheben. Die Aufgabe eines Product Owners (PO) ist es nun, Anforderungen / User Stories gegen Fehler(-altbestände) abzuwiegen und in eine eindeutige Reihenfolge zu bringen. Aus meiner Erfahrung ist dies mit gewissen Herausforderungen verbunden. Product Owner müssen eine Priorisierungsmethode anwenden, die neue Funktionalitäten und die Wartung zusammenbringt – das Team, das i.d.R. keine Fehlerschätzungen vornimmt, hat eine möglichst stabilisierte Velocity zum Ziel, die durch eine ständig wechselnde Fehleranzahl negativ beeinflusst wird.

Fehler willkürlich an User Storys anhängen
Arbeitet ein Team mit User Stories, besteht nach [Wir11] die Möglichkeit, Fehler an umzusetzende User Stories willkürlich anzuhängen. Willkürlich heißt in diesem Zusammenhang, dass jede User Stories einen Fehler zugeordnet bekommt, mit dem es fachlich keinen Zusammenhang gibt. Beide Items werden in unterschiedlichen Backlogs (ein Product-und ein Fehler-Backlog) priorisiert und im Sprint Planning zusammengebracht. Eine User Story ist bei dieser Vorgehensweise erst dann fertig, wenn auch der daran angehängte Fehler gefixt wurde. Dieses Vorgehen hat den Vorteil, dass Fehler nicht geschätzt werden müssen und trotzdem eine Priorität, die der User Stories – erhalten und kontinuierlich Fehler pro Sprint abgearbeitet werden können.
Das größte Hindernis ist nach meiner Erfahrung die Akzeptanz dieser Vorgehensweise im Team, da eine User Story erst fertig ist, wenn ein Fehler behoben ist. Das kann dazu führen, dass eine User Story nicht abgenommen wird, obwohl sie „eigentlich“ done ist. Die Zuordnung von Fehlern an User Stories ohne fachlichen Bezug ist daher für viele Beteiligte schwer zu akzeptieren.
In dieser Situation hilft die Kombination von zwei agilen Methoden – Scrum und Kanban.

Scrum und Kanban kombinieren
Weiterentwicklung und Wartung von einem Produkt kann durch die Trennung von Teams durchgeführt werden. Ein oder mehrere Weiterentwicklungsteams, die nach dem Scrum-Framwork neue Funktionalitäten in Sprints umsetzen und ein Wartungsteam, das nach Kanban arbeitet und Fehler bzw. Altbestände von Fehlern behebt. Größere Teams können auch beide agile Methoden in ihrem Team integrieren und parallel durchführen.
Kanban bedeutet in unserem Zusammenhang, dass der Prozess zum kontinuierlichen Fehlerabbau an einem Kanban-Board visualisiert wird und durch diese Visualisierung Engpässe und Blockierungen unmittelbar sichtbar werden. Die Menge an aktuell zu behebenden Fehlern werden durch Limits begrenzt, um die parallel durchzuführende Arbeit zu begrenzen und dadurch fokussiert an den wichtigsten Elementen zu arbeiten und diese abzuschließen. Der visualisierte Prozess kann im Fall der Wartung sehr einfach gehalten werden und beispielsweise nur aus den Arbeitsschritten – und damit den Spaltenbezeichnungen am Kanban-Board – „to do“, „doing“ und „done“ bestehen. Kanban sieht zwar keine Rollen vor, die mit Scrum vergleichbar sind, es hat sich aber in meinem Umfeld bewährt einen sogenannten BoardMaster zu benennen, der in Analogie zu Scrum entsprechende Aufgaben übernimmt. Dies sind die Überwachung des Prozesses, die Moderation von Meetings, der Schutz des Teams vor Aufgaben, die nichts mit Wartung zu tun haben und dem Coaching des Teams sowie dem „Wegräumen“ von Hindernisse und Blockierungen. Der Nachschub an Fehlern wird über eine priorisierte und in eine Rangfolge gebrachtes Fehler-Backlog geregelt, für das auch der Product Owner verantwortlich ist. Dadurch stehen die kritischsten Fehler mit der höchsten Priorität am Kanban-Board an oberster Stelle und werden anhand dieser Kritikalität behoben, während am Board der Scrum Teams neue User Stories und damit neue Funktionalitäten umgesetzt werden.

Fazit
Scrum ist eine agile Methode, die sich für die Softwareweiterentwicklung hervorragend eignet. In einem Umfeld, indem nicht nur Weiterentwicklung erfolgt, sondern auch Wartungsaspekte berücksichtigt werden müssen, kann die Kombination aus Kanban und Scrum zum Erfolg führen. Die Integration mit Kanban gleicht die Unsicherheit der Sprintplanung aus, stabilisiert die Velocity und gewährleistet trotzdem einen kontinuierlichen Fehlerabbau.

Quellen
[Wir11] Scrum mit User Stories, Ralf Wirdemann, Hanser Verlag, 2. Auflage, 2011
[SS11] The Official Scrum Rulebook, Ken Schwaber and Jeff Sutherland, http://www.scrum.org/Scrum-Guides, 2011

Andreas Becker

Kontaktieren Sie Andreas Becker

Andreas Becker ist Agile Transition Coach, Senior Consultant und Trainer bei HOOD GmbH / Agile-by-HOOD. Er begleitet Unternehmen bei der Transition zu agilen Organisationen und unterstützt bei der Implementierung von „Lean Thinking“. Im Fokus seiner Arbeit stehen agile Teams und Business Analysten in agil skalierten Umfeldern. Er ist in der Lean, Agile und Scrum Community aktiv und veröffentlicht Artikel, hält Vorträge und führt Workshops auf internationalen Konferenzen durch und ist zudem Lehrbeauftragter an der Hochschule Rosenheim für "Agile Produktentwicklung". Herr Becker ist zertifizierter Scaled Agile Framework - Program Consultant (SAFe), ScrumMaster und Product Owner. Neben seiner langjährigen Erfahrung im agilen Umfeld hat er in den Bereichen Requirements Engineering, Softwaretest- und Qualitätsmanagement in unterschiedlichen Branchen gearbeitet.