Nachdem ich in meinem letzten Blog-Beitrag einen Spike in die Basics des agilen Vorgehens unternommen habe, werde ich mich in diesem Beitrag auf agile Teams und damit auf die Menschen in der agilen Welt fokussieren.
Summary:
Agiles Arbeiten bringt Freiheit, stellt aber auch hohe Anforderungen an das Team und jeden Einzelnen.
Wer kein Engagement zeigt, Verantwortung übernimmt, Kritik akzeptiert und sich selbst reflektiert, fällt durch die Maschen der Agilität und gerät u. U. ins Abseits. Damit agile Zusammenarbeit gelingt und am Ende ein für den Kunden wertsteigerndes Ergebnis zu Tage gefördert werden kann, braucht es permanente Weiterentwicklung und Optimierung. Dies entpuppt sich vor allem beim Faktor Mensch als äusserst schwierig und herausfordernd.
(Agile) Teams als Grundpfeiler der Agilität
Agile Vorgehensmodelle wie Scrum und Kanban sind die eine Seite der Medaille. Sie liefern uns (mal mehr mal weniger) konkrete Anhaltspunkte zum Vorgehen und bilden damit das Rahmenwerk für die täglich Arbeit.
Doch was nützen all diese Frameworks mit ihren zugrundeliegenden Werten und Prinzipien wenn niemand diese versteht, anwenden und umsetzen kann?
Und hier kommt die zweite Seite der Medaille ins Spiel – Menschen, welche in Gruppen/Teams versuchen agile Modelle mit mehr oder weniger Erfolg anzuwenden.
Klassische Teams vs. Agile Teams
Was unterscheidet jedoch ein klassisches Team von einem agilen?
Grundsätzlich sind beides Gruppen von Menschen, die nach bestimmten Normen und Regeln kooperieren, um ein bestimmtes Ziel zu erreichen. Beide Arten von Teams können durchaus erfolgreich und effizient sein und benötigen dafür neben klaren Zielen, eine angemessene Führung, organisatorische Unterstützung, geeignete Aufgaben sowie Wertschätzung. Hier gibt es also keine Differenzierung. Der eigentliche Unterschied liegt in der Arbeitsweise, also dem WIE etwas getan wird.
Agile Teams zeichnen sich durch eine ausgeprägte Kollaboration in Kombination mit einer offenen, respektvollen Kommunikation auf Augenhöhe aus. Oft sind agile Teams nicht statisch zusammengesetzt, wie man es von klassischen Teams kennt, sondern werden je nach der zu lösender Aufgabestellung, mit Teammitgliedern ergänzt bzw. reduziert. Damit wird dem agilen Grundsatz, dass ein Team über das notwendige Wissen zur Lösung eines Problems verfügen soll, Rechnung getragen.
Der entscheidende Unterschied zwischen klassischen und agilem Team ist jedoch das selbst organisierte Handeln und das gemeinsame Entscheiden.
Die klassische Führungsrolle wie die eines Teamleiters o. ä. entfällt und wird durch eine verteilte Verantwortung auf das ganze Team übertragen.
Doch gerade diese Selbstorganisation wirft bei mir einige Fragen auf.
Wie in vielen Organisationen ist auch mein aktueller Arbeitgeber klassisch, hierarchisch organisiert.
Beginnend mit dem CEO an der Spitze, verästelt sich die Organisation auf Business-Units, Abteilungen und Teams, welche jeweils einen «Lead» vorangestellt haben. Dabei ist einzig die IT-Abteilung mit ihren 4 Teams nach agilen Prinzipien (Scrum) aufgestellt. Internen Versuche Teams ohne Teamleiter agieren und sich selbst organisieren zu lassen sind gescheitert (Hierzu mehr in meinem nächsten Blog-Beitrag). Was dazu geführt hat, dass jedes Scrum-Team einen Teamleiter besitzt, der die personelle Verantwortung für das Dev.-Team übernimmt.
Diese Art der Organisation ist aus meiner Sicht in der heutigen Zeit häufig anzutreffen und steht nicht zwangsläufig im Widerspruch zu den agilen Bestrebungen, was sich auch in einem Zitat von Boris Gloger widerspiegelt.
«…Selbstorganisation ohne Führung ist zum Scheitern verurteilt.»
Boris Gloger, 2017, S.4
Verlassen wir jedoch das Thema Führen in agilen Organisationen (ich bin schon sehr gespannt auf das CAS Modul Organizational Agility) und kommen zurück zu agilen Teams.
Wie die «Agilität» selber haben auch agile Teams die absolute Kundenorientierung, schnelle Entscheidungen, Innovation, optimale Technologieausnutzung und die Generierung von Business Value im Fokus.
Dr. Thomas Würzburger fasst dies aus meiner Sicht sehr prägnant zusammen:
«Der Zweck ist…: den Menschen möglichst leistungsfähig zu machen .»
Thomas Würzburger, Die Agilitätsfalle, 2019, S.21
Doch aus eigener «schmerzvoller» Erfahrung kann ich behaupten, dass dies einer der ersten Stolpersteine in der agilen Transformation ist. Denn wer glaubt mit der Einführung agiler Methoden wie Scrum oder Kanban, der Durchführung einer Mitarbeiterschulung mit Unterstützung eines Agile Coach schon am Ziel zu sein wird wohl schon nach kurzer Zeit eines Besseren belehrt.
An dieser Stelle kommt mir einer meiner letzten Workshops in den Sinn. In diesem hat der Agile Coach immer wieder betont wie wichtig die Lieferung von Business Value ist. Leider hat er vergessen zu erwähnen was notwendig ist, um konsequenten Kunden-/Geschäftswert zu generieren. Denn die Rahmenbedingungen und das im Agilitätskontext häufig anzutreffende Buzz-Word «Mindset» sind matchentscheidend. Sind diese nicht gegeben sind agile Bestrebungen kaum möglich.
Ein Team das (Höchst)Leistung erbringen soll sich dabei selbst organisiert, gemeinsam entscheidet und dabei maximal kundenorientiert ist braucht aus meiner Sicht vor allem zwei Dinge:
Motivation und den Willen sich permanent weiterzuentwickeln.
Team-Motivation:
Team-Leistung bedingt Motivation jedes Einzelnen.
Doch wie entsteht Motivation?
Diese Frage stelle ich mir in meiner Rolle fast täglich. Denn als Teamleiter ist es einer meiner Hauptaufgaben mein Team zu motivieren, es zu unterstützen, zu ermutigen und bei Fehlern in Schutz zu nehmen. Doch gerade das Motivieren eines ganzen Teams als Einheit zu funktionieren, Entscheidungen selbstständig zu treffen und effizient zu handeln scheint an manchen Tagen ein aussichtsloser Kampf.
Jeder Mensch (oder Teammitglied) hat eigene Wünsche, Ziele, Stärken und Schwächen. Werden diese nicht berücksichtigt sinkt die Motivation und damit die Leistungsbereitschaft.
Letztendlich heisst das Battle:
Eigene Ziele vs. Übergeordnete Ziele oder Motivation vs. Business Value
Leistungsbereitschaft oder Agilität im Allgemeinen können nicht erzwungen oder antrainiert werden. Ebenso wenig kann Motivation eingefordert oder erkauft werden. Was hinzukommt und ich immer wieder im Alltag feststelle ist, dass einige Menschen schlichtweg mit Agilität überfordert sind und versuchen sich in ihre Komfortzone zurückzuziehen. Sie wollen gar nicht die Freiheit Entscheidungen zu treffen, Neues zu probieren oder gewohnte Prozesse und Strukturen verlassen. Was sie wollen ist eine klare Aufgabe, (k)einen Termin und ihre Ruhe.
Somit stellt sich die Frage:
Fallen diese Menschen durch die Maschen der Agilität oder können auch sie weiterentwickelt werden, um mit der Agilität Schritt zu halten?
(Weiter)Entwicklung des agilen Teams:
Weiterentwicklung bedeutet Lernen und Adaptieren. Dies wiederum bedeutet Fehler zu machen, Kritik entgegenzunehmen und zu reflektieren um daraus wiederum zu lernen und zu verbessern. Es handelt sich hier also um ein iteratives-inkrementelles Vorgehen, was ein wesentliches Merkmal agiler Ansätze darstellt. Im Kontext der agilen Teamentwicklung taucht schnell der Begriff «Retrospektive» auf.
Ziel einer Retrospektive ist die kontinuierliche Optimierung der Teamzusammenarbeit, um bessere Ergebnisse zu liefern. An dieser Stelle sei kurz auf den letzten Punkt der 12 Prinzipien zum Manifesto for Agile Software Development verwiesen.
«At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.»
https://agilemanifesto.org/principles.html
Im Gegensatz zu einem Review (im Scrum das sogenannte Sprint-Review) bei dem es um die Klärung der Frage: «Tuen wir das Richtige?» geht und damit der inhaltliche Aspekt im Vordergrund steht, beschäftigt sich die Retrospektive mit der Frage: «Wie tuen wir es richtig?». Hier rückt also die Arbeitsweise und Zusammenarbeit im Team in den Fokus.
Betrachtet man ein Team als System, so kann die Retrospektive als Regelkreis verstanden werden.
Vereinfacht ausgedrückt wiederholen sich in einem Regelkreis (vgl. https://de.wikipedia.org/wiki/Regelkreis) folgende drei Schritte:
- Handlung: eine Interaktion des Systems
- Reaktion: Beobachtung des Systems
- Analysieren: aus dem Verhalten des Systems lernen
Übertragen auf die Teamarbeit heisst dies also, dass die Zusammenarbeit eines Teams zur Lösung eines Problems als Interaktion aufgefasst werden kann. Diese Interaktionen werden von den einzelnen Teammitgliedern wahrgenommen und beobachtet. Die Beobachtungen werden in zyklischen Abständen z. B. nach Abschluss eines Sprints (alle 2-4 Wochen) analysiert, um Störfaktoren zu identifizieren und zu beheben. Damit entsteht ein System aus Rückkopplung und Kalibrierung, welches sich an vielen Orten in der agilen Welt wiederfinden lässt.
Bei technischen Systemen scheint die Anwendung eines Regelkreises recht simpel. Übertragen auf die menschliche Zusammenarbeit ist dies jedoch eine der grössten (aus meiner Sicht sogar die grösste) Herausforderungen in der agilen Bestrebung.
Denn das System «agiles Team» besitzt eine Vielzahl von Stellschrauben wie Motivation, Verantwortungsübernahme, Umsetzungskompetenz, Kommunikationsfähigkeit und viele mehr, welche es zu justieren gilt. Hinzukommt, dass ein Team ein Sub-System eines grösseren Systems (Organisation) ist und dieses übergeordnete System ebenso viel «Stellschrauben» zur Kalibrierung besitzt.
Die Challenge in der Agilität ist demnach der Mensch.