Share ZU:
23 Oktober 2012 @ HOOD

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.

Diesen Beitrag hat Andreas Becker für HOOD geschrieben.

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

Diskussion

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*dieses Feld ist erforderlich

Wissen, das bewegt!

Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.

Jetzt abonnieren und keine wichtigen Insights mehr verpassen!