Kolumne: Groß und (Fr)agil?

Wissen ist Macht: Wie Sie Wissen effizient teamübergreifend austauschen

Christoph Niemann

(c) Shutterstock / eelnosiva

Im dritten Teil der Kolumne „Groß und (Fr)agil?“ greift Christoph Niemann ein Thema heraus, mit dem jedes Entwicklerteam umgehen muss: Es geht um die Frage, wie sich die immer vorhandenen Wissensunterschiede im Team ausgleichen lassen. Wie stellt man sicher, dass wichtiges Know How nicht siloartig an Einzelpersonen hängen bleibt?

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen. Heute geht es darum, wie Sie Wissen effizient zwischen vielen Menschen und teamübergreifend austauschen.

Wissen ist Macht

Kommunikation und der damit verbundene Transfer von Wissen ist ein elementares Prinzip von Agilität. Sichtbar wird das schon im Daily Scrum, wenn die Mitglieder eines Scrum-Teams sich über Fortschritte, Ziele und Hindernisse austauschen. In einem agilen Projekt mit mehr als einem Team reicht der tägliche 15-Minuten-Termin nicht: Um Abhängigkeiten zwischen Teams zu identifizieren oder alle Teammitglieder über neue Komponenten zu informieren, brauchen Sie zusätzlich Kommunikation über Teamgrenzen hinweg. Ein informeller Austausch wird hier schnell ineffektiv, es geht zu viel Wissen verloren oder es gibt keine gemeinsame Wissensbasis mehr.

Ein dezidierter Rahmen wie das „Scrum of Scrums“ hilft aus unserer Erfahrung: Zwei- bis dreimal pro Woche nimmt ein Abgeordneter aus jedem Scrum-Team an diesem zusätzlichen Regel-Meeting teil. Jeder Abgeordnete kommuniziert in Analogie zum Daily Scrum Fortschritte, Ziele und Hindernisse seines Teams und diskutiert aktuelle Probleme im Projekt. Dadurch verteilt sich das Wissen über den gesamten Fortschritt allen Teams. Denn: Die geteilten Informationen nehmen die Abgeordneten natürlich wieder mit zurück in die Teams und kommunizieren sie dort. Es ist wichtig, als Vertreter stets diejenige Person im Team zu wählen, die zum aktuellen Zeitpunkt potenzielle Probleme im Projekt verstehen und kommentieren können. Je nach Art des Problems bietet sich hierfür der Scrum Master, ein Entwickler oder aber ein Tester eher an. Ideal ist es, wenn die Teilnehmer rotieren: Es nimmt immer derjenige teil, der sich im letzten Sprint intensiv mit einem Thema auseinandergesetzt hat.

Ein weiterer Vorteil eines institutionalisierten Scrum of Scrums ist das Erkennen von übergreifenden Impediments: Oft treten Probleme in mehreren Teams parallel oder kurz nacheinander auf. Solche übergreifenden Hindernisse kommen im Scrum of Scrums schnell zur Sprache, die Scrum-Master können sich dann darum kümmern. Ohne den Informationsaustausch bleiben sie unerkannt.

Mein Tipp: Verteidigen Sie Scrum of Scrums als Arbeitstreffen, in dem Vertreter der Teams ihre Arbeit inspizieren und adaptieren. So verhindern Sie, dass Scrum of Scrums als Statusreport-Meeting vom Management gekapert wird oder sich zum Koordinationstreffen der Scrum-Master entwickelt. Für beides gibt es andere Regeltermine oder Maßnahmen, etwa gemeinsame Retrospektiven.

Ergebnisse der SoS-Treffen teilen Sie auf einem Team-übergreifenden Impedimentboard. So behalten alle das Ziel im Blick: mit mehreren Teams ein gemeinsames Sprint-Ziel erreichen.

Groß und (fr)agil?

In der Kolumne Groß und (fr)agil? stellen Christoph Niemann und Timo Becker (MaibornWolff) Lösungsansätze vor, um agile Entwicklung auf große Szenarien zu skalieren. Ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!

Bisher erschienen:

Im Team selbst liegt Spezialwissen bei einigen wenigen Personen: Sie sind meist (unbesungene) Helden im Team; ihnen droht wie einem PO mit vielen Teams die Überlastung. Um auch deren Wissen im Team zu verteilen – und die feste Rollenzuteilung von Entwickler, Tester, Business-Analyst und so weiter aufzubrechen –, haben wir gute Erfahrungen mit Pair-Programming oder der Extremform „Mob-Programming“ gemacht. Im Pair-Programming sitzen immer zwei Beteiligte an einem Rechner: einer entwickelt, der andere denkt mit. Der Entwickler ist dabei oft auf einer sehr detaillierten Ebene des Problems unterwegs. Der „Beifahrer“ muss den Detailgrad nicht denken, er kann stattdessen das Gesamtbild im Auge behalten.

Wenn die beiden Kollegen unterschiedlich erfahren sind, profitiert der unerfahrenere Kollege besonders davon, am Rechner zu sitzen und zu entwickeln. Das kostet zunächst Überwindung, hilft aber dabei, Wissen vom einen in den anderen Kopf zu bekommen.

Eine extreme Form ist das Mob-Programming: Hier teilen sich nicht zwei Kollegen einen Rechner, sondern das gesamte Team. Einer entwickelt, die anderen denken mit. Natürlich entwickelt eine Person nicht die Features eines ganzen Teams in der gleichen Zeit. Der Gewinn ist dafür eine „Weiterbildung“ des gesamten Teams. Nach einer Mob-Programming-Session braucht es eigentlich nicht einmal mehr ein Daily, das gesamte Team war ohnehin an der gesamten Entwicklung beteiligt. So verteilt sich Wissen sehr zuverlässig im Team. Besonders lohnt sich das Mob-Programming daher für komplizierte, nicht-triviale Features. Bevor einer das Feature entwickelt und die Implementierung danach allen erklärt, lohnt sich die direkte gemeinsame Entwicklung.

Welche Erfahrungen haben Sie mit dem Wissenstransfer im Team gemacht? Was funktionierte gut, was weniger gut? Wir freuen uns auf Ihre Kommentare!

Aufmacherbild: elephant running across a tightrope von Shutterstock / Urheberrecht: eelnosiva

Geschrieben von
Christoph Niemann
Christoph Niemann
Christoph Niemann ist IT-Consultant bei MaibornWolff. Er arbeitet am liebsten im agilen Requirements-Engineering an der Schnittstelle zwischen Fachbereich und Entwicklungsteam. Mit seiner agilen Erfahrung, besonders mit Scrum, hilft er Projekten beim Umbau vom Wasserfallmodell auf ein iteratives Vorgehen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: