Kopfmonopole in agilen Teams erkennen und abbauen

Warum Kopfmonopole problematisch sind

Agile Teams sollen flexibel, selbstorganisiert und lieferfähig sein. Genau hier stehen Kopfmonopole oft im Weg. Wenn Wissen nur an wenigen Stellen vorhanden ist, lassen sich Aufgaben nicht mehr so einfach verteilen und Ausfälle nur schwer kompensieren. Das führt im Ernstfall dazu, dass Aufgaben nicht wie geplant fertiggestellt und Stakeholder vertröstet werden müssen. Eventuell werden sogar andere Teams blockiert, die von einer Zulieferung abhängig sind.

In der Praxis haben wir oft erlebt, dass Teams die Existenz von Kopfmonopolen bereits bewusst ist, der Umstand aber einfach ignoriert wird. Problematisch wird es dann, sobald Menschen mit Kopfmonopol ausfallen: Aufgaben können nicht übernommen werden, Sprintziele werden nicht mehr erreicht und die Roadmap muss überarbeitet werden. Das kostet alle Beteiligten Nerven und strapaziert das Produkt-Budget. Noch problematischer sind hingegen unbewusste Kopfmonopole, da diese überhaupt erst im Ernstfall auffallen.

Ein hilfreiches Konzept zur Beantwortung der Frage, ob in eurem Team Kopfmonopole existieren ist die Truck-Number. Die Frage dahinter lautet: Wie viele Personen dürfen ausfallen (von einem Truck überfahren werden), ohne dass ein Projekt oder Produkt nicht mehr sinnvoll weiterentwickelt werden kann? Je kleiner diese Zahl ist, desto größer ist das Risiko.

Gerade in größeren Teams entstehen Kopfmonopole oft in mehreren Dimensionen. Das kann sich zum Beispiel auf Teilprodukte oder Module, aber auch auf bestimmte Prozesse, Technologien, Tools oder fachliche Spezialthemen beziehen.

Kopfmonopole sichtbar machen: die Skillmatrix

Wenn du Kopfmonopole abbauen möchtest, musst du sie zunächst sichtbar machen. Denn oft ist dem Team gar nicht klar, wo Wissen stark konzentriert ist. Ein praktikables Werkzeug dafür ist die Skillmatrix. Eine Skillmatrix wird am besten gemeinsam durch das Team angefertigt, z.B. im Rahmen einer Retrospektive.

Voraussetzung für die Erstellung einer Skillmatrix ist eine gute Fehler- und Lernkultur. Wenn insbesondere mit Unwissen offen und wertschätzend umgegangen wird, fällt es Teams leichter, Wissenslücken offen anzusprechen. Sie sollten als Chance und nicht als Makel wahrgenommen werden.

Zur Erstellung der Matrix kannst du wie folgt vorgehen:

1. Die Teammitglieder sammeln zuerst die für ihr Team relevanten Skills, Technologien, Methoden, Prozesse oder Module.

2. Die Ergebnisse können gemeinsam mit dem Team nach den obigen (oder eigenen) Kategorien gruppiert werden und bilden dann die erste Achse der Skillmatrix.

3. Die zweite Achse bildet sich durch die Namen der Teammitglieder. Jedes Teammitglied bewertet dann für sich, wie gut es sich mit dem entsprechenden Thema auskennt.

Für den letzten Punkt hat sich eine einfache Ampelbewertung in der Praxis bewährt:

• Grün: Das Thema beherrsche ich sehr gut, Aufgaben dazu kann ich eigenständig bearbeiten
• Gelb: Ich benötige mehr Einarbeitung, Bearbeitung von Aufgaben ist unter Geschwindigkeitseinbußen möglich
• Rot: Ich habe kaum oder gar kein Wissen, Aufgaben kann ich nur nach ausgiebiger Einarbeitung bearbeiten

Solltet ihr die Erarbeitung der Skillmatrix in Präsenz durchführen, könnt ihr mit bunten Post-Its an einem Whiteboard arbeiten, remote bietet sich eine tabellarische Darstellung an. Hier ein Beispiel:

Mit dieser Darstellung wird schnell sichtbar, wo im Team bereits eine gute Wissensverteilung vorhanden ist und wo bestimmte Themen noch stark an einzelnen Personen hängen.

Besonders hilfreich ist die Skillmatrix auch mit Blick auf die Truck-Number: Bei welchen Themen wären noch andere Personen arbeitsfähig, wenn eine bestimmte Person ausfällt? Genau diese Frage macht Risiken oft sehr schnell greifbar.

Du kannst in der Skillmatrix auch ergänzende Informationen sichtbar zu machen, z.B. wohin sich einzelne Teammitglieder entwickeln möchten (nutze dafür Symbole oder Emojis). Die Skillmatrix sollte an einem zentralen Ort (z.B. eine Confluence-Seite) abgelegt und fortlaufend gemeinsam aktualisiert werden. Beachte dabei, dass die Offenlegung von Wissenslücken Mut und psychologische Sicherheit erfordert. Frage also am besten, ob sich alle wohl dabei fühlen, die Skillmatrix öffentlich abzulegen. Falls nicht, kannst du ggf. die Zugriffsberechtigungen auf das Team beschränken.

Generelle Maßnahmen zum Abbau von Kopfmonopolen

Der Abbau von Kopfmonopolen gelingt nicht von heute auf morgen. Er braucht eine gute Planung und vor allem den Willen seitens Team, und Product Owner:in, Wissen breiter verteilen zu wollen. Kurzfristig kann das, aufgrund von Einarbeitungsaufwänden, zu Einbußen in der Team-Performance führen, langfristig erhöht das aber die Stabilität und Resilienz des Teams und schafft ein besseres Verständnis für das Big Picture.

Ein guter Einstieg (mit wenig Aufwand in der Vorbereitung) ist es, Aufgaben bewusst rotieren zu lassen. Wenn Entwickler:innen regelmäßig Tickets aus anderen Modulen oder mit anderen Technologieanforderungen übernehmen und dabei die nötige Unterstützung bekommen, entsteht Schritt für Schritt neues Wissen im Team. Auch Pair Programming, Mob Programming oder Shadowing können wirksam sein, weil Wissen direkt im Arbeitsprozess weitergegeben wird.

Für kritische Themen helfen außerdem klare Vertretungsregeln. Wer übernimmt, wenn die Expert:in oder der Experte ausfällt? Diese Frage sollte nicht erst im Ernstfall beantwortet werden müssen. Hinterlegst du Vertretungsregeln in eurem Wiki oder Intranet, kannst du somit Ansprechpartner an externe Stakeholder kommunizieren.

Daneben sind regelmäßiger Wissensaustausch, Weiterbildung und gute Dokumentation zentrale Hebel. Hier ein paar Ideen:

• technische Sprint Reviews

• Schulungen zu Themen mit Wissenslücken (selbst organisiert oder durch erfahrene Trainer:innen)

• verständliche Dokumentation in Confluence mit Diagrammen oder Schaubildern

• Impulsvorträge aus dem Team zu einzelnen Themen (z.B. einer Technolgie)

• Explizite Zeiträume zur eigenen Weiterbildung (z.B. jeden Dienstag Nachmittag oder in der Verlängerung von Regelterminen wie Daily oder Refinement)

Nicht zuletzt kann ein Team-Jahres-Kick-off ein guter Anlass sein, um die Entwicklung des Teams bewusst zu planen: Welche Themen wollen wir dieses Jahr aufbauen? Wer arbeitet woran mit? Wo brauchen wir Unterstützung? Wo möchten sich die Teammitglieder hin entwickeln?

Umgang mit technischen Kopfmonopolen

Technischen Kopfmonopolen kann man (über die bereits genannten Maßnahmen hinaus) auch mit gelebter Collective Code Ownership und einer gut strukturierten Software-Architektur begegnen.

Hinter ersterem versteckt sich eher eine Haltung als eine Maßnahme: Code “gehört” nicht einzelnen Teammitgliedern, sondern dem gesamten Team. Daraus folgt, dass jede Person zu jederzeit Änderungen an der gesamten Codebase des Teams machen darf, ohne sich eine Erlaubnis einholen zu müssen. Wenn nur einzelne Personen bestimmte Bereiche anfassen dürfen, entstehen schnell neue Monopole.

Eine Software-Architektur sollte so strukturiert sein, dass Entwickler:innen sich schnell zurecht finden. Sind z.B. alle Module, die ein Team betreut, ähnlich strukturiert (Layer, Packages, Patterns, Frameworks, Namenskonventionen…), fällt es Teammitgliedern leicht, sich zu orientieren, besonders, wenn sie eine bestimmte Stelle im Code nicht kennen. Generell erleichtert wartbarer Code anderen Teammitgliedern die Arbeit mit Fremdcode – hier kann Kenntnis der Clean-Code-Prinzipien oder der Einsatz von statischen Code-Analyse-Tools die Code-Qualität deutlich verbessern. Langfristig ist auch die konsequente Ablösung überholter Legacy-Technologien nötig, um den Busfaktor gering zu halten.

Wie KI dir dabei helfen kann

Hast du Zugang zu KI-Tools in deinem Unternehmen? Großartig! Large Language Models (LLMs) können dir auch beim Abbau von Kopfmonopolen behilflich sein. Sie können…

• Architekturen und Codebasen erklären und somit schneller verständlich machen (z.B. “Was macht die Klasse SchadenAnlageAdapterImpl”?)

• bestehende Dokumentation zusammenfassen und Fragen zu dieser beantworten

• fehlende Dokumentation aufbauen

• Wissen schneller auffindbar machen

• Einstiegshilfen zu neuen Themen geben und Lernpfade aufzeigen

• deine Teamsituation verstehen und dir konkrete Ansatzpunkte geben

• Commit-Historien analysieren, um Wissenslücken transparent zu machen

• Daten aus Jira analysieren – wie das gelingt, hat unsere Kollegin Ina Humpert in ihrem Blog-Artikel analysiert

Wenn du darüber nachdenkst, fallen dir sicher noch weitere Möglichkeiten ein; hier hast du zumindest schon mal ein paar Ideen!

Was du nicht vergessen solltest

Spezialisierungen sind nicht per se schlecht. In vielen Fällen sind sie sogar notwendig und sinnvoll. Der Scrum-Guide gibt zwar vor, dass Teams Cross-funktional sein müssen – das bedeutet aber nicht, dass alle immer alles können müssen. Gemeint ist vielmehr, dass alle Fähigkeiten, die zur Entwicklung eines Produkts nötig sind, in ausreichendem Umfang im Team vorhanden sind. Wenn ein Team aus vier Frontend- und vier Backend-Entwicklern besteht, ist das völlig in Ordnung.

Manche Kopfmonopole sind außerdem kaum vollständig zu vermeiden – etwa dann, wenn im Team sehr unterschiedliche Expertisen zusammenkommen, zum Beispiel Data Science und Frontend Development. Wichtig ist deshalb nicht, jedes Spezialwissen aufzulösen, sondern, bewusst mit Risiken umzugehen und an kritischen Stellen für mehr Redundanz zu sorgen.

Fazit