SCRUM ist kein Buzzword mehr. Es scheint die ideale Lösung für Unternehmen zu sein, die einen flexiblen Ablauf der Prozesse in der Entwicklung der Software wünschen. Die offizielle Definition besagt: „Scrum ist die Bezeichnung für ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Scrum hat vordefinierte Prozesse und Rituale, welche mehr oder weniger gelebt werden.“ https://de.wikipedia.org/wiki/Scrum
Bevor ich euch nachfolgend meine Erfahrung schildere, möchte ich gleich die erste Abweichung vorwegnehmen. Scrum definiert keine Tester, nur Product Owner, Scrum Master und Entwicklungsteams. In meinem Projekt wurden Tester in das Scrum Team aufgenommen.
Meine Erfahrungen in einem Scrum-artigen Projekt
Im Folgenden werde ich einige Situationen aus meiner Projekt-Praxis mit Scrum schildern und dabei Abweichungen von der Scrum Theorie findet beschreiben.
Die ideale Team Grösse für Scrum-Projekte
Die ideale Team-Grösse sollte bei drei bis neun Personen liegen.
Abweichung im Projekt:
Unser Team bestand aus 17 Personen (Manuelle Tester, Test-Automatisierer, Entwickler und Requirements Engineer (RE)).
Vorteil dieser Abweichung:
In solch einem grossen Team konnte die Arbeit auf mehrere Personen verteilt werden. Bei internen Rückfragen konnte man auf die kombinierte Erfahrung vieler Kollegen zugreifen.
Nachteil dieser Abweichung:
Hier war das Problem, dass eine grössere Zahl an Entwicklern den wenigen Testern gegenüber stand. So konnte zwar eine grosse Menge an Stories bis zum vorletzten Tag der Iteration entwickelt werden aber für die Tester blieben dadurch nur wenige Tage des Testings. Es bestand die Gefahr, dass nicht alle Stories rechtzeitig fertiggestellt werden konnten wodurch der Puffer für Bugfixises dezimiert wurde.
Zusammenarbeit
Nach Scrum ist der Ablauf so definiert, dass der Product Owner die Anforderungen an das Produkt in Zusammenarbeit mit dem Entwicklungsteam (z.B. Architekt, Entwickler, Tester, Dokumentationsexperte oder Datenbankexperte) und den weiteren Stakeholdern, definiert.
Abweichung im Projekt:
Der Requirements Engineer (RE) fungierte auch als Product Owner und pflegte das Product Backlog. Die Stories, die sich im Product Backlog befanden, wurden vorab vom RE nur mit den externen Stakeholdern definiert, ohne Einbezug des restlichen Entwicklungsteams.
Vorteil dieser Abweichung:
Es waren nicht zu viele Personen bei der Abstimmung der Stories beteiligt und somit wurde die Projektzeit nicht unnötig in die Länge gezogen.
Nachteil dieser Abweichung:
Erfahrung der Tester, Architekten und Entwickler wurde nicht miteinbezogen und wichtige Entscheidungen zwecks Umsetzung und Planung wurden gar nicht berücksichtigt oder zu spät entdeckt. Der Tester konnte somit kein Einfluss auf die Testbarkeit nehmen und prüfen.
Sprint Dauer
Ein Sprint/Iteration sollte zwischen ein und vier Wochen dauern, idealerweise zwei Wochen. Dabei gilt es zu beachten, dass in einem Projekt eine Iteration stets eine fixe Länge haben muss.
Abweichung im Projekt:
Ein Release war in fünf Iterationen unterteilt. Die Iterationen hatten keine fixen Längen sondern dauerten zwischen zwei und (meistens) vier Wochen.
Vorteil dieser Abweichung:
In vier Wochen war es möglich, mehrere Stories abzudecken und auf viele Projektmitglieder zu verteilen. Die Userstories mussten oft auch nicht geschnitten werden und konnten somit vollumfänglich in der Iteration fertiggestellt werden.
Nachteil dieser Abweichung:
Die Flexibilität ging verloren und die Priorisierung bzw. neue Themen waren erst bei dem nächsten Iterationsbeginn wieder möglich. Retrospektiven waren ineffizient, da der Betrachtungszeitraum zu lange war. Weil die Userstories nicht mehr geschnitten werden mussten bestand die Gefahr, dass die Komplexität und damit das Risiko steigt.
Stories
Die Verfeinerung der Spezifikationen wird gemeinsam durch Tester, Entwickler und Fachvertreter durchgeführt. Auch als „The Power of Three“ bekannt.
Abweichung im Projekt:
Während der Release-Planung stellte der RE die Stories grob dem gesamten Team vor. Der Testmanager oder RE wies diese Stories dem jeweiligen Tester zu. Anschliessend wurden die zugewiesenen Stories in der Planungswoche zuerst zwischen RE und Entwickler und im Anschluss zwischen RE und Tester oder Entwickler und Tester betreffend Akzeptanzkriterien mündlich besprochen. Der Tester war für die Vollständigkeit dieser Kriterien verantwortlich.
Vorteil dieser Abweichung:
Die Stories waren zwischen Entwickler und RE vorerst auf Machbarkeit und Akzeptanzkriterien besprochen und festgelegt worden. Der Tester konnte die Ergebnisse niederscheiben und diese beim Testing überprüfen.
Nachteil dieser Abweichung:
Eventuelle Rückfragen zur technischen Machbarkeit des Produkts seitens Tester konnten durch die getrennten Besprechungen erst spät beantwortet werden. Eine Verzögerung des Projektes könnte die Folge davon sein.
Stand-Up
Gemäss Scrum müssen Stand-up Meetings täglich stattfinden (daily scrum).
Abweichung im Projekt:
An den wöchentlichen Statusmeetings/Stand-ups wurde der Status des Fortschritts der Stories in Erfahrung gebracht. Dazu mussten die Tester und Entwickler den aktuellen Stand der Stories durchgeben (Probleme, Herausforderungen und der evtl. Fertigstellungstermin)
Vorteil dieser Abweichung:
Täglicher Zeitaufwand von 15 Minuten wurde gespart und das Testingteam wurde von seiner Arbeit nicht weggerissen.
Nachteil dieser Abweichung:
Probleme oder Unklarheiten wurden erst nach einer Woche zu Sprache gebracht.
Meine Sichtweise als Tester
Als Embedded Tester konnte ich Erfahrungen in verschiedenen Unternehmen und Projekten sammeln. Dabei habe ich bis heute den Lehrbuch-Scrum-Prozess noch nie vorgefunden. Meist ist es eine adaptierte Form, z.B. angepasst an die Unternehmenskultur, oder an die Prioritäten des Projektes. Bestimmte Teile von Scrum werden übernommen, andere entfallen. Mischformen mit Wasserfall-Methoden sind meiner Meinung nach ebenso die Regel, wie z.B. Ausfall oder Nichtpraktizierung von bestimmten Bestandteilen oder Ritualen, die als nicht prioritär oder ineffektiv erachtet werden. Oft ist es auch so, dass man von Lieferanten abhängig ist und nicht zu 100 Prozent Scrum anwenden kann (Beispiel: Lieferant arbeitet nach Wasserfallmodell). Ein Nachteil daraus kann sein, dass die Informationen zu spät oder gar nicht fliessen, wenn Stand-ups mit dem Lieferanten zu selten (oder gar nicht) durchgeführt werden.
Diese doch häufigen Mischformen von Scrum zeigen, dass Unternehmen eher individuelle Formen aus verschiedenen Modellen benötigen. Grundsätzlich spricht nichts dagegen, dass ein Unternehmen in der Gestaltung und Umsetzung eines Prozesses flexibel bleibt aber es ist auch wichtig, dass die Essenz des Scrum-Prozesses, nämlich die Agilität und stetige Kommunikation, nicht verloren gehen. Stetige Kommunikation aller Beteiligten trägt zur Verbesserung des Produktes bei und Missverständnisse können zum grössten Teil rechtzeitig eliminiert werden.
Meine Empfehlungen sind:
- Iterationslängen auf maximal zwei Wochen beschränken und auf die fixen Längen achten. Somit verlieren Retrospektiven nicht an Aktualität und Infos und Anregungen gehen über Längere Zeit nicht verloren
- Tester sollten ein fester Bestandteil des Entwicklungsteams sein
- Die Anzahl der Entwickler und Tester sollte nicht zu stark voneinander abweichen. Das optimale Verhältnis liegt bei 1:3 (Tester zu Entwickler)
Aus meiner Sicht kann Scrum zwar in vielen Projekten erfolgreich eingesetzt werden, aber es ist schwer für die Unternehmen Scrum in seiner ursprünglichen Form umzusetzen. Gründe dafür können bei der Unternehmensstruktur oder gewissen Gewohnheiten im Ablauf liegen. Ein erfahrener Coach kann hierbei helfen, das Vorgehen für die Firma zu adaptieren.
