Windows Developer | Aktiver Wissenstransfer im Team ist notwendig

Wie gehen wir schlau mit dem vorhandenen Wissen im Team um?

Stichworte gibt es viele dazu: Crossfunktionalität, Interdisziplinarität, GeneralistInnen, SpezialistInnen oder ein T-Shaped-Skill-Set. Diese Stichworte lassen sich auf eine zentrale Frage zurückführen: Welche Fähigkeiten benötigen wir, und bekommen wir das Wissen sinnvoll verteilt?

"Agile Entwicklungsteams sind interdisziplinär.
Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Produkt-Inkrement zu erstellen."

Im Scrum Guide schreiben Kim Schwaber und Jeff Sutherland [1] über interdisziplinäre Teams. Wenn ein Team, ein Projekt-Inkrement oder gar ein gesamtes Projekt erfolgreich umsetzen soll, muss das für die Umsetzung erforderliche Wissen, auch im Team vorhanden sein.  

Ein Team zeichnet sich vor allem dadurch aus, dass alle Beteiligten auf das gleiche Ziel hin arbeiten: das gemeinsame Teamziel. Alle anderen, möglicherweise konkurrierende Ziele, werden diesem untergeordnet. Alle kennen die Stärken und Schwächen der Beteiligten -- sowohl in Fähigkeiten als auch im Verhalten und können damit zielführend umgehen. 

Ein Team, dass nicht über das erforderliche Wissen zur Umsetzung eines Produkt-Inkrementes, das in Form einer UserStory beschrieben ist, wird früher oder später scheitern. Dabei meint Scheitern nicht nur das endgültige Scheitern im Sinne von "Nicht fertig werden". Sondern es meint auch den Verlust von Geschwindigkeit und Innovation.

Welche Kompetenzen im Team benötigt werden, hängt auch von der Definition of Ready ab.

Mit der Definition of Ready definiert das Team, welche Aufgaben bereits erfüllt sein müssen, bevor die Aufgabe im Team bearbeitet werden kann.

Dabei sind Anforderungen an ein Produkt-Inkrement nicht gleichzusetzen mit Vorgaben. In der Gesamtstruktur kann ein Produkt- oder Projektteam nur dann funktionieren, wenn die vorhandenen Skills im Team an die Feinheit der Anforderungen angepasst werden. Ein Projektteam ohne Design-Kenntnisse wird es schwer haben, Anforderungen ohne klar definierte Design-Vorlage umzusetzen.

Gleichzeitig wird ein Team ohne CSS-Kenntnisse nicht dazu in der Lage sein, eine solche Design-Vorlage auch umzusetzen. Das Team ist in der Selbstorganisation eingeschränkt – es ist auf Zulieferungen angewiesen. Solche Zulieferungen spiegeln sich auch in der Definition of Done wider. Ist ein Inkrement fertig, wenn es auf der Testumgebung bereitsteht oder dann, wenn es tatsächlich live verfügbar ist? 

Die agile Idee setzt auf kleine, abgeschlossene Produkt-Inkremente, die in sich fertig und damit „releaseable“ sind. Dieses Vorgehen ermöglicht dem Team das sofortige Deployment einzelner UserStorys. Das Team wird aus sich heraus, also selbstorganisiert, liefern.

Häufig wird der Deployment-Prozess aus dem eigentlichen Projektteam ausgeklammert. Die Selbstorganisation des Projektteams endet dann vor dem eigentlichen Release. Das Deployment findet erst am Ende eines Sprints oder sogar in individuell festgelegten Abständen durch Nichtmitglieder des Projektteams statt. Dieses Vorgehen hat direkte Auswirkungen auf die Leadtime – also auf die Durchlaufzeit eines Inkrements von der Idee bis zum Release. Je mehr Stationen ein Inkrement durchlaufen muss, desto länger wird auch der tatsächliche Bearbeitungszeitraum. Wenn das eigentliche Releasen nicht durch Projektteam erfolgt, mag das Team an Geschwindigkeit gewinnen, die aber direkt im Warten aufs Release wieder verloren geht.

Ist ein Team auf Zulieferungen eines Einzelnen oder einer anderen Abteilung angewiesen, arbeiten die Zulieferer an konkurrierenden Zielen. Dies wird die Geschwindigkeit des Projektteams auch beeinflussen. Auch hier ist mit Wartezeit zu rechnen. Ein Team, das von der Anforderung bis zur Auslieferung selbstgesteuert an Inkrementen arbeiten kann, wird schneller ausliefern. Damit ergibt sich eine kurze Leadtime für Produkte oder Produktverbesserungen. Das ist ein erstrebenswerter Vorteil in sehr beweglichen Märkten. 

Ein agiles Team hat alle Disziplinen im Team, die es braucht, um das Projekt oder Produkt zu realisieren. Zu Beginn mögen dabei nur Spezialkräfte im Team sein, die genau ihre Disziplin ausfüllen können. Aus Auslastungsgründen ist aber mehr als sinnvoll, wenn Tätigkeiten im Team möglichst von allen übernommen werden können. Wenn das nicht der Fall ist, verschiebt sich das Warten auf eine Disziplin in die agile Teamarbeit. 

Ein Projektteam sollte deshalb vor allem eines sein: Crossfunktional. In der Crossfunktionalität gehen wir von einem T-Shaped-Skill-Set aus. Das bedeutet, jedes Team-Mitglied hat seinen oder ihren Spezialbereich, gleichzeitig aber möglichst breites Basiswissen, um auch andere Aufgaben übernehmen zu können.

Aufgaben warten weniger, wenn mehrere Kandidaten oder Kandidatinnen für die Bearbeitung bereitstehen. Es ergibt also Sinn, Team-Mitglieder in neue Techniken, Vorgehensweise oder Aufgaben einzuarbeiten. Das kostet zunächst Aufwand. Nutzt aber -- denn es ergibt sich der Vorteil einer zügigen und kompetenten Bearbeitung von Anforderungen. Die Aufgaben innerhalb eines agilen Entwicklungszyklus sind priorisiert. Um den größtmöglichen Erfolg des Projekts sicherzustellen, ist die Abarbeitung der Aufgaben in ihrer Prioritäten unerlässlich. Dies gelingt nur dann, wenn möglichst viele Team-Mitglieder in der Lage sind, alle Aufgaben zu bewältigen. Viele Teams scheuen den aktiven Wissenstransfer.

Der vermeintlich einfachste Weg ist, im Team auszuloten, wer welches Spezialwissen mitbringt und die anstehenden Aufgaben dann entsprechend zu verteilen. Dieser Weg berücksichtigt allerdings nicht, dass Team-Mitglieder auf Grund von Urlauben oder gar Krankheiten ausfallen können. Ein solcher Ausfall gefährdet das Teamziel. Hinzu kommt die Wartezeit auf den Spezialisten oder die Spezialistin. Inkremente können eventuell nicht rechtzeitig fertig gestellt werden. Das Commitment des Teams wird nicht erfüllt, und am Ende werden Anforderungen nicht zeitgerecht umgesetzt.

Wir neigen dazu, den einfachsten Weg zu gehen. Aktiver Wissenstransfer ist eine bewusste Entscheidung, die Projektrisiken minimiert. Und für viele Teams gilt: "Unsere teaminterne Aufteilung in Disziplinen ist doch gut. Alle haben ihren klar definierten Spielbereich." Diese Haltung gefährdet die Wirtschaftlichkeit von Projekten. Verringern lassen sich diese Gefahren durch crossfunktionale Teams. 

Startet ein Team neu, erscheint Crossfunktionalität meist wie eine unerreichbare Utopie. „Dafür haben wir keine Zeit“, "Warum sollte jemand die Aufgabe machen, der nicht das größte Wissen hat?" oder „Niemand kann sich da sinnvoll einarbeiten. XYZ weiß das alles viel besser als der Rest“ sind häufig gehörte Argumente gegen aktiven Wissenstransfer im Team. Die Vorteile eines crossfunktionalen Teams werden gesehen, aber der Weg dahin erscheint zu steinig. Dabei lässt sich aktiver Wissenstransfer sehr leicht in das DailyDoing integrieren. 

Ein „Wir reden da mal drüber“ macht noch keinen Wissenstransfer. Wissenaufbau und -austausch im Team braucht Struktur. Ein bewährtes Mittel ist die Team-Skill-Matrix. Mit der Team-Skill-Matrix setzt ihr Euch bewusst mit den notwendigen und vorhandenen Kompetenzen in Eurem Team auseinander.

Die zentralen Fragestellungen sind: Welche Skills brauchen wir im Team, um das Ziel zu erreichen? Welche Skills haben wir bereits? Und wie sind diese konkret verteilt? Die Antworten auf diese Fragen lassen sich in einer Team-Skill-Matrix visualisieren.

Habt ihr euren Wissenstransfer-Bedarf identifiziert, folgt die Priorisierung. Nicht alle Skills und Wissenslücken sind gleich wichtig. Manche Kompetenzen werden erst zu einem bestimmten Zeitpunkt gebraucht oder ihr habt bereits mehrere Team-Mitglieder, die einen Bereich vorerst gut abdecken. In einem anderen steht allerdings nur eine Person zur Verfügung. Beginnt mit dem Wissenstransfer der Kompetenz, die für Euch den größten Hebel darstellt. 

Um sich deutlich zu machen, wo dieser Hebel liegen kann, könnt Ihr diese Team-Skill-Matrix auch um den Bedarf in einem perfekten Team ergänzen. Hierfür könntet Ihr eine Spalte "Bedarf [Aufwand] in Stellen / Zeit / Stunden" ergänzen und damit die real existierenden Kompetenzen im Team abgleichen. Über diesen Vergleich seht Ihr sehr schnell, welche Kompetenzen als Erstes ausgebaut werden sollten [2].

Nun entwickelt ihr entsprechende Maßnahmen. Mögliche Maßnahmen können der gezielte Besuch von Fortbildungen sein. Auch Slack-Time mit Themenschwerpunkten ist als Maßnahme denkbar , um sich selbstständig in ein Thema einzulesen und sich anschließend mit einem anderen Team-Mitglied über das Thema auszutauschen.

Eine weitere Maßnahme für den gezielten Wissenstransfer ist PairProgramming. Erfolgreiches PairProgramming ist mehr als miteinander an einem Schreibtisch zu sitzen und zu coden. Für ein erfolgreiches PairProgramming solltet ihr im Vorfeld eine PairProgramming-Matrix erstellen.

Sofern Ihr im Vorfeld eine Team-Skill-Matrix erarbeitet und damit eindeutig idenfizierte Wissenstransfer-Bereiche zur Verfügung haben, nutzt Ihr diese Ergebnisse für Eure PairProgramming-Matrix. Dabei werden alle Team-Mitglieder einmal in der X-Achse als "Driver" und einmal in der Y-Achse als "Navigator" aufgeführt.

Der Driver schreibt während der Umsetzung den Code und trifft Detailentscheidungen. Der Navigator gibt die Richtung vor, sagt also an, was als nächstes zu tun wäre. Der Navigator gibt so Kurs und erläutert das grundsätzliche Design. Er oder sie kontrolliert den Code und sucht eventuelle Fehler. Nach einem festgelegten Zeitraum wechseln die Beteiligten ihre Rollen. Ein Wechsel kann zum Beispiel nach der Umsetzung einer Unteraufgabe, nach einem festen Zeitraum oder einer bestimmten Anzahl an Zeichen erfolgen.

Der Wechsel zwischen diesen Rollen ist zwingend erforderlich. Er fördert das Verständnis beider Seiten über die eigentliche Wissenshürde. Und beide Seiten können übeprüfen, wie der Lernfortschritt läuft. 

Auch außerhalb von Entwicklungsteams ist Pairing ein bewährtes Mittel. So könnt ihr für nahezu jeden Wissens- und Tätigkeitsbereich eine Matrix erstellen. Das Prinzip bleibt ähnlich: Derjenige, der Wissen vermittelt, bleibt zunächst aktiv, während der oder die Lernende als Zuschauer oder „Schatten“ begleitet. Zu gegebener Zeit tauschen die Beteiligten Ihre Rollen. Diese Art der Wissensvermittlung führt zum Beispiel im Bereich Moderation zu sehr guten Ergebnissen. Wichtig ist allerdings, dass die Beteiligten nach allen Terminen ein direktes Feedback-Gespräch vereinbaren, um Gesehenes zu besprechen.

Ein weiteres Ritual zum gezielten Wissenstransfer können interne Konferenzen oder gezielte Slack-Time, also nicht-verplante Zeit, sein. Insbesondere für den teamübergreifenden Wissenstransfer sind interne Konferenzen oder Community of Practices ein gutes Mittel.

Eine Community of Practice (CoP) besteht üblicherweise aus Personen, die an ähnlichen Aufgaben arbeiten. Sie treffen sich in regelmäßigen Abständen, um über Erfolge und Misserfolge, aber auch über neue Entwicklungen zu sprechen. Es hat sich außerdem bewährt, wenn die CoP für jeden Termin gezielt ein Thema und teilweise sogar einen Referenten oder eine Referentin festlegt. In einer CoP erlangtes Wissen sollte mit einem ähnlichen Ritual wieder zurück ins eigene Entwicklungsteam gebracht werden, um den Wissensgewinn möglichst weit zu streuen.

Interne Konferenzen geben MitarbeiterInnen bewusste Zeit sich mit Themen auseinander zu setzen. Die Themen können hierbei entweder vorgegeben oder frei gewählt werden. Wichtig für den Wissenstransfer ist es, ein Format zu finden, in dem in Teams gearbeitet wird.

Für eine interne Konferenz kann unter anderem ein Format ähnlich einer „Unconference“ genutzt werden. Bei einer Unconference benennen die Teilnehmerinnen und Teilnehmer Themen zu denen sie etwas beitragen möchten. Gleichzeitig dürfen sie aber auch Themen benennen, zu denen sie gerne etwas hören oder arbeiten möchten. Mit einem einfachen Punkte-Voting-Verfahren werden die tatsächlichen Themen ausgewählt. Alle Ergebnisse der Themen-Sessions werden dokumentiert und im Anschluss für jeden und jede zur Verfügung gestellt.

Wissenstransfer kostet Zeit. Zeit die Ihr im Projektalltag zunächst gefühlt nicht habt. Spätestens wenn eine UserStory ins Stocken gerät, weil der Spezialist für die Aufgabe ausfällt, werdet Ihr merken: Langsam an einer Aufgabe zu arbeiten, ist immer noch besser als gar nicht an ihr zu arbeiten.

Verabschiedet Euch von dem Gedanken, innerhalb weniger Tage die perfekten T-Shaped-Skill-Sets aufzubauen. Die braucht Ihr auch nicht. Ihr braucht ein Team, dass zu jedem Zeitpunkt dazu in der Lage ist die Anforderungen im aktuellen Entwicklungszyklus umzusetzen. Die Frage ist also nicht, wie Ihr ein perfektes Skill-Set im Team erreicht, sondern zunächst, wir Ihr den ersten Schritt in Richtung T-Shaped machen könnt. Das Etablieren von Ritualen zum Wissenstransfer ist dieser Schritt.

Der Artikel ist eine Zweitveröffentlichung des gleichnamigen Artikel von Julia Schmidt in der Zeitschrift "Windows Developer 07.2016". Abweichend vom Original ist die Anrede in diesem Artikel "Ihr", während im Zeitschriften-Artikel gesiezt wird.

• Nächster Artikel: Newsletter | Agile Produkt- und Teamentwicklung
• Vorheriger Artikel:  95 Methodenbausteine für agile Retrospektiven. Aus der Praxis für die Praxis.