Agiles Schwärmen: Die Entwicklung jenseits von Scrum

In diesem Blog geht es um unsere Reise und Entwicklung als 'agiles' Team. In den ersten Tagen waren wir nicht einmal annähernd ein gutes Team, aber heute kann ich mit Stolz sagen, dass wir Fortschritte gemacht und uns zu einem wirklich agilen Team entwickelt haben.   Wie viele andere folgen auch wir der Scrum-Methodik und werden daher in diesem Artikel hauptsächlich die Scrum-Terminologie verwenden.

Ich möchte Ihnen einige Höhepunkte unserer agilen Reise von Stufe 0, wo wir dachten, dass wir agil sind, aber keineswegs, bis zu Stufe X, wo wir bewiesen haben, dass wir "Ja, wir sind agil".

Phase 1: Ausgehend von den Definitionen...

Als wir die Reise begannen, folgten wir den Scrum-Zeremonien als eine festgelegte Vorgehensweise, anstatt ihre Absicht und ihren Wert in den Mittelpunkt zu stellen.

Bei den täglichen Standups beantwortete jeder die 3 Fragen mit Leichtigkeit, wie ein Student, der in einem Prüfungssaal sitzt und die Antworten auf jede Frage kennt. Bei der Retrospektive gab es einen weiteren Satz von 3 Fragen. Es war gewissermaßen eine Konzentration auf sich selbst.

Phase 2: Das Wesentliche verstehen...

Wir erkannten, dass das bloße Befolgen verschiedener Scrum-Zeremonien gemäß ihrer Lehrbuchdefinition uns nicht weiterbringt. Wir begannen, die wahre Essenz jeder Zeremonie zu erkennen, und statt zu tun, begannen wir, den Prozess zu genießen.

In den täglichen Standups begann jeder zu beschreiben, was er im Hinblick auf die Sprint-Ziele getan hat, anstatt über ein bestimmtes Thema zu sprechen. Wir begannen, die Sprint-Retrospektiven als Plattform zur Verbesserung des Prozesses zu betrachten und verfolgten verschiedene Wege (die Spaß machen, aber sehr effektiv sind), um die Teamziele für diesen Sprint zu erreichen. Es gab viele Diskussionen, in denen wir überlegten, wie wir die wichtigsten Aussagen in den Retrospektiven herausstellen könnten und auch ein klares Nein, wenn jemand in einem Sprint nicht in der Lage war, eine Sache auszuwählen.

Phase 3: Vom agilen Team zu einem agilen Team werden

In einem Scrum-Team besteht das Hauptziel eines Sprints darin, am Ende ein potenziell lieferbares Inkrement zu liefern.  Obwohl das Team geplant hat, im Rahmen des Sprints eine bestimmte Anzahl von Stories zu liefern, können diese manchmal nicht innerhalb des Zeitrahmens fertiggestellt werden.

Hier ist ein Sprint, in dem wir nicht alle Storys abgeschlossen haben. Wir wollten nur eine Rückschau halten, warum wir einige Stories verpasst haben.

Das Retro ging so ...

Product Owner: Nun, ich bin nicht zufrieden, nicht weil wir nicht alles fertiggestellt haben, sondern weil wir es versäumt haben, den Punkt mit der höchsten Priorität in diesem Sprint umzusetzen. Möchten Sie wissen, warum wir es versäumt haben und was wir tun können, um solche Vorfälle in zukünftigen Sprints zu vermeiden?

Sofort schaute das gesamte Team auf einen bestimmten Entwickler (X), der während des gesamten Sprints daran arbeitete.

X begann zu erklären, was schief gelaufen war, und das gesamte Team gab seinen Input.

Anschließend besprachen wir auch den Status der verbleibenden Spillover-Storys und stellten fest, dass alle diese Storys zu etwa 70 - 90 % fertig waren und mit etwas mehr Zeit auf "fertig" hätten gestellt werden können, aber die Sprintdauer ist festgelegt und kann nicht geändert werden!!!

Bei der Betrachtung dieser beiden Vorfälle sind wir zu folgenden Schlussfolgerungen gelangt:

1. Begehen wir eine bestimmte Geschichte als Einzelperson oder als Team? Wenn wir uns als Team engagieren, wer ist dann für die Fertigstellung verantwortlich? Natürlich ist das Team dafür verantwortlich und nicht einzelne Teammitglieder.
2. Es ist immer besser, 70% der User Stories zu 100% fertig zu haben, als 100% der User Stories zu 70% fertig zu haben.

Als wir nach Möglichkeiten suchten, unsere Teamleistung zu verbessern, hörten wir von Mob Programming und Agile Swarming. Hier ist ein kurzer Überblick über diese agilen Techniken:

Was ist Mob Programming?

Laut Woody Zuill, dem Erfinder dieser Technik, ist Mob Programming definiert als:

All die brillanten Köpfe, die gemeinsam an der gleichen Sache arbeiten, zur gleichen Zeit, im gleichen Raum und am gleichen Computer.

Gemäß der obigen Definition sitzt bei dieser Technik eine Gruppe von Personen vor einem großen Monitor oder Projektor, der mit einem Computer verbunden ist. Zu einem bestimmten Zeitpunkt übernimmt eine Person die Führung und führt die Anweisungen der Gruppe aus.

Wie funktioniert der Mob in einem Sprint?

Es gibt nur einen Gegenstand in WIP(Work In Progress). Der Mob geht nur dann zu einem anderen Punkt über, wenn es ein Hindernis gibt und er nicht weiterkommt oder wenn der aufgegriffene Punkt auf erledigt gesetzt wird. Mit dieser Technik können Sie sicher sein, dass Sie, auch wenn der Sprint nicht perfekt verläuft, nicht mit einem Haufen halbfertiger Geschichten dastehen.

Vorteile der Mob-Programmierung

Mob schafft eine Situation mit einem Paar Händen und mehreren Gehirnen. Da sich das gesamte Team auf eine einzige Aufgabe konzentriert, wird die Geschwindigkeit, mit der eine Geschichte fertiggestellt wird, beschleunigt. Diese Technik ermöglicht mehr Wege, um die Lösung für ein komplexes Problem zu finden, und das Team beginnt, die Stärken und Schwächen des jeweils anderen zu verstehen.

Sie werden ein besseres Team als zuvor. Es gibt viele weitere Vorteile der Mob-Programmierung:

• Keine Abhängigkeit von einem einzelnen Teammitglied, da der gesamte Kontext beim gesamten Team liegt
• "Learning by doing" und Wissenstransfer in Echtzeit
• Es wird keine zusätzliche Zeit für die Codeüberprüfung benötigt, da das gesamte Team weiß, wofür jede Codeänderung da ist...
• Sie lernen und verbessern sich als Team und nicht als Einzelperson.

Als wir die potenziellen Vorteile erkannten, wollten wir mit der Implementierung von Mob Programming beginnen. Aber die Implementierung stellte uns vor eine Herausforderung, da unser Scrum-Team aus Mitgliedern von mehreren geografischen Standorten mit einem erheblichen Zeitzonenunterschied besteht.

Dann haben wir uns Swarming angeschaut.

Was ist Swarming in Agile?

Bei der Schwarmtechnik wird das gesamte Team (oder ein erheblicher Teil der Ressourcen) einer einzigen Aufgabe (auch Story genannt) zugewiesen, damit die anstehende Arbeit effektiver erledigt werden kann.

Was sind die verschiedenen Rollen?

Swarmer: Ein Swarmer ist eine Person, die von einer Geschichte zur nächsten zieht und ihre Fähigkeiten oder ihr technisches Know-how dort anbietet, wo sie gebraucht werden.

Koordinator: Ein Koordinator ist eine Person, die für eine Story verantwortlich ist. Eine Person kann immer nur für eine Geschichte zuständig sein, kann aber für andere Geschichten ein Schwärmer sein.

TeamLet: Ein TeamLet ist eine Gruppe von Personen, die an einer bestimmten Geschichte arbeiten, und jedes TeamLet hat einen Koordinator mit einem oder mehreren Schwärmern.

(Quelle: educba swarming technology)

Nun, wir haben beschlossen, Swarming auszuprobieren, indem wir zwei TeamLets mit zwei Gegenständen in WIP wie unten beschrieben bilden:

1. Wir begannen mit zwei TeamLets, einigen ständigen Schwarmarbeitern (QA, Functional Consultant) und einem Schwarmarbeiter, der sich bei Bedarf jedem Team anschließen kann.
2. Sobald eine Story von einem TeamLet aufgegriffen wird, werden alle Schritte besprochen, die erforderlich sind, um die Story gemäß der Definition of Done (DoD) zur Fertigstellung zu bringen.
3. Am Ende der Diskussion wird der Koordinator für die jeweilige Geschichte bestimmt, die Fortschritte überprüft und alle Erkenntnisse miteinander geteilt.

Was waren die Ergebnisse?

• Anfänglich gab es einige Befürchtungen, dass die Teammitglieder nicht ausreichend ausgelastet sein könnten. Wenn man sich das Tempo ansieht, mit dem eine Geschichte zu Ende gebracht wird, und wie gut die Kommunikation in einem TeamLet funktioniert, hat das Team keine Unterauslastung bemerkt. Niemand fühlte sich überlastet oder war auf die Hilfe anderer angewiesen.
• Die Anzahl der beim Testen der Stories gemeldeten Fehler ist deutlich zurückgegangen, da es zur Routine geworden ist, die Regressionstests bereits in der Entwicklungsphase durchzuführen.
• Wir haben eine deutliche Veränderung in den Product Backlog Refinement-Sitzungen festgestellt. Durch die stärkere Einbindung des Teams gibt es kein Zögern mehr, seine Ansichten mitzuteilen und Erklärungen zu geben, indem man sich auf kürzlich abgeschlossene Stories bezieht.
• Wir haben gute Fortschritte in der Burndown-Tabelle und Konsistenz in der Sprint-Geschwindigkeit gesehen.

Fazit: Unserer Erfahrung nach haben wir durch die Einführung von Agile Swarming erhebliche Produktivitätsgewinne erzielt. Endlich, nach einer langen Reise, genießen wir die Vorteile, ein echtes Team zu werden, und haben verstanden, dass es darauf ankommt, als TEAM zu denken und gemeinsam zu handeln. Wir sind stolz, sagen zu können, dass wir jetzt wirklich "AGILE" sind.