© saicle/Shutterstock.com
Aktiver Wissenstransfer im Team ist notwendig

Crossfunktionale Teams


Wie gehen wir schlau mit dem vorhandenen Wissen im Team um? Stichworte gibt es viele dazu: Crossfunktionalität, Interdisziplinarität, Generalisten, Spezialisten oder ein T-Shaped-Skill-Set. Diese Stichworte 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 [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 hinarbeiten: 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.

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 Produkt­inkremente, 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 Inkremente...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang