Was zeichnet erfolgreiche agile Teamarbeit aus
Agile Teams sind interdisziplinäre Arbeitsgruppen, die fokussiert und engagiert zusammenarbeiten. Erfolgreiche agile Teamarbeit hängt nicht primär von einem bestimmten Ort ab, sondern von geteilten Werten, gemeinsam getragenen Zielen und einem offenen und vertrauensvollen Miteinander. Erfolgreiche agile Teamarbeit zeigt sich u.a. durch echte High Performance, durch die in kürzerer Zeit bessere Arbeitsergebnisse erreicht werden.
Wie entstehen erfolgreiche agile Teams
Die Grundvoraussetzungen für erfolgreiche agile Teamarbeit sind Diversität, Vertrauen, Fokus und eine klare Zielvision. Genau dort setzt unsere Teamentwicklung an. Wir begleiten agile Teams von ihrer Gründung bis zur High Performance. Dafür vermitteln wir passende Tools & Methoden und laden das Team regelmäßig zur gemeinsamen Reflexion ein. Bei Bedarf führen wir Einzelcoachings durch, um die individuellen persönlichen Stärken der Teammitglieder:innen weiter zu fördern.
Agile Teams richtig führen
Teamentwicklung macht nicht an einer Teamgrenze halt. Das jeweilige Umfeld nimmt Einfluss auf den Erfolg eines Teams. Wir geben Tipps und Hinweise, welche Einflussfaktoren die Teamentwicklung fördern oder behindern können. Auf Wunsch unterstützen wir Führungskräfte aktiv bei ihrer fachlichen und persönlichen Weiterentwicklung im Bereich Agile Leadership.
Individuelle Vorgehensweise
Kein Team gleicht einem anderen. Jedes Team entwickelt mit der Zeit seine eigene Subkultur und ist zugleich ein Abbild der jeweiligen Unternehmenskultur. Bei der Teamentwicklung verlassen wir uns nicht auf einfache Blaupausen, sondern arbeiten mit jedem Team individuell und vertrauensvoll zusammen. Unsere Arbeitsweise ist werte- und prinzipienbasiert. Dazu zählen Offenheit, Respekt, Vertrauen, Fairness und Verbindlichkeit. Gemeinsam mit den Teammitgliedern reflektieren wir regelmäßig den Status quo und finden Verbesserungsmöglichkeiten für bessere Ergebnisse.
Dauer und Kosten einer Teamentwicklung
Wir haben in den letzten Jahren viele erfolgreiche agile High-Performance-Teams entwickelt. Bei unserer Arbeit setzen wir von Anfang an konsequent auf die Eigenverantwortung der Teammitglieder:innen. Mit einem hohen Maß an Vertrauen und Respekt, stellen sich meist schon nach kurzer Zeit erste wahrnehmbare Erfolge ein. Jedes Team wird individuell von uns betreut. Pro Team investieren wir mehrere Tage in ein gemeinsames Teambuilding und begleiten es für max. sechs Monate an bis zu vier Tagen pro Monat. Die Kosten bleiben damit berechenbar. Wir machen uns entbehrlich.
Praxisbeispiel agile Teamentwicklung
Drei Monate haben wir mit einem Team gearbeitet, das anspruchsvolle Messtechnik entwickelt. Herz und Hirn des Teams galt ein Teamleiter, der immer alles wusste und Antwort auf jede fachliche Frage geben konnte. Es gab keinen Projektplan und keine richtige Dokumentation. Alles war im Kopf des Teamleiters. Jedes Teammitglied konnte sich darauf verlassen, dass die Ideen und Vorschläge des Teamleiters zum Ziel führten. Er koordinierte die Arbeit jedes Einzelnen und bestimmte präzise, wer wann woran arbeiten sollte.
Ein viertel Jahr vor unserem Arbeitsbeginn verstarb der Teamleiter ganz plötzlich. Neben dem menschlichen Verlust stand das Team plötzlich nahezu mit leeren Händen da. Es gab keine richtige Dokumentation und keinen strukturierten Arbeitsprozess für die aktuelle Neuentwicklung. Drei Monate lang versuchte das Team irgendwie weiterzumachen. Mit mäßigem Erfolg. Es fehlte an Wissen zu den übergeordneten Produktzusammenhängen und fokussierter Teamarbeit. Jeder arbeitete an Dingen, von denen er annahm, es wäre nützlich für das Produkt.
Derweil sich abzeichnete, dass die Prognose für eine Lieferfähigkeit des Produktes immer schlechter wurde, entschied die Geschäftsführung kurzerhand das Entwicklungsteam extern zu unterstützen. Wir erhielten den Auftrag dazu. Als unser Coach erstmals auf das Team traf, wurde er zwar freundlich empfangen, aber es war wahrnehmbar, dass ihn nicht jeder willkommen hieß. Es entsprach ganz offensichtlich nicht dem Wunsch des Teams, dass ein Externer es bei der Veränderung der Arbeitsweise unterstützen soll.
Egal wie viele Jahre Erfahrung man hat, für solche Situationen gibt es kein Best Practice, sondern nur tragfähige Werte & Prinzipien: Respekt, Vertrauen, Freiwilligkeit, Transparenz & Feedback.
Die Irritation mancher Teammitglieder, einen Externen ins Team zu bringen, konnte unser Coach gut verstehen und respektieren. Ihm wäre es vermutlich auch so ergangen! Daher hat er vom ersten Moment auf Freiwilligkeit gesetzt. Seine Ansprache ans Team lautete “Ich bin nicht hier, um euch zu sagen, was ihr falsch macht. Das steht mir gar nicht zu. Stattdessen möchte ich euch einladen, gemeinsam mit mir etwas auszuprobieren: Lasst uns sechs Wochen etwas Neues versuchen und ihr entscheidet danach, ob es für euch passt oder nicht.”
Einen Tag hat er dem Team zugehört, sich die Arbeit erklären lassen, welche Herausforderungen sie haben und ihnen im Anschluss das Rahmenwerk Scrum vorgestellt. Manch einer war sofort begeistert und wollte es ausprobieren, manch einer war sogar noch skeptischer als vorher. Unser Coach hat gesagt, dass er zwar das finanzielle Mandat von der Geschäftsleitung für eine Zusammenarbeit habe, die Entscheidung, ob sie wirklich zusammenarbeiten werden, ausschließlich beim Team und ihm läge. Ein Nein hätte er anstandslos akzeptiert.
Zwei Teammitglieder waren dafür, drei waren skeptisch und einer knapp vor einem Veto. Wahrscheinlich hat er gespürt, dass unser Coach seine Entscheidung zu jeder Zeit akzeptieren würde und sich nur deshalb auf den Versuch eingelassen. Respekt und Freiwilligkeit sind dafür entscheidend.
Zuerst hat unser Coach gemeinsam mit dem Team ein Backlog aufgebaut, ohne ständig die englischen Begriffe dafür zu verwenden. Es wurde es erst einmal nur ‘Ideensammlung’ genannt und aufgeschrieben, was bekannt war und für das neue Produkt benötigt werden würde. Im Anschluss wurde vereinbart, sich jeden Tag kurz und einmal pro Woche etwas länger zu treffen, um ganz konkret über die Arbeitsergebnisse und Verbesserungsmöglichkeiten zu sprechen (das Daily, der Sprint und die Scrum-Kadenz waren geboren).
Im ersten Review wurde eine Zeichnung von einem Entwickler auf den Tisch gelegt und erklärt, warum der Schaltkreis überarbeitet werden müsste. Dann gab es die Idee, die Arbeitsfortschritte besser zu dokumentieren und noch vor Fertigstellung eine Zweitmeinung einzuholen. Damit war die Definition of Done geboren.
In der ersten Retrospektive hat unser Coach nur gefragt, wie es dem Team in der ersten Woche ging und als Hilfsmittel vier Smileys an einen Schrank gemalt, auf denen jeder seine Stimmung markieren konnte. Danach wurde darüber gesprochen, was nötig ist, um die Stimmung zu verbessern.
Im zweiten Sprint übernahm der Mensch im Team, der sich dem Produkt in einem ganz besonderen Maße verbunden fühlte, die Rolle des Product Owners und auch eine Scrum Masterin erklärte sich bereit, damit zu beginnen, auf die zeitliche Begrenzung der täglichen Abstimmungsrunde zu achten.
Am Ende des dritten Sprints wurde bereits eine erste Platine im Review vorgestellt, ein Ticketsystem zur Backlogverwaltung genutzt und erste konkrete Absprachen für die Bestellung von weiteren Materialien unter Beachtung der Kostenstruktur getroffen.
Nach vier Sprints wurde die Sprintlänge auf zwei Wochen erhöht, um noch fokussierter arbeiten zu können und z.B. die Testaufbauten besser zu nutzen und erkannte Fehler im laufenden Sprint beheben zu können.
In der Retrospektive des fünften Sprints stellte unser Coach die Frage, wie das Team weiter arbeiten möchten. Die Antwort war eindeutig: “Wir möchten so weiter arbeiten und auf keinen Fall dahin zurück, wie es vorher war.”
Das Team hatte Selbstvertrauen gewonnen, seine Selbstwirksamkeit zurückgefunden und erkannt, dass sie nur gemeinsam das Produkt erfolgreich entwickeln können.
Nach drei Monaten zog sich unser Coach aus dem Team zurück in dem vollen Vertrauen, dass Transparenz, Überprüfung und Anpassung gelebt werden und sich das Team kontinuierlich weiterentwickeln wird.