Team-Knowledge-Model
Wissensverteilung erkennen, Wissensaufbau motivieren, Teamentwicklung visualisieren
Indiv. Model Template
Download .pdf
Team Model Template
Download .pdf
Autor
Motivation
An Feature Teams in der skalierten Produkt-Entwicklung werden besondere Anforderungen gestellt. Durch die Ende-zu-Ende Perspektive und eigenständige Lieferverantwortung eines Kundenwertes sind Feature Teams nicht nur cross-functional, 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 fremden oder unbekannten Code zum Normalfall. D.h. ein Feature Team muss sich schnell in neue Technologien und Systemkomponenten (Code) 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 der Kunden und Stakeholder hergestellt. Die wesentlichen Metriken für Vorhersagen sind zum einen die „remaining Product Backlog size“ (Größe des verbleibenden Produkt Backlogs) und die „Velocity“ (Liefergeschwindigkeit) des Teams. Damit mit diesen Werten (Burndown Chart) 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 kürzeren Vergangenheit ungeplant auf Null gefallen ist. In diesem Fall kann z.B. der Product Owner zukünftig keine zuverlässigen Vorhersagen mehr tätigen, denn die Velocity des Teams könnte dann ja jederzeit wieder auf Null fallen und damit nichts mehr liefern.
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 das kontinuierliche Lernen und eine stabile Produktivität gleichzeitig gewährleisten müssen.
Das wirft folgende Fragen für Scrum- und Feature Teams 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 Vecolity des Teams alleine 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 zu einem „High Performance Team“ entwickelt hat? Leider wird oft Performance mit der Team Liefergeschwindigkeit gleich gesetzt. 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 (z.B. Urlaub, Krankheit oder andere ungeplante adhoc Tätigkeiten) und zum anderen, weil die Velocity auch durch Mehrarbeit einzelner Teammitglieder steigen kann. Außerdem kann die Velocity einfach durch höhere Schätzungen des Teams manipuliert werden.
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 auch 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 (Know-how Aufbau und Produktivität gleichermaßen) einzusetzen.
Die Fähigkeit einer echten Skalierung erreicht ein Team nur dann, wenn auch die Teammitglieder selbst in der Lage sind zu skalieren, also mehrer 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 individuelle Lernpotentiale. - Skalierungsstatus
Die Balance zwischen Herausforderungen und Fähigkeiten. - Skalierungshemmnis
Wissenslücken des Teams, Einschränkungen im Aufgabengebiet und für Know-how Aufbau im Team. - Skalierungsfortschritt
Wird das Team-Knowledge-Model wiederholt angewendet, visualisiert es den Fortschritt des Wissensaufbau und damit die Teamentwicklung.
Skalierbarkeit eines Teams ist ein Faktor, der vor allem auf die Leistungsfähigkeit des Team abzielt. Es ist aber kaum vorstellbar, dass Menschen nachhaltig hohe Leistungen erbringen, wenn sie sich dabei nicht wohl fühlen. Deshalb ist es genauso wichtig auf die Zufriedenheit, auf 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 einem Vortrag zum Thema emotionale Teamzustände von Joseph Pelrine. In diesem hat er unter anderem das Flow Model von Mihály Csikszentmihalyi vorgestellt. Der ursprünglich aus dem Sport kommende Begriff des Flows, ist nach Csikszentmihalyi ein Zustand, in dem Menschen in der Balance der eigenen Fähigkeiten und den an sie gestellten Herausforderung arbeiten. Im Flow sind wir gefordert aber nicht überfordert und dies macht Menschen glücklich.
Im oberen Bild stellt der Zustand der Apathie für den Einzelnen der 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 garnicht einsetzen, ist diese Person 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 annehmen und zu meistern führt sicher für die Allermeisten von uns zu Glücksgefühlen. Im oben gezeigten Model würde das bedeuten, dass wir uns sehr hohen Herausforderungen stellen aber wir diese 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 z.B. durch eine vorgelagerte Ausbildung ohne jedoch dieses Wissen unmittelbar zur praktischen Anwendung zu bringen.
Beim „Learning by doing“ werden zuerst die Herausforderungen erhöht. Eigentlich übersteigen dann die aktuellen Aufgaben die eigenen Fähigkeiten, aber man kniet sich rein und mit der Zeit versteht man 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 erstmal das nötige Wissen anzueignen. Durch eine entsprechende Ausbildungen z.B. Lehre oder auch einfach nur durch ein Training. Dies ist ebenfalls eine sehr gute und vernünftige Art des Aufbaus eigener Fähigkeiten. Stellen wir uns mal 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.
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 mal 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 „Peterchen-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ück kommt, 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 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 ggf. Maßnahmen ergreifen, um diese Person in den Flow zurück zubringen.
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 jedem Teammitglied ermöglicht wird in den Flow zu kommen.
Das Team-Knowledge-Model (TKM)
basierend auf dem Flow Model von Mihaly Csikszentmihalyi
Im Team-Knowledge-Modell werden alle individuellen Flow-Modelle der Teammitglieder zusammengeführt und damit das Wissen und 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):
Im Team-Knowledge-Modell werden alle individuellen Flow-Modelle der Teammitglieder zusammengeführt und damit das Wissen und 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):
Im Team-Knowledge-Modell werden alle individuellen Flow-Modelle der Teammitglieder zusammengeführt und damit das Wissen und 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 einfach Aufgaben
- medium: Mittelschwere Aufgaben
- high: Komplexe Aufgaben
Aus dem Kampfsport Aikido kommt die Einteilung der Lernenden in drei Status : Shu-Ha-Rhi. Wobei „Shu“ dem Anfänger, „Ha“ dem Fortgeschrittenem und „Rhi“ dem Meister entsprechen. Dr. Alister 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, kann nach Vorgaben Aufgaben erledigen
- Ha: Ich komme ganz gut zurecht, benötige aber ab und an Hilfe für komplizierte Aufgaben
- Rhi: Ich kenne mich exzellent aus, komplexe Aufgaben kann ich alleine bewältigen und kann Anderen sogar in diesem Thema unterrichten
basierend auf dem Flow Model von Mihaly Csikszentmihalyi
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)
- Wissensentwicklung über die Zeit (Skalierungsfortschritt)
TKM Prozess
Der Ablauf ist recht einfach und beinhaltet folgende Tätigkeiten:
- Auswahl der Lernfelder für das Team
- Individuelles Ausfüllen der Modelle
- Mit dem gesamten Team alle individuellen Ergebnisse ins Team Modell übernehmen
- Analyse des Ergebnisses
- Bestimmen der Maßnahmen zum Wissensaufbau und entsprechende Aufgabenverteilung
- Folgemodelle durchführen
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 und zum anderen orientiert sich die Auswahl an den Interessen der Teammitglieder.
Die Lernfelder sollten im fachlichen (im Beispiel Domain Know-how) und/oder technischen Kontext des Teams liegen. Sollten sich viele Lernfelder aus dem Arbeitskontext ableiten, oder gar von Außen dem Team vorgegeben werden, ist es wichtig, dass zumindest ein Lernfeld vom Team frei gewählt werden kann. Das steigert die Motivation und 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++…
- Design Prinzipien, OOD, S.O.L.I.D, GRASP…
- Technologien, Azure, AWS, KI, Big Data…
- Continuous Integration (CI/CD)
- Entwickungspraktiken, ATTD, TDD, BDD…
- Refinement & Test-Praktiken
Die gezeigten Beispiele sind hier vor allem aus der Software Produktentwicklung entnommen. Das TKM lässt sich aber auf alle Team Kontexte anwenden. Ein Fußball Team identifiziert Schwächen in der Taktik, im Abwehrverhalten oder bei den Fitnesswerten. Projektleiter und Account Manager wollen mehr über Marketing oder Kunden Akquise lernen. Ein Team von Managern vielleicht orthogonale Selbstführung, klassische Management Methoden oder Leadership Praktiken erlernen.
2. Individuelles Modell: eigene Kompetenzen einschätzen
Am Anfang steht die Selbsteinschätzung. Über welches Know-how verfüge ich? Wie groß sind meine Herausforderungen?
Zuerst füllt jedes Teammitglied alleine sein persönliches Knowledge-Model aus. Es ist wichtig, dass die Teammitglieder das wirklich alleine 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 vs. Fremdbild) aufgezeigt und diskutiert werden.
Ob man sich selbst zuerst im Know-how, also auf der horizontalen Ebene Shu-Ha-Rhi, 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 bin im Flow, oder werden meine Kenntnisse garnicht genutzt und befinde mich in diesem Bereich 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, Hilfe benötige ich nur selten, dennoch stoße ich hin und wieder auf einige Wissenslücken, dann wäre „Ha“ angemessen. Sehe ich mich jedoch 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 „Rhi“ die richtige Einstufung.
3. Das Team Startmodell: Wissensverteilung erkennen
Im ausgefüllten Team-Knowledge-Model (TKM) 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 is es sinnvoll, dass eine „neutrale“ Person, z.B. der Scrum Master, sich die Ergebnisse von jedem Teammitglied zeigen lässt und 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
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 Beispiel Modell links zeigen die Kreise in den Lernfeldern Coding und Im 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 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 hier im Team das TKM zu interpretieren und über das Dargestellte zu diskutieren. Wenn sich Teammitglieder außerhalb des Flows befinden ist das erstmal 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, also die vom Team zu ergreifenden Maßnahmen, um die Teammitglieder ggf. schnell in den Flow zurück zu bringen.
5. Maßnahmen: Wissensaufbau planen
Hat das Team verstanden, wer im Team 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 oft am leichtesten.
Teamaufgabe ist es, die Teammitglieder schnellst möglich wieder in den Flow zu bringen. Ist ein Teammitglied in der „Überforderung“, dann sollte das Team durch Unterstützung beim Wissensaufbau helfen, z.B. indem ein Experte im Team (übernimmt die Coach Rolle) zusammen mit diesem Teammitglied (Coachee) an dessen Aufgaben mitarbeitet. So baut der Coachee schneller Wissen auf und kommt damit leichter wieder in den Flow zurück.
Ist hingegen ein Teammitglied „unterfordert“ ist der einfachste Weg dieses Teammitglied in die aktive Arbeit (Umsetzung von Backlog Items) in diesem Bereich einzubinden, um das Teammitglied wieder in den Flow zu bringen. Ebenfalls ist es möglich, dieses Teammitglied beispielsweise als Coach für Teammitglieder, die sich in diesem Lernfeld weiterentwickeln möchten, einzusetzen.
Wenn jedoch Expertenwissen im Team fehlt, sollte das Team versuchen Hilfe zu organisieren z.B. durch Workshops mit externen Experten, durch Besuche einzelner Teammitglieder in entsprechenden Schulungen mit anschließender Wissensvermittlung im Team. Im skalierten Umfeld kann auch intensives Zusammenarbeiten (bei Refinements/Businessanalyse und Designarbeit) mit Unterstützung eines Teams, das dort Expertise hat, helfen, um Wissen im angestrebten Lernfeld schnell aufzubauen.
Einige hilfreiche Methoden und Praktiken, um Wissen aufzubauen und die Fähigkeiten des Teams auszubauen:
- Pair-und Mob-Programming
- Coding-Dojos
- Aufsetzen von Community of Practices (für teamübergreifendes Lernen)
- Pair-Learning, Pair-Reading
- Dedizierte Zeiteinheiten reservieren für individuelles Lernen
- Aufsetzen von Foren:
z.B. Agile-Design-Forum zur Einführung der S.O.L.I.D. Design Prinzipien und GRASP Prinzipien - Einführung von ATDD und TDD (verbessert das Domänen-, Test- und Codeverständnis)
Die hier aufgeführten Ideen beziehen sich in erster Linie auf Teams in der Softwareentwicklung. Jedoch lassen sich sehr viele dieser Methoden und Praktiken in andere Bereiche übertragen und entsprechend anpassen.
6. Folgemodelle: Lernfortschritte aufzeigen
Regelmäßige Workshops zum Update bzw. zum Erstellen von Folge-TKMs hilft dem Team zu erkennen, ob die Maßnahmen wirklich wirken und ermöglicht dem Team Anpassungen vorzunehmen.
Nach drei, sechs, oder neun Monaten empfiehlt es sich den TKM Prozess zu wiederholen. Natürlich kann man zunächst den ersten Schritt "Auswahl der Lernfelder" auslassen. Man wiederholt die Schritte zwei, drei und vier.
Anschließend vergleicht man das aktuelle TKM mit dem vorherigen TKM. 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 des Teams, neue Dinge anzugehen aus.
In den Folge-Workshops wird sich auf das zuletzt erstellte TKM fokussiert. In der Diskussion stellt das Team vielleicht fest, dass es schon ausreichend in einem Lernfeld an Know-how aufgebaut hat und hier keine weiteren Aktivitäten des Teams 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 wird dann beim nächsten Update des TKMs als Vergleichsmodell verwendet.
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
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 links ist lediglich eine Vision, jeder kann sich in diese Richtung entwickeln und würde unterstützt werden. 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.
Beispiel aus der Praxis
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 (links) 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 in diesen Lernfeldern 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 nun, 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 aber andere Teams diese fachliche Komponente weiterentwickelt hätten und er sich nun nicht mehr so gut dort auskennen würde.
Im ersten Team-Knowledge-Model Workshop hatte das Team die unten aufgeführten Maßnahmen zum Know-how Aufbau beschlossen.
Beschlossene Maßnahmen
- 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
- Es wurde eine Wunschlist der zu lernenden Themen erstellt
- Wöchentlich (1/2 Stunde) wurden Aufgaben und Lösungen, die erarbeitet wurden, 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
- Nichts motiviert so sehr wie Erfolg, das Team-Knowledge-Model kann den Lernerfolg eines Teams aufzeigen.
Coaching Tipps & Tücken
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 zusammenbeleibt. Gemeinsames Lernen braucht Vertrauen und Routinen, dies 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 im Team weiterentwickeln. Dies kann durch das Management unterstützt werden. Beispielsweise durch Aufnahme eines Bewertungskriteriums für Mitarbeiter, das festhält, was dieser zur Entwicklung der Kollegen beigetragen hat.
Das Team-Knowledge Model lässt sich hervorragend in Team-Building-Workshops, z.B. nach einer Team Neuformierung, einem Self-Designing Team Workshop anwenden (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, dass Maßnahmen vereinbart wurden und diese nun auch angegangen werden müssen.
Regelmäßige Aktualisierungen des TKMs zeigt 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 6 Monaten, je nach Bedarf und Komplexität der Lernfelder des Teams.
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.