Konstantin Diener cosee

Communities of Practice sind ein mächtiges Werkzeug zur Vernetzung der Experten aus crossfunktionalen Teams.

Immer mehr Organisationen wandeln sich hin zu einem Aufbau mit crossfunktionalen, selbstorganisierten Teams. Nach diesem Schritt geht es darum, wie die Experten in den einzelnen Teams vernetzt werden und wie Wissen verteilt wird. Auch übergreifende Entscheidungen und Standards müssen nun crossteam getroffen werden.

Sobald ein Unternehmen wächst, fängt es an, mehr und mehr Strukturen zu bilden. Dieses Verhalten lässt sich einfach erklären. Mit jedem weiteren Mitglied eines Teams steigen die Koordinationskosten überlinear. Die optimale Größe eines Teams liegt zwischen drei und neun Mitgliedern. Wird das Team größer, sollte es in mehrere Teams aufgeteilt werden. Der in der IT lange Zeit vorherrschende Ansatz für diese Aufteilung war, die Teams nach Funktionen zu teilen. Die Mitarbeiter, die dieselben Aufgaben ausführen, wurden in einem Team oder in einer Abteilung zusammengefasst: Backend-Entwickler, Frontend-Entwickler, Tester, DBAs oder Sysadmins.

Agile Entwicklungsmodelle wie Scrum brechen mit dieser Art der Aufteilung und fordern crossfunktionale Teams. Alle Spezialisten, die zum Liefern von Customer Value in Form eines Shippable Product Increments notwendig sind, sollen zusammen in einem Team sein und möglichst wenig Abhängigkeiten zu anderen Teams haben. Später kam die DevOps-Bewegung hinzu, zu deren zentralen Anliegen die Abschaffung der funktionalen Silos von Dev und Ops gehört. Immer mehr Unternehmen erkennen die Vorteile crossfunktionaler Teams und beginnen, ihre Organisation entsprechend umzustellen.

Durch die Umstellung einer Organisation auf crossfunktionale Teams ergibt sich für die Mitarbeiter eine neue Situation. Die Gruppe der Backend-Entwickler, Frontend-Entwickler, Tester, DBAs oder Sysadmins wird auseinandergerissen und die Mitarbeiter auf verschiedene crossfunktionale Teams verteilt (Abb. 1). Dabei beobachtet man nach einer Weile in der Regel drei Effekte: fehlende Hilfe bei Problemen, fehlender Wissenstransfer und Inselentscheidungen. Im crossfunktionalen Team gibt es nur wenige oder gar keine anderen Mitarbeiter mehr, die einem bei konkreten Problemen helfen können, z. B. einem Backend-Entwickler dabei zu helfen, einen Bug in einer Backend-Komponente zu finden. Der Entwickler findet also weniger Hilfe und Ansprechpartner. Backend- oder Frontend-Entwickler sitzen nicht mehr eng beieinander und profitieren so nicht mehr von Erfahrungen und Fehlern der anderen. Entwickler, die neu im Unternehmen sind, kennen die anderen Kollegen noch nicht einmal von früher. Das schadet dem Wissenstransfer. Da crossfunktionale Teams in der Regel selbstorganisiert sind, z. B. in Scrum, treffen sie auch viele Technologieentscheidungen ohne Austausch mit den anderen Teams. Diese Entscheidungen sind für das einzelne Team scheinbar richtig, für die Gesamtorganisation aber möglicherweise kontraproduktiv. Es entstehen Insellösungen.

Abb. 1: Mehrere crossfunktionale Teams

Abb. 1: Mehrere crossfunktionale Teams

Vor allem in der Entwicklung von IT-Anwendungen überwiegen die Vorteile crossfunktionaler Teams. Aus diesem Grund sollten Organisationen, die die beschriebenen Beobachtungen machen, nicht einfach wieder zu funktionalen Teams zurückkehren, sondern eine Vernetzung der jeweiligen Experten untereinander ermöglichen. Diese Vernetzung geschieht in der Regel durch Communities of Practice.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Business Technology 4.17 - "Teams spielen heute anders"

Alle Infos zum Heft
579819720Gleichgesinnte in Communities of Practice zusammenbringen
X
- Gib Deinen Standort ein -
- or -