Haltung #1 - Agile Teams

Viel wichtiger als Methoden ist die Einstellung mit der wir unsere Arbeit verrichten. In der Reihe Haltung schreibe ich über wesentliche Aspekte dieser agilen Haltung.

So ganz einfach ist diese Frage nicht zu beantworten. Vermutlich gibt es auch gar keine generell gültige und vollständige Sammlung von Kriterien, die ein agiles Team beschreibt. Das Agile Manifest ist dabei mit seinen 12 Prinzipien ebenfalls nicht sehr aussagekräftig. Dort heißt es lediglich:

“Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams”

und

“In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an”.

Näher erklärt wird beides aber nicht.

Anstatt eine finale und perfekte Definition für agile Teams zu konstruieren, versuche ich hier und heute lieber ein paar ganz wesentliche Grundlagen zu beschreiben ohne die ein Team vermutlich nur sehr schwer agil arbeiten kann.

Der Scrum Guide, der immerhin ein sehr bekanntes und erfolgreiches agiles Framework zur Bearbeitung von Projekten mit agilen Teams beschreibt, sagt, dass das Entwickler Team zwischen drei und neun Mitglieder umfassen sollte. Kleineren Teams würden vermutlich wesentliche Qualifikationen fehlen und bei größeren Teams sei die Zusammenarbeit im Team zu komplex.

Jeff Bezos (dem Gründer von Amazon) wird die Regel zugeschrieben, funktionierende Teams sollten maximal so groß sein, dass sie von zwei Familien-Pizzen satt werden. Je nach Größe der Pizza und Hunger der Teammitglieder ist damit klar, dass eine Mitgliederanzahl kleiner als zehn sinnvoll ist. So ganz falsch scheint das nicht zu sein, denn Amazon ist immerhin recht erfolgreich.

In einem Blog-Artikel, den ich neulich las, wird diese Zwei-Pizza-Regel zum Anlass genommen, sehr schön zu beschreiben, wie die Komplexität der Zusammenarbeit von Menschen in einer Gruppe mit deren Größe exponentiell zunimmt. Ein Kollege erzählt in seinen Trainings gerne eine Geschichte dazu:

Freunde von ihm hätten ein Kind bekommen und so wurde aus der einen Verbindung zwischen den beiden Eltern, drei Verbindungen zwischen den Eltern und dem Kind. Das ließ sich gut handhaben. Als dann aber etwas später Zwillinge dazu kamen wurden es zehn Verbindungen und als die kleinen anfingen zu krabbeln mussten die Eltern von “Manndeckung” auf “Raumdeckung” umsteigen. 

Wir wissen also schon einmal, das agile Teams möglichst kleiner als zehn Personen sein sollten, um gut funktionieren zu können. Aber reicht das schon?

Wenn ich mich so umsehe, dann funktionieren ganz viele Teams gar nicht als Gruppe, sondern eher als eine Sammlung von Silos, die jedes für sich ihre individuellen Aufgaben lösen und eher zufällig an eine gemeinsame Führungskraft berichten. Das passt bestimmt nicht besonders gut, zu selbstorganisiertem Arbeiten, wie es im agilen Manifest beschrieben ist. In einem Meetup habe ich das agile Reifegradmodell von Judith Andresen kennengelernt. In diesem Modell werden vier Stufen beschrieben, die Teams und Organisationen auf dem Weg zur vollständig agilen Organisation durchlaufen.

Ich möchte heute ja nur auf die Grundlagen eingehen, daher betrachte ich nur die erste Stufe des Modells. Sie beschreibt was Teams als erste Stufe auf dem Weg zum agilen Arbeiten anstreben sollten:

Das ist sicher auch bei nicht agilen Teams sehr hilfreich und nicht sehr neu.

Damit ist gemeint, dass die oben beschriebenen Silos aufgelöst werden. Alle Aufgaben im Team werden als Aufgabe für das Team als Gruppe verstanden. Es ist nicht im Vorwege festgelegt, wer aus dem Team, welche Aufgabe erledigt. Das setzt natürlich voraus, dass die Teammitglieder auch dazu in der Lage sind, diese Aufgaben zu übernehmen.

Eine relativ einfache Möglichkeit sich gegenseitig zu unterrichten, ist es Aufgaben im Duo zu erledigen. In der Software-Entwicklung nennt man so ein Vorgehen Pair-Programming.

Dazu ist es wichtig Lernmomente zu schaffen. Also Momente, in denen sich alle austauschen können. Ein solcher Moment kann das im letzten Beitrag beschriebene Daily-Stand-Up Meeting sein. Eine Reihe weiterer sehr guter Lernmomente können Retrospektiven schaffen. Das sind Termine mit allen Teammitgliedern, in denen die Zusammenarbeit im Team reflektiert und Maßnahmen zu deren Optimierung erarbeitet werden.

Es ist sinnvoll, diese Retrospektiven in eher kürzeren Abständen durchzuführen. Im Scrum Guide wird eine Retrospektive am Ende eines jeden Sprints vorgesehen. Sprints sind ein- bis vierwöchige Iterationen. Für Teams die nicht nach Scrum arbeiten, könnten monatliche Retrospektiven eine gute Idee sein.

Der Weg zu einem echten Team ist nicht immer ganz einfach. Insbesondere, wenn neue Mitglieder in das Team kommen oder sich das Ziel des Teams ändert, kann das durchaus spannend werden. In der nächsten Ausgabe helfe ich Dir zu verstehen, was da geschieht.

Wenn Dir mein Blog gefällt, teile den Artikel gerne mit Deinen Kontakten! Hast Du eine Frage, Anregung oder Ergänzung, dann nutze die Kommentarfunktion hier im Blog.