© Martin Good/Shutterstock.com
Business Technology Magazin
Kollaboration zwischen crossfunktionalen, selbstorganisierten Teams

Gleichgesinnte zusammenbringen

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.

Konstantin Diener


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 [1]. 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 werden 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, 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 ab...

Business Technology Magazin
Kollaboration zwischen crossfunktionalen, selbstorganisierten Teams

Gleichgesinnte zusammenbringen

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.

Konstantin Diener


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 [1]. 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 werden 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, 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 ab...

Neugierig geworden?


    
Loading...

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