Heutzutage kommt keiner in der Software-Branche an dem Begriff „agil“ vorbei. Das war sicher auch der Grund, weshalb in meinem aktuellen Kundenprojekt beschlossen wurde, dass der komplette Prozess neu strukturiert werden soll. Wichtig war vor allem eins: Er sollte agil werden. Das Ziel war eine Verbesserung auf allen Ebenen.
Tatsächlich war und ist die Umstellung eines jahrelangen – und auch irgendwie funktionierenden – Projekts auf ein neues Vorgehen nicht gerade das Einfachste, was sich ein Team vornehmen kann. Das mussten nicht nur der Product Owner (PO) und die Entscheidungsträger erfahren, sondern insbesondere die Entwickler und Tester. Während der noch andauernden Umstellung sind u. a. uns Testern Punkte aufgefallen, die verändert werden mussten. Diese möchte ich hier gern reflektieren, da sie anderen Teams in ähnlichen Situationen hilfreich sein könnten.
Für unser Team waren diese Herausforderungen zwar viel Arbeit, aber diese zu bewältigen, war schlussendlich ein wichtiges Erfolgserlebnis.
Neuer Refinement-Prozess und fehlende Akzeptanzkriterien
Etwas, das grundlegend neu definiert wurde, war der komplette Workflow – von Anforderungsdefinition über die Entwicklung bis hin zum Testen der Anwendung. Hier wurde ein neuer Refinement-Prozess eingeführt, der durch eine feste Struktur der JIRA-Tickets eine bessere Bearbeitung der Aufgaben gewährleisten sollte.
Um diese standardisierten Inhalte festzulegen, wurde das Team von Entwicklern und Testern leider nicht mit einbezogen. Das führte dazu, dass bei den ersten Durchläufen nach dem neuen Vorgehen die Akzeptanzkriterien fehlten. In den Tickets stand keine Definition, gegen die getestet werden konnte.
Verbesserungsvorschlag
In unserem wöchentlichen Tester-Standup brachten wir zur Sprache, dass ein Arbeiten nach diesem Vorgehen für die Tester nicht adäquat möglich sei. Wir wiesen außerdem darauf hin, dass es sinnvoll wäre, die Mitarbeiter im Projekt einzubeziehen, um die Inhalte für das Refinement zu definieren. Wir schlugen vor, dass sowohl die Fachabteilung als auch die Entwickler und Tester ihre Anforderungen an ein gutes Ticket formulieren sollten, um daraus eine Definition of Ready (DOR) Richtlinie ableiten zu können.
Dieser Vorschlag wurde zeitnah umgesetzt und angewandt. Die Akzeptanzkriterien für den Test sind nun fester Bestandteil der Tickets und es kann ohne Nachfragen dazu getestet werden.
Einbindung des Teams und Leben der agilen Vorgehensweise
Ein weiteres Problem, das mit dem ersten Thema einherging, war der fehlende Dialog mit den Teammitgliedern. Am Anfang wurde die Umstellung auf das agile Vorgehen lediglich „von oben“ delegiert. Schon allein dieser Fakt spricht gegen ein agiles Vorgehen, bei dem der Mensch im Fokus stehen soll. Zusätzlich wurde eine beliebige Methodik über das existierende Projekt und seine Mitarbeiter gestülpt. Das traf verständlicherweise auf Widerstand. Die Kollegen fühlten sich nicht nur übergangen, sondern wurden in eine Prozess-Schablone gepresst, die weder auf das Projekt zugeschnitten war, noch zu den Mitarbeitern passte. Die allgemeine Stimmung im Projekt war angespannt und das Arbeiten ineffektiver.
Ein Tester ist die letzte Station im Entwicklungsprozess der Software, bevor diese letztlich den Kunden erreicht. Dazu müssen wir uns in die Fachabteilung und ihre Belange hineinversetzen, mit den Entwicklern, dem PO sowie anderen Abteilungen abstimmen und dabei immer die Qualität an die erste Stelle setzen. Zudem kommt jeder vorab im Prozess enthaltene Fehler potenziert beim Tester an. Das bringt uns den entscheidenden Vorteil, dass wir den Überblick über den ganzen Prozess gewinnen, weil wir aus jedem Bereich ein kleines Stück erfahren. Somit fällt uns auch die Reflektion eventueller Schwachstellen leichter.
Verbesserungsvorschlag
Diesen Vorteil haben wir genutzt und den PO informiert, dass während der Einführung eines agilen Prozesses unbedingt die Mitarbeiter einbezogen werden müssen. Schließlich sind es die Mitarbeiter, die den neuen Prozess tragen und leben sollen. Weiterhin ist es wichtig, nicht eine Methode X zu betrachten und sie Eins zu Eins auf das Projekt zu übertragen. Aus unserer jahrelangen Projekterfahrung konnten wir berichten, dass die Methodik zum Projekt und den Mitarbeitern passen muss, um effektiv zu sein. Und dazu ist es wichtig, dass nicht nur eine einzige Methode ins Auge gefasst wird, sondern mehrere Vorgehen kombiniert und kleine Stücke schrittweise angepasst und ausprobiert werden.
Auch dieser Vorschlag wurde ernst genommen und mehrere Meetings anberaumt, um Unstimmigkeiten zu klären und Schwachstellen zu eliminieren. Es wurden To-dos definiert und der Dialog gesucht. Die Stimmung im Projekt hat sich dadurch maßgeblich entspannt und das Arbeiten funktioniert wieder flüssiger.
Das Stiefkind Automatisierung
Während der Prozess-Umstellung sollte auch der wichtige Punkt der Automatisierung ernster angegangen werden. Vom Tester bis hin zu den Entscheidungsträgern waren sich alle einig über die Wichtigkeit und Dringlichkeit dieses Themas. Allerdings verschwand das Thema aufgrund der vielen Schwierigkeiten während der Einführung des neuen Prozesses von der Agenda.
Verbesserungsvorschlag
Zunächst wurde seitens des Tests immer wieder nachgehakt, aber auch Informationen gesammelt sowie Tools empfohlen und diese auf Tauglichkeit geprüft. Der Kontakt zu Schlüsselpersonen, die mit diesem Thema verknüpft sind, wurde aktiv gesucht. Hier war besonderes Fingerspitzengefühl gefragt, um zuweilen den richtigen Moment abzupassen. Alle Informationen wurden regelmäßig an den PO gemeldet und in regelmäßigen Abständen nach dem Fortschritt dieser Maßnahme gefragt.
Diese Hinweise wurden ebenfalls aufgenommen und das Thema weiter oben auf der Agenda platziert. Der PO beraumte Treffen mit den Entscheidungsträgern an und wird sich weiterhin für eine Vorankommen im Bereich der Automatisierung einsetzen. Die Festlegung auf ein Tool, die Eingliederung in den Prozess sowie die Frage der personellen Aufstockung stehen noch aus.
Fazit
Zusammenfassend hat sich meine Erfahrung bestätigt, dass die Umstellung bestehender Prozesse auf ein anderes Vorgehen nur mit psychologischem Geschick, dem Fokus auf das Wesentliche und im Dialog mit den Teammitgliedern gelingen kann. Eines braucht eine solche Umstellung jedoch immer: Genügend Zeit. Darum ist es zwar wichtig, einen Prozess voranzutreiben – mindestens genauso wichtig ist es jedoch, den richtigen Momenten abzuwarten, um zum richtigen Zeitpunkt das volle Potenzial zu nutzen und Chancen zu ergreifen.
Als Tester in diesem Kundenprojekt konnte ich beobachten, dass es für eine Umstrukturierung empfehlenswert ist, einige Beteiligte auf allen Ebenen eines Projekts zu haben, die bereits agil gearbeitet haben. So können deren Erfahrungen mit einbezogen werden und einen wichtigen Beitrag zur erfolgreichen Umsetzung leisten. Gegebenenfalls kann dazu auch externe Unterstützung eingeholt werden. Rückblickend war es in diesem Kundenprojekt von Vorteil, dass sowohl die ZEISS Digital Innovation GmbH als auch ich selbst auf unsere Erfahrungen mit agilen Vorgehensweisen zurückgreifen konnten.
Dieser Beitrag wurde verfasst von:
