Agile Software-Entwicklung wird heutzutage in fast jedem Unternehmen gelebt. Aber was genau bedeutet dies für die Teamorganisation? Was sind die Aufgaben? Mit welchen Challenges ist man in einer Organisationsrolle täglich konfrontiert? Gibt es überhaupt eine solche Tätigkeit in agilen Teams?
Mein Erfahrungsbericht beweist, dass es manchmal doch etwas mehr braucht als nur Selbstorganisation.
Ich begann meine Tätigkeit im Projekt als Test Engineer. Dabei bestand mein Alltag aus Test Case Design, Task Verification und Software Spezifikation Review. Während der Software-Verifizierungsphase verliess jedoch der Test Manager das Projekt. Daraufhin fragte mich der Projektleiter ob ich nicht die Organisation eines der beiden Test Teams übernehmen könnte. Die Aufgabe klang für mich sehr spannend und ich erklärte mich bereit das Team zu organisieren. Ich hoffte, dass ich in der neuen Position die Chance hatte einige Mängel, welche mir in meiner Zeit als Test Engineer aufgefallen waren, im Projekt zu beseitigen.
Team organisieren
Da ich bereits länger im Test Team tätig war und die Mängel kannte, wusste ich bereits was als erstes zu tun ist. Mein erstes Ziel war es ein Kanban Board und einen Daily Standup einzuführen. Dies führte zu grösserer Transparenz und lies das Team sich selbst organisieren. Doch dabei stiess ich auf erheblichen Widerstand aus dem Team. "Das ist doch Zusatzaufwand", "Was bringt das überhaupt" und "Ich will nicht Kärtchen schieben" musste ich mir täglich anhören. Es benötigte viel Überzeugungsarbeit, aber nach mehreren Wochen haben sich alle Teammitglieder an das Kanbanboard und die Standups gewöhnt, es gefiel den meisten sogar. Die Transparenz war nun geschaffen und Bottlenecks konnten früher entdeckt werden.
Selbstorganisation fördern
Jedoch fing das Team an sich auf mich als Organisationskraft zu verlassen. Ich begriff schnell, dass dies mit Nachteilen verbunden ist. Wie kommt das Team klar, falls ich mal krank oder in den Ferien sein sollte? Dies brachte mich zu meinem zweiten Ziel. Als zweite Aufgabe habe ich das Team zur Selbstorganisation ermutigt. Dies dauerte etwas länger als die Einführung des Kanban Boards. In den Köpfen der Teammitglieder musste ein Umdenken stattfinden. Sie waren es gewohnt einen Teamleiter zu haben, der alle organisatorischen Probleme regelt und jedem einzelnen Teammitglied Aufgaben zur Abarbeitung zuweist. Nach einem Lernprozess haben die Teammitglieder selbstständig angefangen, das Board zu erweitern. Tasks wurden selbstständig priorisiert und zur Abarbeitung vom Board genommen. Schon bald lobte die Projektleitung das Team mehrmals und benutzte das Kanban Board als plakatives Beispiel für Selbstorganisation im Projekt.
Rahmen zur Selbstorganisation setzen/halten
Nach geraumer Zeit entschied ich mich eine Woche in die Ferien zu fahren. Bei meiner Rückkehr musste ich zu meinem Bedauern feststellen, dass die Selbstorganisation über den Haufen geworfen wurde.Der Projektleiter hatte die Priorisierung der Tasks kurzerhand selbst vorgenommen. Ich merkte schnell, dass das Problem darin lag, dass die Rahmenbedingungen für Selbstorganisation nicht mehr gegeben waren. Ich suchte das Gespräch mit der Projektleitung und bot mich selbst in Sachen Priorisierung von Tasks als "Single Point of Contact" an. Die sich ständig ändernden Prioritäten trug ich in die Planungs-Meetings mit dem Team und es wurde eine gemeinsame Priorisierung der Tasks unter Berücksichtigung der Wünsche des Projektleiters durchgeführt. Die Rahmenbedingungen für Selbstorganisation waren somit wieder hergestellt und ich konnte mich der nächsten "Challenge" des Projektes stellen.
Angst vor einer Aufwandsschätzung nehmen
Eine wichtige Komponente der Agilität ist die Velocity. Diese erlaubt es dem Team eine bessere Schätzung und Planung anhand der gemessenen Velocity durchzuführen. Da das Test Team noch nie die eigene Velocity gemessen hat, war es für den Test Manager und das Team schwierig eine Schätzung anstehender Test Tasks abzugeben.
Als die Projektleitung mich um eine Schätzung des Testaufwands für den anstehenden Release bat, wollte ich eine Schätzung gemeinsam mit dem Team abgeben. Nach mehreren Versuchen den ersten Task zu schätzen fiel mir jedoch auf, dass die Mitglieder Furcht vor der Schätzung entwickelt hatten, da diese in der Vergangenheit immerzu als harte Deadline definiert wurde und nie gehalten werden konnte. Es wurde auch keine Anpassung der Schätzung bei sich ändernden Projektrahmenbedingungen akzeptiert.
Meine Aufgabe bestand also darin, dem Team die Angst vor einer Schätzung zu nehmen und gleichzeitig realistisch zu schätzen. Ich entwickelte eine Strategie für das Team.
1. Zuerst wurde eine Handvoll Tasks geschätzt und an die Projektleitung kommuniziert. Hierfür wurden relative Werte - keine Zeitangabe - verwendet. Hierbei halfen uns die Priority Poker Karten.
2. Nach der Messung der Zeit für die Umsetzung der geschätzten Tasks (Velocity) zeigte ich dem Team, wie viele Tasks es pro Woche umsetzen kann. Daraufhin wurde eine weitere Schätzung anhand der Velocity gemacht. So verbesserte sich die Schätzung des Teams kontinuierlich und die Angst vor dem Schätzen ist verschwunden. Seitdem schätzt das Team in Meetings (alle zwei Wochen) anstehende Tasks und kommuniziert die Schätzung an das Management.
Retrospective Meetings einführen
Langsam aber sicher konnte ich beobachten wie das Team eine Eigendynamik entwickelte. Vereinzelte Teammitglieder analysierten die getane Arbeit und brachten Verbesserungsvorschläge an. Diese wurden jedoch von niemandem getrieben. Daraus ergab sich eine weitere Aufgabe für mich.
Ich führte ein Retrospective Meeting für das Test Team ein. In dem Meeting wurde die Arbeit der letzten drei Wochen besprochen und Verbesserungsideen erarbeitet. Daraufhin wurden daraus Tasks abgeleitet und in den Backlog aufgenommen.
Das Test Team organisierte sich also selbst und hat eine stabile Velocity entwickelt. Man konnte sagen, dass das Team eine Transformation zum agilen Test Team begonnen hat. Der nächste Schritt wäre eine Integration der Test Team Mitglieder in die Scrum Teams, um das Testing noch agiler zu gestalten. Somit könnten die Tester als Scrum-Teammitglieder frühzeitig testen und schnelleres Feedback an die Developer liefern (entsprechend dem Agile Testing Framework).
Fazit
Meine Erfahrung hat mir gezeigt, dass Agilität im Team nicht immer heisst dem Team uneingeschränkte Freiheit einzuräumen. In gewissen Situationen braucht es eine organisatorische Komponente, um Konflikte zu lösen, die Kommunikation zu fordern oder das Team auf ein gemeinsames Ziel einzuschwören. Dies gilt für jede Art von Team, nicht nur das Test Team. Agilität ist also eine Mischung aus Organisation und Selbstorganisation.
Laut agilem Manifest ist es auch wichtig auf Veränderungen schnell zu reagieren. Deshalb sollte ein Team die kontinuierliche Verbesserung (KVP) anstreben. Am Besten wäre es, wenn das gesamte Team ein KVP-Mindset entwickelt. Dabei muss man auch mutig genug sein die gegebenen Vorgehensweisen und Prozesse kritisch zu hinterfragen und die Verbesserungsvorschläge an die richtigen Entscheidungsträger zu schicken.
Weiterhin sagt das agile Manifest, dass es um Individuen und Interaktionen geht. Deshalb ist die Kommunikation sehr wichtig. Werden Unstimmigkeiten bei Vorgehensweisen entdeckt, muss konstruktives Feedback schnell kommuniziert werden. Gleichzeitig muss es einen Treiber der Verbesserungsvorschläge geben, im Idealfall ist es das komplette Team.