Agile Teams: Definition und Führung

Ein agiles Team ist geprägt durch intensive Kommunikation und häufigen Austausch. Ein typisches Beispiel dafür sind tägliche Kurz-Meetings zum Stand der Arbeit, die beispielsweise nicht länger als 15 Minuten dauern dürfen. Das erlaubt es dem Team neue Informationen rasch allen zugänglich zu machen und darauf zu reagieren.

Teams sind immer zu einem gewissen Grad selbstorganisiert, sonst wären es keine Teams. In agilen Teams besteht eine extreme Selbstorganisation. Alle Einmischungen von außen und Abhängigkeiten sind auf ein Minimum reduziert. So kann das Team schnell und eigeninitiativ Probleme lösen und sich auf neue Situationen einstellen. Unter anderem zeigt sich diese Freiheit darin, dass die Führungskraft lediglich eine Art Coach für das Team ist. Ein Coach der Ergebnisse einfordert – aber nicht den Weg bestimmt. Die Führungskraft agiler Teams definiert Anforderungen an das Produkt und wirkt als Kontakt und Interessenvertreter zu (internen) Kunden und der Unternehmensführung. Sie mischt sich nicht in die Arbeitsorganisation des Teams ein.

Schnelle und optimierte Entscheidungsprozesse prägen agile Teams. Das erreichen sie durch mehrere Maßnahmen. Eine davon sind kompetente Teammitglieder mit selbständiger Arbeitsweise. Eine andere ist die oben genannte Autonomie mit minimaler Abhängigkeit bei Entscheidungen von außen. Dass es extra Personen im Team gibt, deren Rolle auf den Kontakt zum Kunden und anderen Stakeholdern zugeschnitten ist, führt zu einer schnellen Verfügbarkeit von wichtigen Informationen und damit schnelleren und besseren Entscheidungen. Auch institutionalisierte Zeitfenster mit Meetings (z.B. täglich 15 Minuten das ganze Team) fördern die Entscheidungsfähigkeit.

In agilen Teams besteht ein ausgesprochener Kundenfokus. Kunden sollten dabei breit verstanden sein. Es können externe Kunden und auch interne Gruppen sein, für die das Team arbeitet und Lösungen erstellt. Idealerweise bildet ein zentraler Botschafter im Team oder nahe am Team das Kundeninteresse ab. Zudem ist ein regelmäßiger Austausch mit Kunden, für die das agile Team arbeitet, entscheidend. Mindestens sollten Kunden in die Planung von Lösungen eingebunden sein und zu einzelnen Zwischenergebnissen zeitnah Informationen bekommen.

Handlungsfähige Mitglieder sind für jedes Team wichtig. Für agiles Arbeiten im Team sind sie allerdings fundamental. Ohne geht es nicht. Das agile Konzept scheitert komplett, wenn kompetente und selbständige Teammitglieder fehlen. Das betrifft einerseits die fachliche Kompetenz – besonders aber Teamkompetenzen wie Kommunikation. Konkret geht es darum, seine eigenen Ideen präsentieren zu können, Zuhören können, konstruktives Feedback beherrschen. Es gibt aufgrund dieser hohen Anforderungen Mitarbeiter, die vielleicht für ein normales, klassisches Team geeignet waren, die im agilen Team auf einmal komplett überfordert und absolut fehl am Platz sind. Der Personalauswahl und Personalentwicklung kommt also ein noch höherer Stellenwert zu, sobald ein Team agil sein soll.

Wie sieht eine agile Teamstruktur aus? Agil und Struktur – eine Kombination, die sich nahezu selbst widerspricht. Ein agiles Team hat daher keine starre, sondern eine flüssige Struktur. Das zeigt sich etwa darin, dass feste Rollenbezeichnungen im Arbeitsteam fehlen und Teammitglieder schnell neue und andere Aufgaben bekommen. Auch das erfordert natürlich extrem handlungsfähige und kompetente Personen im Team. Wir können also festhalten: Je agiler ein Team ist, desto weniger Struktur hat es in Form von fixen Rollen.

Schnelligkeit im Arbeiten erreichen agile Teams auch durch Proaktivität. Durch ihren intensiven Kontakt mit der Umwelt erkennen agile Arbeitsgruppen Chancen und Risiken frühzeitig, verstehen diese und reagieren intelligent darauf. Sie reagieren nicht erst, wenn der Kunde es fordert oder ein Problem direkt auf der Türschwelle steht. Sie kennen und berücksichtigten die Bedürfnisse des Kunden genau. Sie haben Teammitglieder, die sich stark darum kümmern, mögliche Hindernisse zu erkennen und aus dem Weg zu räumen.

Wie soll ein Team sich schnell anpassen, wenn es nicht schnell und fundiert lernt? Agile Arbeitsgruppen haben daher eine sehr steile Lernkurve. Input zum Lernen kommt aus den täglichen Erfahrungen bei der Umsetzung und von den Personen im Team, die intensiven Kontakt mit der Umwelt haben (Unternehmen und Kunden). Die Lernprozesse selbst finden dann in Situationen wie täglichen Meetings, Reviews nach abgeschlossen Projektschritten oder auch in Gesprächen einzelner Teammitglieder zu ihrer Zusammenarbeit statt. In agilen Teams ist der Fokus in Meetings immer auf die Zukunft und Verbesserung gelegt. Mit der Vergangenheit befasst man sich nur, um für die Zukunft zu lernen.

Ein Scrum Team hat folgende Rollen bzw. dieser Struktur:

• Ein Teammitglied hat die Rolle „Product Owner“. Der Product Owner übersetzt die Kundenwünsche in die Anforderungen an das Produkt bzw. die Lösung, die das Team erarbeitet. Er hat die Vision für das Produkt im Blick und stellt sicher, dass die Lösung maximalen Nutzen für die Kunden und das Unternehmen besitzt. Das fördert den Kundenfokus, der agile Teams kennzeichnet. Gleichzeitig ist er der Botschafter des Teams, seine Augen und Ohren nach außen. Diese Person kümmert sich um Kontakt mit den Kunden und anderen wichtigen Stakeholdern und vertritt das Team nach außen, etwa gegenüber dem Unternehmen.
• Ein anderes Teammitglied hat die Rolle „Scrum Master“. Es fokussiert sich komplett auf die Zusammenarbeit und Prozesse, ist in gewissem Sinne ein Coach für das Team. Es stellt sicher, dass alles rund läuft. Es informiert sich über den Stand und steht dem Team zur Seite. Es stellt (kritische) Fragen und fordert geeignete Ergebnisse. Niemals greift es autoritär ein, sagt dem Team, wie es etwas zu tun hat oder strukturiert den Prozess von außen. Damit ist die hohe Autonomie und Selbstorganisation agiler Teams berücksichtigt. Wenn etwas nicht funktioniert, merkt es diese Person schnell und reagiert. Etwa indem sie Hindernisse beseitigt oder ein Krisen-Meeting einberuft und Lösungen einfordert.
• Die normalen Teammitglieder, das „Development Team“. Es handelt sich um möglichst wenige hoch kompetente Personen, die zusammen alle kritischen Kompetenzen für das Projekt abdecken. Sie sind absolut selbstorganisiert und treffen ihre eigenen Entscheidungen nach eigenen Regeln. Vorgaben von außen sind lediglich: Es ist immer das gesamte Team für die Leistung jedes einzelnen Mitglieds verantwortlich. Es gibt keine speziellen Rollenbezeichnungen im Team und keine Bildung von Subgruppen. So erreichen Scrum Teams die flüssige Struktur und Handlungsfähigkeit, die agile Teams ausmacht.

Agile Arbeitsmethoden im Scrum Team sind:

• Der „Sprint“ ist eine Phase der Implementierung. Zweck eines Sprints ist bestimmte Ziele beim Produkt (Product Goals) fertigzustellen. Sprints haben idealerweise immer eine ähnliche Zeitdauer, um die Komplexität gering zu halten. Beispielsweise dauern sie in einem bestimmten Team immer einen Monat, in einem zweiten Team immer eine Woche oder bei manchen Teams auch nur einen Tag – ganz je nach Projektbedarf.
  Nehmen wir dieses Kapitel hier als Beispiel für ein Produkt. Ein Scrum Team soll genau dieses Kapitel erstellen. Product Goals dieses Kapitels sind dann die einzelnen Abschnitte zu erstellen – etwa diesen hier zum Scrum Team als Beispiel für ein agiles Team. Jedes Teammitglied könnte sich also einen zu erstellenden Abschnitt als Thema aussuchen. Ein Mitglied recherchiert und schreibt zu Führung agiler Teams, ein anderes zu Merkmalen Agiler Teams usw. Es kann mehrere Sprints dauern, bis eine Product Goal erreicht ist. So könnten die Teammitglieder ihren Abschnitt im ersten Sprint recherchieren und schreiben. In einem zweiten Sprint könnten wir die Abschnitte Probelesern geben, um auf Verständlichkeit, Fehler etc. zu testen, und den Text anhand des Feedbacks überarbeiten. In einem dritten Sprint würden wir die Abschnitte sinnvoll in ein Kapitel zusammenfügen, eine logische Reihenfolge herstellen, uns mit guten Übergängen befassen und inhaltliche Redundanzen entfernen.
• Das „Sprint Planning“ ist ein Meeting zur Planung eines Sprints. Hier geht es um die Definition dieser Ziele, der dafür notwendigen Zwischenschritte bzw. Meilensteine (Increments), der Zuständigkeiten und der Zeitfenster: Wer macht was mit wem bis wann? In agilen Teams ist wichtig, dass diese Planung nur kurz andauert. Bei Sprints mit einer Woche beträgt die Planungsdauer maximal einen Vormittag. Bei einem Sprint mit einem Tag maximal 30 Minuten. Damit erreichen Scrum Teams die für agile Teams typischen schnellen Entscheidungen und schnelles Implementieren.
• Der „Daily Scrum“ ist ein tägliches Kurz-Meeting von ca. 15 Minuten des Development Teams: Läuft alles nach Plan, haben wir etwas übersehen, ist ein Risiko oder eine Chance entstanden, gibt es Änderungsbedarf? Es findet idealerweise immer zur gleichen Zeit und am gleichen Ort statt, um den Abstimmungsaufwand gering zu halten. Ziel ist ein kurzer Überblick über den Stand des Projektes und vor allem die Planung des nächsten Tages. Der Fokus ist auf die Zukunft gerichtet, wie das Team seine Ziele gut erreichen kann. Diese agile Methode ersetzt alle anderen Meetings, dient zur Verbesserung der Kommunikation, schnellem Informationsaustausch und zu schnelleren Entscheidungen – alles Aspekte, die agile Teams definieren. Der Scrum Master stellt sicher, dass diese Meetings stattfinden und dass sie den Zeitrahmen nicht überschreiten.
• Im „Sprint Review“ stellt das Development Team die Ergebnisse eines Sprints dem Product Owner und den Stakeholdern (z.B. Kunden) vor. Diese agile Methode stellt Kundennähe sicher und lässt schnell erkennen, wenn man am Kunden vorbei arbeitet. Das Team kann so Änderungen und Anpassungen zeitnah einarbeiten, wenn sich die Situation beim Kunden geändert hat oder unerwartete Herausforderungen auftreten. Die Veranstaltung sollte dafür Workshop-Charakter haben. Bei einem Sprint von einer Woche sollte der Review nicht länger als zwei Stunden dauern, lieber nur eine.
• Die „Sprint Retrospective“ erreicht als agile Methode für das gesamte Team nach jedem Sprint einen maximalen Lerneffekt. Typische Fragestellungen, die das Team dabei beantwortet sind: 1.) Was ist gut gelaufen? 2.) Was hätte besser laufen können? 3.) Was optimieren wir beim nächsten Sprint anhand dieser Erfahrungen? Bei einem Sprint von einer Woche sollte dieser Rückblick nicht länger als eine Stunde dauern. Wenn alles gut gelaufen ist, dann gerne kürzer. Wenn es grobe Probleme gab, dann etwas länger.

Weitere Einrichtungen und Begriffe im Scrum Team sind:

• Das „Product Backlog“ ist der Kompass des Teams und spezifiziert die Ziele. Der Product Owner erstellt ihn in Abstimmung mit Kunden, Unternehmen und Team. Er bricht die Kundenbedürfnisse in ganz konkrete produktspezifische Anforderungen herunter, für die das Team eine Lösung entwickeln soll. Ein Beispiel: Das Team soll für eine Personalabteilung einen Workshop entwickeln, der Teamarbeit im Unternehmen verbessert. Der Product Backlog bricht dieses übergeordnete Ziel in konkrete Anforderungen mit Kundennutzen herunter. Konkrete Anforderungen im Product Backlog könnten also der Kompetenzerwerb der Teilnehmer am Workshop sein in den Feldern „Teamzusammenhalt stärken“, „Teamaufgaben motivierend gestalten“ oder „Teammitglieder entwickeln“. Das Development Team erarbeitet dann für diese einzelnen Positionen im Backlog jeweils eine Zielvorstellung (Product Goal), die diese konkreten Anforderungen erfüllt.
• Ein „Sprint Backlog“ enthält die einzelnen Zwischenziele (Increments), um zu einem Product Goal zu kommen. Das Development Team erstellt den Sprint Backlog. Die Increments sollten eine logische Folge haben, und zusammen harmonieren. Und natürlich sollten sie geeignet sein, um am Ende eine oder mehrere der Produktanforderungen zu erfüllen. Der Sprint Backlog ist geeignet für eine detaillierte tägliche Planung. Wer macht heute was mit wem bis wann? Idealerweise schafft er Transparenz über den Status von Increments: „to do“, „in progress“, „done“.
• „Increments“ sind die Zwischenschritte auf dem Weg zu einem Product Goal. Ein Beispiel: Wie lässt sich die Anforderung an einen Workshop Lösungen zum Thema „Teamzusammenhalt stärken“ in Increments übersetzen? Als erstes braucht es ein konkretes Product Goal. Das wäre in diesem Fall „Drei praktikable und wirksame Konzepte mit Übungen für die Workshopteilnehmer, um den Zusammenhalt in einem Team zu stärken“. Einzelne Increments könnten sein: „Teamgeist stärken durch das Feiern von Erfolgen“, „Teamgeist stärken durch die geeignete Auswahl der Teammitglieder“, „Teamgeist stärken durch das Vermeiden von Trittbrettfahrern und Konflikt“.