Agile & DevOps

Wie verteilt man WIssen in agilen Teams sinnvoll?

Crossfunktionale Teams – aktiver Wissenstransfer im Team
Keine Kommentare

Wie gehen wir schlau mit dem vorhandenen Wissen im agilen Team um? Stichworte gibt es viele dazu: Crossfunktionalität, Interdisziplinarität, Generalisten, Spezialisten oder ein T-Shaped-Skill-Set. Diese Begriffe lassen sich auf folgende Fragen 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 Produktinkrement zu erstellen“ – im Scrum-Guide schreiben Ken Schwaber und Jeff Sutherland über interdisziplinäre Teams. Wenn ein Team, ein Projektinkrement 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 was die Fähigkeiten als auch was das Verhalten anbetrifft – und können damit zielführend umgehen. Ein Team, das nicht über das erforderliche Wissen zur Umsetzung eines Produktinkrements verfügt, das in Form einer User Story 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 auch den Verlust von Geschwindigkeit und Innovation. Welche Kompetenzen im Team benötigt werden, hängt auch von der „Definition of Ready“ (DoR) ab. Damit definiert das Team, welche Aufgaben bereits erfüllt sein müssen, bevor die Aufgabe im Team bearbeitet werden kann.

Team-Skills an Anforderungen anpassen

Dabei sind Anforderungen an ein Produktinkrement nicht mit Vorgaben gleichzusetzen. 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 Designkenntnisse wird es schwer haben, Anforderungen ohne klar definierte Designvorlage umzusetzen.

Gleichzeitig wird ein Team ohne CSS-Kenntnisse nicht dazu in der Lage sein, eine solche Designvorlage 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 (DoD) 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 Produktinkremente, die in sich fertig und damit „releaseable“ sind. Dieses Vorgehen ermöglicht dem Team das sofortige Deployment einzelner User Storys. 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 Lead-Time, 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 Veröffentlichen nicht durch das Projektteam erfolgt, mag das Team an Geschwindigkeit gewinnen, diese geht aber beim Warten auf das Release direkt wieder verloren.

Ist ein Team auf Zulieferungen eines Einzelnen oder einer anderen Abteilung angewiesen, arbeiten die Zulieferer an konkurrierenden Zielen. Dies wird die Geschwindigkeit des Projektteams ebenfalls 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 Durchlaufzeit für Produkte oder Produktverbesserungen. Das ist in sehr beweglichen Märkten ein erstrebenswerter Vorteil.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Agile Teams: Crossfunktionalität ist Trumpf

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 es allerdings mehr als sinnvoll, dass 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 Teammitglied hat seinen oder ihren Spezialbereich, gleichzeitig aber möglichst breites Basiswissen, um auch andere Aufgaben übernehmen zu können.

Aufgaben bleiben weniger lang liegen, wenn mehrere Kandidaten für die Bearbeitung bereitstehen. Es macht also Sinn, Teammitglieder in neue Techniken, Vorgehensweisen oder Aufgaben einzuarbeiten. Das kostet zunächst Aufwand, der sich allerdings bezahlt macht. 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 je nach Priorität unerlässlich. Das gelingt nur dann, wenn möglichst viele Teammitglieder in der Lage sind, alle Aufgaben zu bewältigen. Viele Teams scheuen den aktiven Wissenstransfer.

Spezialwissen verteilen!

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 Teammitglieder aufgrund von Urlauben oder gar Krankheiten ausfallen können. Ein solcher Ausfall gefährdet das Teamziel. Hinzu kommt die Wartezeit auf den Spezialisten. 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.

Start where you are

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 erkannt, aber der Weg dahin erscheint zu steinig. Dabei lässt sich aktiver Wissenstransfer sehr leicht in das Daily Doing integrieren.

Rituale nutzen!

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

Die zentralen Fragestellungen sind: Welche Skills brauchen wir im Team, um das Ziel zu erreichen? Welche Skills bringen wir bereits mit? Und wie sind diese konkret verteilt? Die Antworten auf diese Fragen lassen sich in einer Team-Skill-Matrix visualisieren (Abb. 1). Hierfür listet man zunächst alle identifizierten Skills und den benötigten Skill-Level auf. In die X-Achse setzt man alle Teammitglieder mit Namen und jeweils eine Spalte für Notizen und Maßnahmen. Bei der Skill-Betrachtung ist es empfehlenswert, zwischen drei Wissensständen zu unterscheiden:

  1. Kann unterrichten.
  2. Kann durchführen.
  3. Kann unter Anleitung umsetzen.
schmidt_wissenstransfer_1

Abb. 1: Die Team-Skill-Matrix wird für das Projekt erfasst und öffentlich aufgehängt

Wurde der Wissenstransferbedarf identifiziert, folgt die Priorisierung. Nicht alle Skills und Wissenslücken sind gleich wichtig. Manche Kompetenzen werden erst zu einem bestimmten Zeitpunkt gebraucht oder es gibt bereits mehrere Teammitglieder, die einen Bereich vorerst gut abdecken. In einem anderen steht allerdings nur eine Person zur Verfügung. Am besten man beginnt mit dem Wissenstransfer der Kompetenz, die für das Team den größten Hebel darstellt.

Um sich deutlich zu machen, wo dieser Hebel liegen kann, kann man die Team-Skill-Matrix auch um den Bedarf in einem perfekten Team ergänzen. Hierfür kann eine Spalte „Bedarf [Aufwand] in Stellen/Zeit/Stunden“ ergänzt und damit die real existierenden Kompetenzen im Team abgeglichen werden. Über diesen Vergleich sieht man sehr schnell, welche Kompetenzen als Erstes ausgebaut werden sollten.

Nun entwickelt man entsprechende Maßnahmen. Mögliche Maßnahmen können der gezielte Besuch von Fortbildungen sein. Aber 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 Teammitglied über das Thema auszutauschen.

Pair Programming? Ja – nach festen Regeln

Eine weitere Maßnahme für den gezielten Wissenstransfer ist Pair Programming. Erfolgreiches Pair Programming ist mehr als lediglich miteinander an einem Schreibtisch zu sitzen und zu coden. Für ein erfolgreiches Pair Programming sollte man im Vorfeld eine Pair-Programming-Matrix erstellen. Sofern man im Vorfeld eine Team-Skill-Matrix erarbeitet und damit eindeutig idenfizierte Wissenstransferbereiche zur Verfügung hat, nutzt man diese Ergebnisse für die Pair-Programming-Matrix. Dabei werden alle Teammitglieder einmal in der X-Achse als „Driver“ und einmal in der Y-Achse als „Navigator“ aufgeführt. Das Ziel ist es, dass jedes Teammitglied einmal in einem bestimmten Zeitraum in jeder dieser beiden Rollen gearbeitet hat (Abb. 2).

schmidt_wissenstransfer_2

Abb. 2: Die Pairing-Matrix gibt Auskunft, welche Teammitglieder in welchen Rollen miteinander gearbeitet haben

Für ein erfolgreiches Pair Programming sollte zudem eine genaue Anzahl an Aufgaben oder Storys für einen konkreten Zeitraum festgelegt werden, die im Pairing bearbeitet werden sollen. Im Planning werden die ausgewählten User Storys entsprechend markiert.

Kommt eine solche Aufgabe nun zur Bearbeitung, legt man die beiden Bearbeiter fest. Eine Person als Driver, die andere als Navigator. 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 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 überprüfen, wie der Lernfortschritt vorangeht.

Pairing – auch über die Technik hinaus

Auch außerhalb von Entwicklungsteams ist Pairing ein bewährtes Mittel. So kann man 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 Feedbackgespräch vereinbaren, um Gesehenes zu besprechen.

Pairing nicht nur als Pair Programming nutzenPairing funktioniert nicht nur als Pair Programming. Auch in anderen Aufgabenbereichen kann Pairing als Wissenstransferbaustein genutzt werden. Beispielsweise hier:

  • Moderation von Teamritualen
  • Erstellung von Basisdesigns für das Softwaresystem (Grafik plus Frontend)
  • Formulierung von Anforderungen (Epics, User Storys)

Über das Team hinaus

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 (CoP) ein gutes Mittel.

Eine 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 festlegt. Wissen, das in einer CoP erlangt wurde, sollte mit einem ähnlichen Ritual wieder zurück ins eigene Entwicklungsteam gebracht werden, um den Wissensgewinn möglichst weit zu streuen.

Im Rahmen von internen Konferenzen haben Mitarbeiter Zeit, sich bewusst mit Themen auseinanderzusetzen. 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 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 zur Verfügung gestellt.

Einfach mal machen

Wissenstransfer kostet Zeit. Zeit, die man im Projektalltag zunächst gefühlt nicht hat. Spätestens wenn eine User Story ins Stocken gerät, weil der Spezialist für die Aufgabe ausfällt, wird man 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 man auch nicht. Man braucht ein Team, das zu jedem Zeitpunkt dazu in der Lage ist, die Anforderungen im aktuellen Entwicklungszyklus umzusetzen. Die Frage ist also nicht, wie man ein perfektes Skill-Set im Team erreicht, sondern zunächst, wie man den ersten Schritt in Richtung T-Shaped machen kann. Das Etablieren von Ritualen zum Wissenstransfer ist dieser Schritt.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -