Die agile Arbeit innerhalb eines Teams ist gut verstanden; es gibt ein gemeinsames Verständnis, wie sie organisiert werden kann und wie man ein Team ins agile Arbeiten bringt.
Software-/Produktentwicklung ist heute aber kaum noch mit nur einem Team zu stemmen. Wie mehrere Teams gemeinsam agil entwickeln, ist viel schlechter verstanden. Es gibt zwar eine Reihe von Skalierungsframeworks, die für sich in Anspruch nehmen, das Problem zu lösen. Dass die Anwendung dieser Frameworks häufig unreflektiert passiert, einfach Blaupausen kopiert werden und am Ende die Erfolge ausbleiben, zeigt aber deutlich, dass das gemeinsame Verständnis dann doch fehlt.
Wir machen seit über 10 Jahren gute Erfahrungen mit dem Agile Descaling Cycle (früher Agile Scaling Cycle). Er besteht aus nur zwei Schritten, die zyklisch wiederholt werden.
- Strukturen nach Wertschöpfung bilden
- Koordinieren
Wenn man diesen Zyklus kontinuierlich durchläuft, kann man eine immer leichtgewichtigere, flexiblere Struktur und Koordination finden: „to descale“ bedeutet „entkalken“ und darum geht es ja am Ende.
Strukturen nach Wertschöpfung
Wir suchen zuerst nach (Team-)Strukturen, die an der Wertschöpfung ausgerichtet sind. Eine Aufteilung in Frontend- und Backend-Team erfüllt dieses Kriterium ebensowenig wie eine Aufteilung in ein Team aus Business-Analysten, eins aus Programmierern und eins aus Testern.
Mehrere Teams zu bilden, die jeweils kundensichtbare Funktionalität Ende-Zu-Ende verantworten, kommt der Wertschöpfung deutlich näher.
Aus der Praxis wissen wir, dass man in diesem Schritt oft nicht so weit kommt, wie es plausibel wäre. Manchmal steht Politik im Weg, manchmal unternehmensinterne Regelungen, manchmal irgendetwas Anderes. Irgendwann gilt es, diese Beschränkungen für den Moment anzuerkennen und mit der Arbeit zu beginnen. Diese erfordert dann die Koordination der Teams und wir kommen zum zweiten Schritt des Agile Descaling Cycle.
Koordinieren
Egal, wie pfiffig unsere Teamstruktur ist, es werden Abhängigkeiten zwischen den Teams übrig bleiben. Diese müssen natürlich geeignet koordiniert werden – natürlich so leichtgewichtig wie möglich.
Insbesondere achten wir bei der Koordination darauf, welche Hindernisse für Wertschöpfung sichtbar werden. Wo stockt Arbeit oder bleibt komplett liegen? Wo entstehen Missverständnisse? Wo wird Ticket-Ping-Pong gespielt? etc.
Diese Hindernisse sind der Treiber für die Weiterentwicklung der Team-Organisation. Sie können dazu führen, dass es neue Erkenntnisse dazu gibt, wie Teams besser nach der Wertschöpfung ausgerichtet werden können.
Der nächste Zyklus
Mit den aufgedeckten Hindernissen gehen wir wieder zum ersten Schritt des Agile Descaling Cycle und überarbeiten die Strukturen. Häufig wird man feststellen, dass jetzt Änderungen an den Strukturen möglich werden, die vorher unrealistisch erschienen. Schließlich haben wir jetzt ein belegbares Problem in der Wertschöpfung!
Und wenn wir die Struktur verbessert haben, sollten wir in der Folge mit weniger oder leichtgewichtigeren Koordinationstechniken auskommen. Wir haben einen ersten Entkalkungsvorgang abgeschlossen.
Und dann beginnt das ganze Spiel von vorne.
Agile (De)Scaling Maturity Model
Daraus ergibt sich das Reifegrad-Modell für agile Skalierung:
die Menge an Koordinationstechniken, die man nicht (mehr) braucht
Das ist natürlich nicht wirklich als Reifegradmodell gedacht. Es macht aber die Denkrichtung klar.
Vertiefung
Ich habe das Modell und die vielen weiteren Überlegungen zu den beiden Schritten inkl. neuer fluider Teamkonzepte wie Mission Teams und Floating Teams in einem Buch beschrieben: „Innovative agile Teamkonzepte“
Es gibt außerdem ein kürzeres Whitepaper und Steckbriefe zu den fluiden Teams hier zum Download.
Über den Autoren
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.