Team-Knowledge-Model

Kurzfassung

Feature Teams müssen kontinuierlich lernen und gleichzeitig verlässlich liefern. Velocity taugt nicht, um Teamentwicklung zu messen.

Das Modell führt die individuellen Flow-Modelle aller Teammitglieder zu einem Teambild zusammen, entlang von Lernfeldern.

Sichtbar werden vier Dinge: Wissensverteilung, Balance aus Herausforderung und Fähigkeit, Wissenslücken und der Fortschritt über die Zeit.

Der Prozess umfasst sechs Schritte und einen Teamworkshop. Wiederholung nach drei bis sechs Monaten zeigt, ob die Maßnahmen wirken.

Motivation

An Feature Teams in der skalierten Produktentwicklung werden besondere Anforderungen gestellt. Durch die Ende-zu-Ende-Perspektive und die eigenständige Lieferverantwortung eines Kundenwertes sind Feature Teams nicht nur crossfunktional, sondern agieren auch über den kompletten Technologie-Stack hinweg. Darüber hinaus ist es üblich, dass Feature Teams in allen Komponenten des Systems entwickeln, ändern und diese Komponenten auch noch wartungsfreundlich halten. Damit wird das Arbeiten in fremdem oder unbekanntem Code zum Normalfall. Ein Feature Team muss sich also schnell in neue Technologien und Systemkomponenten einarbeiten können. Aber auch das Verstehen der Kundenwünsche, der fachlichen oder technischen Anforderungen ist ein Lernprozess.

Während sich die Tätigkeiten und das dazugehörende Lernen aus den Einsatzgebieten des Teams ableiten lassen, ist das Team für das individuelle Lernen der Teammitglieder selbst verantwortlich. Lernen alle Teammitglieder alles, oder teilen sie sich einzelne Lernfelder auf?

Das Lernen im Team und das Organisieren des Lernprozesses ist also eine wesentliche Aufgabe für Scrum- oder Feature Teams. Allerdings gibt es auch eine Rahmenbedingung, die den Teams das Lernen nicht gerade vereinfacht. In der agilen Projekt- oder Produktentwicklung ist die Vorhersagefähigkeit ein hohes Gut, denn dadurch wird Vertrauen bei Kunden und Stakeholdern hergestellt. Die wesentlichen Metriken für Vorhersagen sind zum einen die „remaining Product Backlog size“ (Größe des verbleibenden Product Backlogs) und zum anderen die Velocity (Liefergeschwindigkeit) des Teams. Damit mit diesen Werten tatsächlich verlässliche Vorhersagen gemacht werden können, ist es wichtig, dass die Velocity des Teams keinen allzu großen Schwankungen unterliegt. Fatal ist es, wenn die Velocity des Teams in der jüngeren Vergangenheit ungeplant auf null gefallen ist. In diesem Fall kann zum Beispiel der Product Owner künftig keine zuverlässigen Vorhersagen mehr treffen, denn die Velocity des Teams könnte ja jederzeit wieder auf null fallen.

Wird dieser Maßstab gesetzt, dass ein Team immer etwas liefern muss, damit die Organisation vorhersagefähig bleibt, dann ergibt sich für Scrum- und Feature Teams die Herausforderung, dass sie kontinuierliches Lernen und eine stabile Produktivität gleichzeitig gewährleisten müssen.

Das wirft folgende Fragen auf:

• Wie können wir individuelle Ziele und Teamziele in Einklang bringen?
• Wie können wir erkennen, wer Experte ist und wer Hilfe benötigt?
• Wie kontrollieren wir, in welche Richtung sich das Team entwickelt?
• Wie können wir neue Dinge lernen und gleichzeitig produktiv sein?

Für die Messung der Teamentwicklung ist die Velocity des Teams allein denkbar ungeeignet.

„High Performance Team“ ist das Schlagwort der agilen Community und der heilige Gral der Agilität. Wie entwickelt man nun ein Team zu einem High Performance Team, und wie weist man nach, dass ein Team sich dorthin entwickelt hat? Leider wird Performance oft mit der Liefergeschwindigkeit des Teams gleichgesetzt. Viele Manager neigen dazu, die KPI Velocity zu nutzen, um die Teamentwicklung nachzuweisen und um den Nutzen der Scrum-Master-Rolle zu messen oder zu bewerten. Das ist jedoch nicht zielführend. Weder weist eine steigende Velocity auf eine echte Teamentwicklung hin, noch weist sie den Nutzen eines Scrum Masters direkt nach. Zum einen, weil die Velocity eines Teams stets auch kleineren Schwankungen unterliegt (etwa durch Urlaub, Krankheit oder ungeplante Ad-hoc-Tätigkeiten), und zum anderen, weil die Velocity auch durch Mehrarbeit einzelner Teammitglieder steigen kann. Außerdem lässt sie sich einfach durch höhere Schätzungen des Teams manipulieren.

In einem High Performance Team geht es nicht darum, dass jeder schneller oder mehr arbeitet, sondern darum, dass die Teammitglieder Routinen entwickeln, die es ihnen ermöglichen, Synergien zu nutzen, um das Lernen und Liefern im Team effektiver und effizienter zu gestalten. Das Wunder der Kollaboration: Die Summe des Teams ist mehr als die Summe der Individuen. Es geht um echte Skalierung: darum, die Kapazitäten und Kompetenzen der einzelnen Teammitglieder jederzeit optimal für den Teamerfolg einzusetzen, für Know-how-Aufbau und Produktivität gleichermaßen.

Die Fähigkeit einer echten Skalierung erreicht ein Team nur dann, wenn auch die Teammitglieder selbst in der Lage sind zu skalieren, also mehrere unterschiedliche Aufgaben im Team übernehmen können.

Nimmt man die Fähigkeit des Teams zu skalieren als Grundlage für die Teamentwicklung, dann lassen sich vier Eigenschaften identifizieren, die damit in unmittelbarem Zusammenhang stehen:

• Skalierungspotential: die Wissensverteilung. Wer weiß was im Team, und welche individuellen Lernpotentiale gibt es?
• Skalierungsstatus: die Balance zwischen Herausforderungen und Fähigkeiten.
• Skalierungshemmnis: Wissenslücken des Teams, Einschränkungen im Aufgabengebiet und beim Know-how-Aufbau.
• Skalierungsfortschritt: wird das Team-Knowledge-Model wiederholt angewendet, visualisiert es den Fortschritt des Wissensaufbaus und damit die Teamentwicklung.

Skalierbarkeit eines Teams ist ein Faktor, der vor allem auf die Leistungsfähigkeit des Teams abzielt. Es ist aber kaum vorstellbar, dass Menschen nachhaltig hohe Leistungen erbringen, wenn sie sich dabei nicht wohlfühlen. Deshalb ist es genauso wichtig, auf die Zufriedenheit und das Glücksempfinden der Teammitglieder zu achten. Wie also Hochleistung und Glücksgefühl in Einklang bringen?

Ganz einfach: arbeitet im Flow.

Was bedeutet: arbeiten im Flow?

Teamentwicklung war für mich schon immer Teamaufgabe und sollte auch von den Teammitgliedern gemeinschaftlich erlebbar sein. Glücklicherweise besuchte ich Anfang 2009 einen Vortrag zum Thema emotionale Teamzustände von Joseph Pelrine. In diesem hat er unter anderem das Flow-Modell von Mihály Csíkszentmihályi vorgestellt. Der ursprünglich aus dem Sport kommende Begriff des Flows beschreibt nach Csíkszentmihályi einen Zustand, in dem Menschen in der Balance der eigenen Fähigkeiten und der an sie gestellten Herausforderung arbeiten. Im Flow sind wir gefordert, aber nicht überfordert, und das macht Menschen glücklich.

Flow Model nach Mihály Csíkszentmihályi Flow Model (Mihály Csíkszentmihályi)

Im oberen Bild stellt der Zustand der Apathie für den Einzelnen den Mangel an Wissen und fehlende Aufgaben dar. Übersteigen die Herausforderungen die Fähigkeiten, befindet sich die Person in der Überforderung; langfristig könnte dieser Zustand zum Burnout führen. Kann eine Person hingegen ihre Fähigkeiten gar nicht einsetzen, ist sie unterfordert und langweilt sich möglicherweise. Langfristig könnte das dann zum Boreout führen.

Wir alle wollen etwas leisten, wollen gut in etwas sein, wir streben also nach wahrer Meisterschaft, etwas, worauf wir auch stolz sein können. Eine anspruchsvolle Herausforderung anzunehmen und zu meistern führt sicher für die Allermeisten von uns zu Glücksgefühlen. Im Modell würde das bedeuten, dass wir uns sehr hohen Herausforderungen stellen, diese aber ohne Blockaden und Unterbrechungen erledigen können.

Im Flow hat man die Balance zwischen anspruchsvollen Herausforderungen und eigenen Fähigkeiten erreicht.

Lernen am Rande des Flows

Menschen lernen auf unterschiedlichste Weise. Lernen bedeutet auch immer, dass wir unsere Komfortzone verlassen und uns damit aus dem Flow nehmen. Am Rande des Flows gibt es zwei Wege des Lernens, die uns hoffentlich nur kurzzeitig aus dem Flow bringen: „Learning by doing“ und der initiale Wissensaufbau, zum Beispiel durch eine vorgelagerte Ausbildung, ohne dieses Wissen unmittelbar zur praktischen Anwendung zu bringen.

Beim Learning by doing werden zuerst die Herausforderungen erhöht. Eigentlich übersteigen die aktuellen Aufgaben dann die eigenen Fähigkeiten, aber man kniet sich hinein, versteht mit der Zeit, wie es läuft, und baut Wissen auf. So kommt man letztendlich wieder in den Flow. Viele Menschen bevorzugen diese Art des Lernens, und daran ist auch nichts falsch.

Andere wiederum bevorzugen es, sich für neue Herausforderungen erst das nötige Wissen anzueignen, durch eine entsprechende Ausbildung, eine Lehre oder auch einfach durch ein Training. Dies ist ebenfalls eine sehr gute und vernünftige Art des Aufbaus eigener Fähigkeiten. Stellen wir uns vor, ein Arzt würde seinen Ausbildungsweg über Learning by doing ohne langes Studium bestreiten. Auch dieser Weg des Lernens ist also durchaus hilfreich.

Es gibt also kein Richtig oder Falsch in dieser Frage, sondern beide Wege sind sinnvoll und haben ihre Berechtigung.

Lernen am Rande des Flows

Problematisch wird es allerdings, wenn man nicht mehr zurück in den Flow kommt, also in den rot schraffierten Flächen verharrt, denn dann wäre uns der Weg zurück ins Glück versagt. In solchen Fällen können wir zwei negative Effekte beobachten, die wir vielleicht schon selbst erlebt oder bei anderen gesehen haben.

Kommt man aus dem Learning by doing nicht mehr zurück in den Flow, ist das vergleichbar mit dem Peter-Prinzip. Dieses besagt, dass jeder so lange befördert wird, bis er den Grad seiner Unfähigkeit erreicht hat. Man verfügt nicht über die notwendigen Kompetenzen für die aktuellen Aufgaben und ist dauergestresst.

Wenn man aus der Unterforderung nicht mehr zurückkommt, also seine Fähigkeiten gar nicht zum Einsatz bringen kann, fühlt sich das, vor allem wenn dieser Zustand nicht selbst gewählt wurde, wie Mobbing an.

Beide Extreme stehen langfristig im Widerspruch zu einer gesunden Arbeitsweise. Es kommt also darauf an, wie schnell man wieder in den Flow kommt. Für mich ist ein Team eine Lerngemeinschaft, und damit ist es auch Teamaufgabe, darauf zu achten, dass jedes Teammitglied die notwendige Unterstützung für individuelles Lernen und die Anwendbarkeit der eigenen Fähigkeiten erhält. Mit dem oben aufgeführten Modell kann man sehr schön visualisieren, wo eine Person gerade steht, und gegebenenfalls Maßnahmen ergreifen, um sie in den Flow zurückzubringen.

Mein Thema ist aber die Teamentwicklung, und deshalb habe ich diesen individuellen Ansatz auf das ganze Team ausgedehnt, ohne den Bezug auf einzelne Teammitglieder zu verlieren. So entstand das Team-Knowledge-Model.

Die Verantwortung des Einzelnen ist es, mitzuhelfen, dass jedes Teammitglied in den Flow kommen kann.

Das Team-Knowledge-Model (TKM)

basierend auf dem Flow-Modell von Mihály Csíkszentmihályi

Im Team-Knowledge-Model werden alle individuellen Flow-Modelle der Teammitglieder zusammengeführt und damit das Wissen und der Grad der erlebten Herausforderungen auf Teamebene visualisiert.

Um den Teammitgliedern eine bessere Orientierung für die Bestimmung ihres eigenen aktuellen Zustandes zu geben, habe ich die Y-Achse der Herausforderungen und die X-Achse der eigenen Fähigkeiten in jeweils drei Abschnitte unterteilt.

Einteilung Herausforderungen (Y-Achse)

• low: keine oder einfache Aufgaben
• medium: mittelschwere Aufgaben
• high: komplexe Aufgaben

Aus dem Kampfsport Aikido kommt die Einteilung der Lernenden in drei Status: Shu-Ha-Ri. Wobei Shu dem Anfänger, Ha dem Fortgeschrittenen und Ri dem Meister entspricht. Alistair Cockburn hat diese Begriffe in die agile Welt als Lernebenen transferiert. Diese Einteilung verwende ich mittlerweile im Team-Knowledge-Model.

Einteilung Fähigkeiten (X-Achse)

• Shu: Ich weiß nichts darüber oder nur grundlegende Dinge und kann nach Vorgaben Aufgaben erledigen.
• Ha: Ich komme ganz gut zurecht, benötige aber ab und an Hilfe für komplizierte Aufgaben.
• Ri: Ich kenne mich exzellent aus, komplexe Aufgaben kann ich allein bewältigen und andere in diesem Thema sogar unterrichten.

Werden alle Ergebnisse in das gemeinsame Modell übertragen, erhält man das Team-Knowledge-Model.

Initial ausgefülltes Team-Knowledge-Model Beispiel: initial ausgefülltes Team-Knowledge-Model, basierend auf dem Flow-Modell von Mihály Csíkszentmihályi

Das Team-Knowledge-Model visualisiert:

• die Wissensverteilung im Team (Skalierungspotential)
• die Balance zwischen Herausforderungen und Fähigkeiten (Skalierungsstatus)
• mögliche Wissenslücken im Team (Skalierungshemmnis)
• die Wissensentwicklung über die Zeit (Skalierungsfortschritt)

Sechs Schritte und ein Workshop

Der Ablauf ist recht einfach und beinhaltet folgende Tätigkeiten:

1. Auswahl der Lernfelder für das Team
2. Individuelles Ausfüllen der Modelle
3. Mit dem gesamten Team alle individuellen Ergebnisse ins Teammodell übernehmen
4. Analyse des Ergebnisses
5. Bestimmen der Maßnahmen zum Wissensaufbau und entsprechende Aufgabenverteilung
6. Folgemodelle durchführen

Die Tätigkeiten 3 bis 5 werden zusammen in einem dedizierten Team-Workshop durchgeführt. In den folgenden Abschnitten werden die Aktivitäten detailliert vorgestellt.

1. Auswahl der Lernfelder

Damit das Team seinen Know-how-Aufbau planen und steuern kann, ist es sinnvoll, zuerst die gemeinsamen Lernfelder festzulegen. Diese lassen sich zum einen aus den konkreten Aufgabenstellungen des Teams ableiten, zum anderen orientiert sich die Auswahl an den Interessen der Teammitglieder.

Die Lernfelder sollten im fachlichen (im Beispiel Domänen-Know-how) und/oder technischen Kontext des Teams liegen. Sollten sich viele Lernfelder aus dem Arbeitskontext ableiten oder gar von außen vorgegeben werden, ist es wichtig, dass zumindest ein Lernfeld vom Team frei gewählt werden kann. Das steigert die Motivation und die Identifikation mit dem Lernprozess an sich.

Lernfelder sind keine Lernziele. Es ist auch nicht sinnvoll, die Lernfelder bei der Auswahl mit Zielen zu versehen, denn das würde den Startpunkt der Einzelnen im Team und des gesamten Teams außer Acht lassen.

Beispiele für Lernfelder

Fachlich

• Arbeitsprozesse, Ver- oder Einkaufsprozesse
• Versicherungsprozesse, Algorithmen, Policen
• Telekommunikation: Standards, Protokolle
• Steuern, Buchhaltung, Rechnungswesen
• unterschiedlichste Rechtsbereiche
• Finanzprozesse

Was auch immer im wirtschaftlichen Interesse des Unternehmens liegt.

Technisch

• Programmierkenntnisse: Java, Angular, C++
• Designprinzipien: OOD, S.O.L.I.D., GRASP
• Technologien: Azure, AWS, KI, Big Data
• Continuous Integration (CI/CD)
• Entwicklungspraktiken: ATDD, TDD, BDD
• Refinement- und Testpraktiken

Was immer das Team zur Erledigung seiner Aufgaben benötigt.

Die gezeigten Beispiele sind vor allem aus der Softwareproduktentwicklung entnommen. Das TKM lässt sich aber auf alle Teamkontexte anwenden. Ein Fußballteam identifiziert Schwächen in der Taktik, im Abwehrverhalten oder bei den Fitnesswerten. Projektleiter und Account Manager wollen mehr über Marketing oder Kundenakquise lernen. Ein Team von Managern vielleicht orthogonale Selbstführung, klassische Managementmethoden oder Leadership-Praktiken.

2. Individuelles Modell: eigene Kompetenzen einschätzen

Individuelle Flow-Modelle

Am Anfang steht die Selbsteinschätzung. Über welches Know-how verfüge ich? Wie groß sind meine Herausforderungen?

Zuerst füllt jedes Teammitglied allein sein persönliches Knowledge-Model aus. Es ist wichtig, dass die Teammitglieder das wirklich allein und ohne Referenz zu ihren Teamkollegen ausfüllen. So können später beim Übertragen der individuellen Daten ins Teammodell auch mögliche Fehleinschätzungen (Eigenbild gegen Fremdbild) aufgezeigt und diskutiert werden.

Ob man sich zuerst im Know-how, also auf der horizontalen Ebene Shu-Ha-Ri, einteilt und dann die Größe der Herausforderungen bewertet oder umgekehrt, ist jedem selbst überlassen. Es geht hier nicht darum, sich zu profilieren, sondern eine ehrliche Selbsteinschätzung zu geben.

Es ist hilfreich festzustellen: Bin ich in dieser Wissensdomäne aktuell oberhalb des Flows, also in der Überforderung? Oder läuft es super und ich bin im Flow? Oder werden meine Kenntnisse gar nicht genutzt und ich befinde mich unterhalb des Flows? Diese Einschätzung wird auf der Y-Achse (high, medium, low) eingetragen.

Auf der X-Achse hingegen schätzt man seine Kompetenzen in dem jeweiligen Bereich ein. Bin ich eher Anfänger, verfüge über Grundkenntnisse und benötige viel Zeit oder Hilfe, um Probleme zu lösen? Hier wäre dann der Bereich Shu zu wählen. Oder komme ich ganz gut zurecht, benötige Hilfe nur selten, stoße aber hin und wieder auf Wissenslücken? Dann wäre Ha angemessen. Sehe ich mich als Experten in diesem Bereich und kenne mich so gut aus, dass ich selbst keine Hilfe benötige, aber andere in diesem Thema sogar unterrichten kann, ist Ri die richtige Einstufung.

3. Das Team-Startmodell: Wissensverteilung erkennen

Initiales Team-Knowledge-Model

Im ausgefüllten Team-Knowledge-Model lässt sich ablesen, welches Know-how dem Team zur Verfügung steht und ob Teammitglieder gerade mit ihren Aufgaben zu kämpfen haben.

Im dedizierten Team-Workshop zum TKM werden als Erstes die individuellen Modelle zum gemeinsamen TKM zusammengeführt. Der Reihe nach werden pro Lernfeld die Kreuze von jedem Teammitglied ins Teammodell übertragen.

Hierbei ist es sinnvoll, dass eine neutrale Person, zum Beispiel der Scrum Master, sich die Ergebnisse von jedem Teammitglied zeigen lässt und sie dann im Beisein aller in das Team-TKM überträgt. Dies ist ein wichtiger Aspekt, denn durch dieses Verfahren können mögliche Fehleinschätzungen transparent werden. Sind alle individuellen Kreuze zu einem Lernfeld übertragen, wird ein Kreis um alle Kreuze zu diesem Lernfeld gezogen. Danach wird der Vorgang mit dem nächsten Lernfeld wiederholt, bis alle Lernfelder ins Teammodell übertragen sind. Dann beginnt die Interpretation und Analyse des Ergebnisses.

4. Analyse des Modells: Wissensaufbau motivieren

Analyse des Team-Knowledge-Models

Wir beginnen mit einer optischen Analyse: Haben wir große oder eher kleine Kreise, ist deren Zentrum eher links unten oder eher rechts oben?

Im Beispielmodell zeigen die Kreise in den Lernfeldern Coding und Domänen-Know-how große Diversität (große Kreise). Es gibt Teammitglieder, die Experten in diesen Domänen sind, aber auch Anfänger. Ein Teammitglied fühlt sich etwas überfordert mit dem Domänenwissen, und ein anderes kann sein Coding-Know-how gar nicht richtig anwenden.

In diesen zwei Lernfeldern kann das Team durch geschickte Maßnahmen eigenständig die Lernfortschritte planen und angehen. Alles Notwendige scheint im Team dafür vorhanden zu sein.

Anders sieht es im Lernfeld Testen aus. Hier ist zum einen der Kreis klein und damit das Know-how im Team zum Thema recht ähnlich (homogen), aber vor allem befindet sich das Zentrum des blauen Kreises unten links. Das bedeutet, dass das Team im Lernfeld Testen nicht über genügend Expertise verfügt. Hier besteht also Handlungsbedarf, externes Know-how ins Team zu bringen.

Aufgabe im Workshop ist es, das TKM im Team zu interpretieren und über das Dargestellte zu diskutieren. Wenn sich Teammitglieder außerhalb des Flows befinden, ist das erst einmal okay. Es kann ja das bevorzugte Lernmodell sein. Wichtig ist, dass das Team darüber spricht, wie das entsprechende Teammitglied möglichst schnell wieder in den Flow hineinkommt.

Hat das Team ein gemeinsames Verständnis über den aktuellen Zustand des Teams und der einzelnen Teammitglieder erreicht, geht es an die Erarbeitung der nächsten Schritte.

5. Maßnahmen: Wissensaufbau planen

Hat das Team verstanden, wer welche Kompetenzen einbringt und wer möglicherweise in der Überforderung ist, sind die zu ergreifenden Maßnahmen gar nicht mehr so schwer zu identifizieren. Vielen Teams fällt dieser Teil des Workshops am leichtesten.

Teamaufgabe ist es, die Teammitglieder schnellstmöglich wieder in den Flow zu bringen. Ist ein Teammitglied in der Überforderung, dann sollte das Team durch Unterstützung beim Wissensaufbau helfen, zum Beispiel indem ein Experte im Team die Coach-Rolle übernimmt und zusammen mit diesem Teammitglied an dessen Aufgaben mitarbeitet. So baut der Coachee schneller Wissen auf und kommt leichter wieder in den Flow zurück.

Ist ein Teammitglied hingegen unterfordert, ist der einfachste Weg, es in die aktive Arbeit, also in die Umsetzung von Backlog Items in diesem Bereich einzubinden. Ebenso ist es möglich, dieses Teammitglied als Coach für Kollegen einzusetzen, die sich in diesem Lernfeld weiterentwickeln möchten.

Wenn jedoch Expertenwissen im Team fehlt, sollte das Team versuchen, Hilfe zu organisieren: durch Workshops mit externen Experten oder durch Besuche einzelner Teammitglieder in entsprechenden Schulungen mit anschließender Wissensvermittlung im Team. Im skalierten Umfeld hilft auch die intensive Zusammenarbeit mit einem Team, das dort Expertise hat, etwa bei Refinements, Businessanalyse und Designarbeit. So baut das Team Wissen im angestrebten Lernfeld schnell auf.

Einige hilfreiche Methoden und Praktiken, um Wissen aufzubauen und die Fähigkeiten des Teams auszubauen:

• Pair- und Mob-Programming
• Coding-Dojos
• Aufsetzen von Communities of Practice für teamübergreifendes Lernen
• Pair-Learning, Pair-Reading
• dedizierte Zeiteinheiten für individuelles Lernen reservieren
• Aufsetzen von Foren, zum Beispiel ein Agile-Design-Forum zur Einführung der S.O.L.I.D.-Designprinzipien und GRASP-Prinzipien
• Einführung von ATDD und TDD, was das Domänen-, Test- und Codeverständnis verbessert

Die hier aufgeführten Ideen beziehen sich in erster Linie auf Teams in der Softwareentwicklung. Sehr viele dieser Methoden und Praktiken lassen sich jedoch in andere Bereiche übertragen und entsprechend anpassen.

6. Folgemodelle: Lernfortschritte aufzeigen

Fortschritt im Team-Knowledge-Model

Regelmäßige Workshops zum Erstellen von Folge-TKMs helfen dem Team zu erkennen, ob die Maßnahmen wirklich wirken, und ermöglichen es, Anpassungen vorzunehmen.

Nach drei, sechs oder neun Monaten empfiehlt es sich, den TKM-Prozess zu wiederholen. Natürlich kann man den ersten Schritt, die Auswahl der Lernfelder, zunächst auslassen. Man wiederholt die Schritte zwei, drei und vier.

Anschließend vergleicht man das aktuelle TKM mit dem vorherigen. Gab es Fortschritte, sind einzelne Teammitglieder zurückgeblieben? Wenn ja, warum? Ist das okay, oder liegt hier etwas im Argen? Echte Fortschritte im Team sollten gefeiert werden. Der Vergleich der Modelle mit einem nachgewiesenen Fortschritt wirkt sich nach meinen Beobachtungen sehr positiv auf die Teamstimmung und die Motivation aus, neue Dinge anzugehen.

In den Folge-Workshops wird auf das zuletzt erstellte TKM fokussiert. In der Diskussion stellt das Team vielleicht fest, dass es in einem Lernfeld schon ausreichend Know-how aufgebaut hat und hier keine weiteren Aktivitäten erforderlich sind. In diesem Fall kann das Team ein neues Lernfeld hinzunehmen. Für dieses wird dann ein neues TKM mit den Ergebnissen der weiter genutzten Lernfelder erstellt. Dieses Modell dient beim nächsten Update des TKMs als Vergleichsmodell.

Natürlich wird sich das Team nach der Analyse des neuen TKMs auf Maßnahmen einigen und den Wissensaufbau für die nächste Lernperiode planen.

Lernvision statt Ziele

Vision im Team-Knowledge-Model

Muss jeder im Team alles können? Nein.

Es kann nicht das Ziel sein, dass jeder ein Experte in jedem Lernfeld werden muss. Das würde die Individualität und Eigenständigkeit eines Teammitglieds missachten, und Lernen würde als Zwang empfunden. Das Bild ist lediglich eine Vision: Jeder kann sich in diese Richtung entwickeln und würde dabei unterstützt. Sollte es tatsächlich der Fall sein, dass alle Teammitglieder Experten in einem oder mehreren Lernfeldern sind, dann kann sich das Team im nächsten TKM neue Lernfelder erschließen.

Ein Team im Abstand von acht Monaten

TKM eines Teams im Abstand von acht Monaten TKM eines Teams, im Abstand von acht Monaten durchgeführt

Das hier gezeigte TKM eines realen Teams zeigt auf der linken Seite das initiale Modell, das zwei Monate nach der Teamformierung erstellt und nach acht Monaten (rechte Seite) aktualisiert wurde.

Zu Beginn der Teamzusammenarbeit hatten viele Teammitglieder nur Anfängerkenntnisse oder gar keine Kenntnisse in den verschiedenen Lernfeldern. Auffällig durch die großen Kreise ist aber auch, dass es in jedem Lernfeld Teammitglieder gab, die über Expertenwissen verfügten und in der Lage waren, ihre Kollegen entsprechend zu unterstützen oder auszubilden.

Im rechten TKM kann man sehr gut erkennen, dass es in allen Lernfeldern Fortschritte gegeben hat. Viele haben ihre Kenntnisse deutlich erweitert und arbeiten nun an entsprechenden Aufgaben. Einige merken, dass sie sogar Aufgaben übernehmen, die eigentlich über ihren Fähigkeiten liegen. Offensichtlich findet hier Learning by doing statt. Eine Ausnahme gibt es allerdings: Das Thema „CM Meta/Access“ hat sich nicht verbessert, und sogar die Expertise eines Kollegen scheint schlechter geworden zu sein. Dies war für das Team in der Analyse erklärbar, denn das Team hat in diesem Bereich des Produktes seit dem ersten TKM keine Aufgaben mehr übernommen. Da gab es also für die Teammitglieder nichts zu arbeiten und damit auch nichts zu lernen. Der Experte erklärte, dass andere Teams diese fachliche Komponente weiterentwickelt hätten und er sich nun nicht mehr so gut dort auskenne.

Im ersten Team-Knowledge-Model-Workshop hatte das Team die folgenden Maßnahmen zum Know-how-Aufbau beschlossen:

• Pair-Programming
• Fragen stellen. Gemeint war, es solle davor keine Scheu geben.
• eigene Coding-Projekte aufsetzen und dafür Zeit reservieren
• Weiterbildungstag: jedes Teammitglied konnte einen Tag im Sprint zum Lernen verwenden
• Ergebnisse des individuellen Lernens mussten mit dem Team geteilt und dokumentiert werden
• eine Wunschliste der zu lernenden Themen wurde erstellt
• wöchentlich wurden für eine halbe Stunde Aufgaben und erarbeitete Lösungen im Team vorgestellt
• ein „Best Practice“-Ordner wurde erstellt
• zwei Teamkollegen beschlossen, zusammen die SCJP-Zertifizierung abzulegen; dazu haben sie kapitelweise Bücher gelesen und sich gegenseitig Dinge erklärt oder abgefragt

Beschlossene Maßnahmen

Nichts motiviert so sehr wie Erfolg. Das Team-Knowledge-Model kann den Lernerfolg eines Teams aufzeigen.

Coaching Tipps und Tücken

Achtung: Treibsand Achtung: Treibsand!

Natürlich gibt es auch beim Team-Knowledge-Model, wie bei allen Methoden, ein paar Dinge außerhalb der Methodik, die zu beachten sind. Darüber hinaus möchte ich hier auch auf ein paar Tücken in der Anwendung des Modells hinweisen.

Bevor mit dem Team-Knowledge-Model gearbeitet wird, ist es sinnvoll zu prüfen, ob das Team auch längerfristig zusammenbleibt. Gemeinsames Lernen braucht Vertrauen und Routinen, und diese aufzubauen braucht Zeit.

Hilfreich ist auch, wenn im Team ein gemeinsames Verständnis darüber herrscht, dass es die Aufgabe eines jeden Teammitglieds ist mitzuhelfen, dass sich die Kollegen weiterentwickeln. Dies kann durch das Management unterstützt werden, beispielsweise durch Aufnahme eines Bewertungskriteriums, das festhält, was ein Mitarbeiter zur Entwicklung der Kollegen beigetragen hat.

Das Team-Knowledge-Model lässt sich hervorragend in Team-Building-Workshops anwenden, etwa nach einer Teamneuformierung oder einem Self-Designing-Team-Workshop (siehe LeSS Case Study). In Team-Retrospektiven lässt sich das TKM ebenfalls sehr gut nutzen.

Ein Selbsteinschätzungsprozess ist keine exakte Wissenschaft, aber das Team-Knowledge-Model visualisiert eben das vorhandene oder fehlende Know-how im Team, gibt Rückschlüsse auf die Belastungen der Teammitglieder und ist damit ein guter Indikator für das Selbstvertrauen und die Stimmung im Team.

Um im Lernprozess nicht den Fokus zu verlieren, sollten nicht mehr als sechs Lernfelder gleichzeitig betrachtet und bearbeitet werden.

Das TKM im Teamraum aufzuhängen erinnert jeden im Team daran, dass Maßnahmen vereinbart wurden und diese nun auch angegangen werden müssen.

Regelmäßige Aktualisierungen des TKMs zeigen Lern- und Entwicklungsfortschritte im Team auf. Nichts ist so motivierend wie Erfolg. Die Visualisierung dessen motiviert für neue Aufgaben, stärkt im Team das Selbstbewusstsein sowie die Verantwortungsübernahme und erhöht die Bereitschaft, die Komfortzone zu verlassen. Ich empfehle Wiederholungen im Abstand von drei, vier oder sechs Monaten, je nach Bedarf und Komplexität der Lernfelder.

Schreibt keine Namen der Teammitglieder an die Kreuze im Modell. Das TKM ist teamintern. Das Ergebnis kann jedoch öffentlich gemacht werden und erhöht die Transparenz. Aber einzelne Teammitglieder sollen nicht erkennbar sein. Das verhindert auch, dass Manager das Modell für Team-Rankings missbrauchen.