Wenn man ein neues Produkt entwickelt, das erst später nach entsprechenden Qualitätssicherungen zum Einsatz kommen soll, ist es verhältnismäßig einfach, Scrum nach dem Lehrbuch einzuführen.
Firmen jedoch, die Ihre eigene Software entwickeln, wie z.B. einen Webshop, und die diese Software auch selbst betreiben, kommen oft mit Troubleshouting-Problemen auf die Software-Entwickler zu, die eben umgehend gelöst werden müssen und keinen noch so kleinen Aufschub dulden. Unter diesen unvorherbestimmbaren Umständen ist es natürlich schwieriger, ein Sprint-Commitment zu halten. Der Artikel soll zeigen, wie dies mit einer Scrum-Taskforce gelöst werden kann.
Fast alle Sprints litten immer darunter, das es Emergency-Bugs im laufenden Betrieb des Webshops gab und gibt, die, sind sie einmal bekannt, dann keinen Aufschub dulden. Dies können Fehler sein, die
den Betrieb der Software verhindern oder gefährden,
die aus rechtlich relevanten Gründen der umgehenden Anpassung bedürfen,
die wichtige inhaltliche oder ablauftechnische Funktionen des Verkaufsprozesses verhindern.
Bei all diesen Themen muss umgehend im Life System ein Bugfix eingespielt werden. Bisher wurde dann immer eines der Teams beauftragt, dies zu fixen. Dies führte zu der allseits anerkannten Tatsache, das ein Team das Recht hatte, unter diesen Umständen commitete Stories nicht fertigzustellen. Ein eigentlich im Scrum unakzeptabler Zustand! Dennoch ging die Notwendigkeit der dringenden Bugfixes immer vor, was aus kommerziellerSicht begreiflich ist.
Nach Diskussion mit anderen ScrumMastern und dem Team kam die Idee auf, ein Bugfixing Team ausserhalb der Sprint Teams zu etablieren. Dieses sollte sich um akute und existente Bugs kümmern und damit quasi den anderen Teams den Rücken frei halten, damit diese sich voll auf Ihre Sprint-Ziele fokussieren können. Ich hatte bereits Erfahrung mit solch einer Taskforce und kannte die positive Seite, das die Teams ungestört am Sprintziel arbeiten konnten.
Es gab aber auch eine Kehrseite: Bugfixing ist nicht gerade populär.
Wen also in die Bug-Task-force nehmen? In einem früheren Team/anderen Firma hatte ich dies mit einem Freelancer gelöst, der mit bei den Teams saß und (fast) alle Bugsrequests abfing. Nach einer Einarbeitungszeit von ca. 3-4 Wochen lief das auch sehr gut und der Freelancer war fast ein Jahr dabei. Der Haken war, das man mit Bugfixing auch die verschiedensten Stellen der Anwendung kennenlernt. Nach einem halben Jahr wusste der Freelancer teilweise mehr über die Anwendung als in dieser Zeit neu eingestellte Entwickler, die nur Ihre bis dahin realisierten Themen kannten. Bugfixing ist also auch ein intensiver Weg des Lernens! Diese Fehlentwicklng wollten wir diesmal unbedingt vermeiden.
Die Lösung war ein rotierendes Bugfixing -Team! Je (3-Wochen-) Sprint gehen 2 andere Entwickler ins Bugfixing-Team. Bei ca. 12 Entwicklern kommt also rein rechnerisch jeder alle 15 Wochen für 3 Wochen dran. Das ist sehr akzeptabel, zumal er dann ca. 3 Monate Ruhe vor Bugfixing hat.
Im nächsten Artikel werde ich beschreiben, Wie wir die Arbeit organisieren, welche Aufgaben das Bug-Task-Force Team hat und ein Fazit zu den ersten Erfahrungen geben.
iqupi's world 
Eine rotierende Taskforce wäre für mich persönlich nicht die erste Wahl: die sich dadurch ständig ändernde Teamzusammensetzung könnte sich negativ auf optimale Leistungen auswirken. Mein Favorit wäre ein gesamtes, rotierendes Team.
Aber wie bei fast allen Ideen gilt: Es gibt keine “Best Practice”, sondern kommt immer auf die jeweiligen Randbedingungen an.
Bin deshalb gespannt mehr zu lesen 🙂
Tja, mehr als 2 wäre bei unserer Gesamtstärke zu hoch gegriffen. Aber Sie gehen auch immer wieder in Ihre Teams zurück, die jeweils ja immer nur einen Mann für 3 Wochen verlieren. Geht schon.