Das selbstorganisierte Entwicklungsteam – ein Blick in die Praxis

Die meisten Software-Entwicklungsabteilungen werden das Problem kennen: Viele verschiedene Projekte in unterschiedlichen Phasen werden parallel von einzelnen, disjunkten Projektteams umgesetzt. Dazu kommen häufig „Einzelkämpfer“, die sich um Kleinstprojekte oder fortlaufendes Application Management kümmern. Ein Austausch zwischen den einzelnen Projektteams findet selten statt. Projekt-, Fach- und technisches Wissen entwickelt sich auf den einzelnen Projektinseln sehr unterschiedlich. Wenn ein Team im laufenden Projekt verstärkt werden muss, erzeugt dies hohe Einarbeitungsaufwände und führt zu Verzögerungen im ohnehin schon engen Zeitplan.

Auch bei IT-P begegneten wir diesen Herausforderungen regelmäßig. Im Entwicklungsbereich haben wir es mit immer wechselnden Projekten verschiedener Kunden aus diversen Branchen zu tun. Bei den meisten unserer Kunden begleiten wir die von uns entwickelte Software danach noch jahrelang im Application Management, also sporadischer Anpassung und Modernisierung. Auch die Projektmethodik ist vielfältig: Festpreis oder nach Aufwand, Werkvertrag oder Dienstleistung, Wasserfall oder agil, Product Owner auf Kundenseite oder bei uns, 10 Tage oder 20 Monate Umfang – alle Varianten sind bei uns anzutreffen. Das macht eine adäquate, dedizierte Ressourcen- und Zeitplanung mit einzelnen Teams quasi unmöglich. Kontinuität und Effizienz sind nur schwer zu gewährleisten.

Unsere Antwort: Das selbstorganisierte Entwicklungsteam

Vor etwa fünf Jahren beschlossen die Entwickler, in Zukunft ihre Projekte gemeinsam, agil und eigenverantwortlich umzusetzen. Sie gründeten ein selbstorganisiertes Entwicklungsteam – unser „Dev-Team“. Am Anfang stand etwas Aufwand, um die nötigen Voraussetzungen zu schaffen:

• Alle Kollegen sollen mit agilen Methoden vertraut sein.
• Jedes Projekt braucht einen internen Product Owner (PO) bzw. Projektleiter – möglichst eine Person außerhalb des Dev-Teams.
• Ein agiles Framework gibt dem Team das Gerüst für seine tägliche Arbeit.
• Eine digitales Board dient zur Übersicht und Nachverfolgung der anstehenden Projekte und Aufgaben.

Eine weitere wichtige Voraussetzung – ein gemeinsamer Technologiestack – war ebenfalls gegeben, da sich die Projekte, die das Dev-Team umsetzt, vorwiegend im Microsoft-Umfeld bewegen (.NET Framework, SQL Server, Azure DevOps, dazu Angular).

How it started …

Dank interner ‚Agile Coaches‘, vorhandener Erfahrung und Begeisterung für den „neuen Weg“ war das agile Mindset schnell in allen Köpfen verankert. Auch die PO-Rollen konnten wir zügig verteilen.

Als Framework entschieden wir uns für Scrumban, eine Mischung aus Scrum und Kanban. Scrumban wird häufig bei langlaufenden Projekten oder nicht klar abgegrenzten Anforderungen eingesetzt und verwendet „das Beste aus beiden Welten“.  Das Team einigte sich auf eine Sprintlänge von zwei Wochen. Ein Agile Coach begleitete das Team, damit es sich schneller in den Prozess einfinden konnte. Die Teammitglieder gaben sich zu Beginn selbst einen Codex und Richtlinien zur Entwicklung und Qualitätssicherung. Dazu gehören etwa Code Reviews, Coding Conventions, Definition of Done, Definition of Ready. Damit war gewährleistet, dass in allen Projekten einheitliche Standards galten, so dass die Entwickler sich schnell zurechtfinden konnten.

Ein passendes Planungswerkzeug (Board) hatten wir mit Microsoft Azure DevOps bereits im Einsatz. Hier wurden schon die Anforderungen und Arbeiten in den einzelnen Projekten dokumentiert, geplant und bearbeitet. Ergänzend kam jetzt noch ein weiteres, separates Azure DevOps-Projekt hinzu, um die projektübergreifende Grobplanung der einzelnen Sprints vorzunehmen und ein Backlog für das Team aufzubauen. Dieses Backlog enthält die Aufgaben nur bis zur Ebene der Backlog Items. Die Detailplanung der einzelnen Arbeitspunkte erfolgt weiterhin in separaten DevOps-Projekten, da wir Azure DevOps auch intensiv zur Zusammenarbeit mit unseren Kunden nutzen. Dieser Overhead der doppelten Pflege ist ist jedoch dank Verlinkung zwischen den Arbeitspunkten vernachlässigbar klein.

Als nächstes richteten wir die erforderlichen Meeting-Termine (im Scrum als „Events“ bezeichnet) und den Ablauf ein:

• Das Planning findet bei Bedarf statt. Hier bringen die PO ihre Anforderungen in Form von Backlog Items ein. Außerdem liefern sie dem Team eine grobe Zeitplanung für ihre jeweiligen Projekte, auch über den aktuellen Sprint hinaus. Hieraus ermittelt das Team die groben Aufwände für die einzelnen Items und legt die Prioritäten fest. Wir haben hierfür einen wöchentlichen Regeltermin als Blocker eingerichtet, der aber nur stattfindet, wenn das Team und/oder die PO ihn als notwendig erachten. Gleiches gilt für das Refinement.
• Im Daily Stand-up tauscht sich das Team – wie in Scrum üblich – über die Fortschritte und Hindernisse aus, hier allerdings projektübergreifend. Da die meisten Entwickler „T-shaped“ mit unterschiedlichen Spezialisierungen sind, ergeben sich hier häufig neue Ansätze zur Lösung bestimmter Aufgaben. Das Daily ist time-boxed auf 15 Minuten. Details klären wir bei Bedarf im Anschluss. Durch den regelmäßigen Austausch sind die Teammitglieder über den Stand in allen Projekten im Bild, auch wenn sie in diesem Sprint keine Aufgaben übernehmen.
• Die Reviews finden je nach Projektsituation gemeinsam mit dem Kunden oder Team-intern mit den jeweiligen PO statt. Alle, die in dem aktuellen Sprint am Projekt mitgewirkt haben, stellen die umgesetzten Anforderungen vor, und der PO nimmt die Anforderungen ab (oder versieht sie mit Anmerkungen für den folgenden Sprint, sofern noch Anpassungen erforderlich sind).
• Eine teaminterne Retrospektive bildet den Abschluss eines Sprints. Hier blicken wir kritisch auf den Prozess, die Organisation und die Zusammenarbeit und beleuchten positive wie negative Aspekte , um Verbesserungschancen zu ergreifen.

How it is going …

Wie üblich stand das nächste große Projekt schon vor der Team-Tür und wartete auf seine Umsetzung. Nach wenigen anfänglichen Holprigkeiten hatte sich das Team schnell in die neue Arbeitsform eingeschwungen, und die ersten positiven Effekte entfalteten ihre Wirkung: Naturgemäß hat jeder Entwickler neben  einer soliden Basis an Entwicklungs-Knowhow sein Steckenpferd – in unserem Team finden sich Architekten, ein DevOps-Spezialist, Frontend- und Backendzauberer und Datennmodellierer. Durch die Arbeit im Dev-Team kann jeder sich in allen Projekten mit seinen Spezialthemen einbringen. So baut der DevOps-Experte die Azure Build Pipelines für alle Projekte, wenn sie gebraucht werden, ohne dass Projektleiter A ihn sich erst bei Projektleiter B „ausleihen“ muss. Gleichzeitig trägt er sein Wissen in das Team und damit in die Breite, indem er in kurzen Workshops die Vorgehensweise erläutert. Die Architekten erarbeiten gemeinsam eine Software-Architektur und entwerfen ein Team-eigenes Framework, das sich schnell portieren lässt und Projekt-Setup und Entwicklungszeit verkürzt. Insgesamt ist die Arbeitslast jetzt auf mehr Köpfe und Schultern verteilt als vorher. Aufgaben können wir schneller und effizienter abarbeiten. Und bei Bedarf gehört ein Sprint eben nur einem einzelnen Projekt, wenn die Projektsituation dies erfordert. Entscheidend ist, dass das Team selbst festlegt, wie viele verschiedene Projekte und Themen es in einem Sprint bearbeiten wird, denn der Zeitverlust durch das sogenannte Context Switching, den häufigen Themenwechsel, ist ein nicht zu vernachlässigender Aspekt.

Eine größere Umstellung ergab sich dagegen für die einzelnen Product Owner und Projektleiter: Bisher hatten sie ein projektspezifisches, dediziertes Team zur Verfügung, dessen Ressourceneinsatz und Priorisierung allein ihrer Hand lag. Die Tatsache, dass in den Plannings eine Konkurrenzsituation um Teamzeiten und Prioritäten entstand, war zunächst ungewohnt und erforderte ein gewisses Umdenken. Aber nach kurzer Zeit wurden auch hier die Vorteile sichtbar: Da das Wissen auf mehr Schultern verteilt ist, lassen sich Abwesenheiten oder Urlaube besser kompensieren. Der Kollege mit Datenbank-Expertenwissen muss nicht aus einem anderen Team losgeeist werden, um im eigenen Projekt die SQL-Zugriffe zu optimieren – er ist bereits im Team und steckt auch fachlich im Thema.

Im Laufe der Zeit wurde noch ein weiterer Aspekt sichtbar, der initial gar nicht so sehr im Fokus der Teamgründung gestanden hatte: Die Qualiät der Software und das Skillset der Teammitglieder. Durch den selbstgegebenen Codex, der Code Reviews durch andere Teammitglieder zwingend vorschreibt, gibt es keine „Inseln“ mehr; der geschriebene Code wird immer kritisch in Augenschein genommen und kommentiert, was auf beiden Seiten – beim Coder und beim Reviewer – zu stärkerem Qualitätsdenken führt. Außerdem können beide Seiten voneinander lernen, wodurch der Skilllevel im Team steigt. Durch regelmäßiges Pair Programming findet das Team schneller Lösungen für komplexe Aufgabenstellungen.

Das selbstorganisierte Entwicklungsteam – Benefit für beide Seiten

Rückblickend sind sich Teammitglieder und POs einig, dass die Gründung des Dev-Teams ein voller Erfolg war. Wie in agilen Methoden üblich, wird in den Retrospektiven immer mal an kleineren Stellschrauben gedreht, aber das große Ziel haben wir erreicht: eine passende Antwort auf die geschilderten Herausforderungen zu finden. Gleichzeitig haben wir die Qualität der Software verbessert und das Skillset gestärkt und in die Breite getragen. Die Teammitglieder sind deutlich zufriedener: bei allen Retros wird „die Zusammenarbeit im Team“ als motivierender Faktor genannt. Und natürlich profitieren unsere Kunden von all dem ja auch: bessere Software, effizientere Entwicklung, viele (mögliche) Ansprechpartner und motivierte Entwickler – bleiben da noch Wünsche offen?