Wie man ein Spezialistenteam reibungslos auflöst
 |
| Bild: Unsplash / Annie Spratt - Lizenz |
Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.
Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.
Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.
Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.
Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.
Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.
Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.
In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.
