Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

God save the team!?

2.11.2022 | 6 Minuten Lesezeit

Vom Mythos der langlaufenden und stabilen Teams: Ein Appell für dynamische Teams in agilen Organisationen

Agilität ist ein Buzzword der aktuellen Zeit. Viele Unternehmen und Organisationen möchten agil sein, agil arbeiten oder agile Teams aufsetzen. Die Auslöser und Ziele dieser Initiativen sind ebenso vielseitig wie die Methoden, mit denen dieses Ziel umgesetzt wird. Scrum, KanBan oder SAFe, in skalierten Umgebungen, sind Frameworks, die vor allem in Softwareentwicklungs-Teams viel Zuspruch finden.

Viele dieser Methoden eint die Forderung, das Team in den Mittelpunkt sämtlicher Aktivitäten zu rücken und sich weniger auf Prozesse, Mechanismen oder Technologien zu versteifen, sondern vor allem menschlich zusammenzurücken und den vollen Fokus auf das Produkt sowie die Zusammenarbeit im Team zu legen (vgl. Heart of Agile – A. Cockburn).

Ein stabiles Team bringt, im besten Fall, unbestreitbar Vorteile mit sich:

  • Die Personen sind aufeinander eingespielt und kennen einander. Somit sind Arbeitsweisen und persönliche Vorlieben im Team bekannt und müssen nicht mehr re-diskutiert werden (vgl. Teamphasen nach Tuckman)

  • Rollen sind besetzt und Verantwortlichkeiten im besten Fall klar zugeteilt

  • Die psychologische Sicherheit der Teammitglieder untereinander wird erhöht: Man kennt einander, hat sich auch bereits auf persönlicher Ebene ausgetauscht und hat so vor allem in herausfordernden persönlichen Lebenssituationen eine tiefere Vertrauensbasis zueinander

Der Mythos der langlaufenden, stabilen Teams

Doch wenn ich ehrlich bin, dann sind stabile Teams in der Praxis eher eine absolute Ausnahmeerscheinung: Ich persönlich habe in den vergangenen Jahren in unterschiedlichen Rollen noch kein Team erlebt, das länger als drei Monate in stabiler personeller Konstellation gearbeitet hat. Meiner Erfahrung nach zwingen unterschiedliche Faktoren Teams zu Anpassung und Veränderung:

  • Kolleg:innen entwickeln sich weiter und nehmen andere und neue Rollen ein, verlassen das Unternehmen, um einen Traum zu verwirklichen, werden Eltern und gehen somit in Elternzeit oder nehmen ein Sabbatical

  • Viele Teams, auch in der Softwareentwicklung, sind mit Internen sowie Externen besetzt. Somit erfolgen hier zwangsläufig Wechsel: Beauftragungen und Vertragslaufzeiten können aus vielfältigen Gründen auslaufen oder Kolleg:innen werden in neue Projekte gezogen

  • Unternehmen wollen wachsen oder benötigen mehr fachlichen Support durch Fachkräfte und stellen somit neue Kolleg:innen ein

Von passivem Management zu aktiver Steuerung

Ich spreche mich hier aktiv dafür aus, personelle Wechsel und neue Teamkonstellationen nicht nur passiv zu managen, sondern aktiv herbeizuführen und zu beeinflussen. Agile Projekte sind oft in schnelllebigen Umgebungen zuhause. Das heißt, der Markt verändert sich in rasanter Geschwindigkeit und somit entwickeln sich auch die Anforderungen an das Team ständig weiter. Durch eine regelmäßige Anpassung in den Teamkonstellationen können agile Teams personell möglichst perfekt auf die aktuelle Problemstellung zugeschnitten werden. So skizziert beispielsweise bereits Conway's Law wie die organisationalen Rahmenbedingungen Einfluss auf das Softwareprodukt nehmen.

Aktuell werden die fortschreitenden Anforderungen in stetigen Teams zwar besprochen, oft jedoch auf sachlicher Ebene. Rollen, Beziehungen und Aufgabenpakete sind im Team bekannt, inhaltliche, sachliche Änderungen werden ergänzt. Oft wird keine Notwendigkeit dafür gesehen, den grundsätzlichen Status Quo zu hinterfragen. Natürlich wird in Retrospektiven oder Teamworkshops über Effizienz oder Ineffizienz des aktuellen Entwicklungs- oder Projektfortschrittes gesprochen, allerdings meist auf einer Ebene, die nicht hinterfragt, ob die organisationale Gesamtkonstellation eines Teams inkl. Rollen und Fertigkeiten der einzelnen Teammitglieder so die bestmögliche für das aktuelle Entwicklungs- bzw. Projekt Setup ist. 

In der Praxis zeigt sich gerade in skalierten Umgebungen, also dort, wo mehrere Teams an einem Produkt arbeiten oder es hohe Überschneidungen mit Fach- und Nachbarabteilungen gibt, dass dieser dynamische Ansatz eine ungeheure Kraft birgt.

Initialisierung dynamischer Teams

Es gilt, ganz zu Beginn alle bestehenden Gedanken zu personellen Team-Zugehörigkeiten in den Hintergrund zu stellen und in einem Kernteam inkl. fachlicher Ansprechpartner:innen rein die anstehenden Meilensteine und Aufgabenpakete zu betrachten:

  • Welche Aufgabenpakete stehen an? 

  • Welche Aufgabenpakete können in logische Einheiten (= in einem Team) 
    gebündelt werden? Auch vor dem Hintergrund systemseitiger Abhängigkeiten

  • Welche Kompetenzen benötigen wir zur Erfüllung der einzelnen Aufgabenpakete?

Diese Überlegungen aus dem Kernteam werden dann in einer Übersicht zusammengefasst und visualisiert. Diese Übersicht bietet die Gesprächsgrundlage für eine Diskussion im Team zu den inhaltlichen Meilensteinen für die nächsten Monate. Im besten Fall können sich die Teammitglieder anschließend selbst auf die unterschiedlichen Teams aufteilen, bzw. sich zu Themen zuordnen. Das geschieht in einem Workshop-Setting und mit offener Diskussion. 
Die folgenden Sätze sind im Rahmen eines solchen Workshops schon so oder so ähnlich gesagt worden:

  • „Peter, meinst du nicht, du solltest lieber für die nächsten drei Monate ins Team 2 kommen? Da wird bei Thema y auf jeden Fall dein Infrastruktur-Wissen benötigt.“

  • „Wäre es möglich, dass wir die UX-Kompetenzen aufteilen? Also 50/50 auf Team 3 und 4?“

  • „Wir haben bei Thema x, nachdem es einmal aufgesetzt ist, sehr viele Lift-and-Shift-Aufwände. Wäre das nicht super, wenn wir hier den neuen Junior-Kollegen erstmal mit ins Team holen? Dann hat er gleich die Chance, hier aktiv zu unterstützen und kann nach kurzer Einarbeitung bereits eigenständig arbeiten.“

Vorteile dynamischer Teams 

Eine dynamische Teamaufteilung und somit auch eine regelmäßige Adaption der Teamkonstellationen bringt in der Praxis viele Vorteile mit sich.

⁠Autonomie der Teams
Ob die Teams unterschiedlicher Größe sind oder nach welchem Framework sich die einzelnen Teams praktisch im Arbeitsalltag organisieren, liegt hierbei in der Entscheidung der Gruppe. Entscheidend ist jedoch die klare Priorisierung der Arbeitspakete und die damit verbundene, möglichst einwandfreie Zuteilung von Kompetenz zum Thema.

Kontinuierliches Onboarding
Dieser Ansatz, die stetigen Teams aufzubrechen und zu dynamisieren, ermöglicht es den Teams, wechselnden Teammitgliedern zu begegnen, denn so haben neue Teammitglieder früh die Möglichkeit, einen guten Überblick über Aufgabenpakete, Prioritäten und Skills der anderen Teammitglieder zu gewinnen, sich aktiv mit einzubringen und die eigenen Fertigkeiten früh möglichst gewinnbringend einbringen zu können. Gleichzeitig ist das Onboarding für neue Teammitglieder zu Beginn überschaubarer, da sich neue Teammitglieder nicht mit „allen“ Teilbereichen eines Produktes beschäftigen müssen, sondern erst einmal in den Deepdive zu einem Teil gehen können und somit schneller aktiver Teil des Entwicklungs- und Umsetzungsprozesses sind.

Lernen und Entwickeln
Außerdem ermöglichen diese dynamischen Teams einen stetigen Lern- und Entwicklungsprozess der unterschiedlichen Kolleg:innen untereinander. Bestehende Kopfmonopole werden aufgeweicht und unterschiedliche Teammitglieder haben die Möglichkeit, von- und miteinander zu lernen, somit wird Wissen breiter über das gesamte Team verteilt.

Dynamische Teams etablieren

Natürlich muss dieser neue Arbeitsmodus in dynamischen Teams gerade zu Beginn, zum Beispiel durch einen erfahrenen Agile Coach, sehr gut begleitet werden. Die folgenden Punkte gilt es im Rahmen einer Initialisierung zu bedenken:

  • Unsicherheiten und Sorgen von Teammitgliedern aufnehmen und diskutieren
  • Transparenz gegenüber Führungskräften und Management schaffen
  • Commitment über Rahmenbedingungen schaffen, vor allem zu teamübergreifenden fachlichen Abstimmungen
  • Verprobungs-Zeitraum festlegen
  • Arbeitsweisen vereinbaren, in Developmentteams z. B. klare Regeln zu Code Ownership, der Definition of Done und Testing
  • Feedbackmechanismen teamintern und teamübergreifend etablieren


In der Praxis ermöglichen dynamische Teamkonstellationen agilen Teams nicht nur, den Wissensaustausch untereinander zu fördern, sondern machen auch persönliche Auszeiten für jede:n planbarer und setzen vor allem wieder das Produkt sowie die Domäne in den Fokus sämtlicher Bemühungen.

Beitrag teilen

Gefällt mir

4

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.