Teamstruktur durch skalierte Agilität verbessern

Was sich am einfachsten ändern lässt: Sie selbst!

Ulf Schneider

© IStockphoto.com / danleap

Wir sprechen von skalierter Agilität, sofern mehrere agil arbeitende Teams an einem Vorhaben beteiligt sind. Dieser Text beleuchtet einige der damit verbundenen Fragestellungen und macht Vorschläge zur Unterstützung erfolgreicher Skalierung.

Ein Team ist mehr als eine Gruppe. Es ist gekennzeichnet durch seine Leistungsfähigkeit. Nicht ohne Grund wird die Hochphase der Teamentwicklung im Modell von Tuckmann als Performancephase bezeichnet. Leistet ein Team nichts oder nur wenig, haben wir es vielleicht nur mit einer Gruppe von Menschen zu tun, die täglich dieselbe Kaffeemaschine benutzen und Smalltalk pflegen. Die Organisationsfähigkeit eines Teams zur Erreichung gemeinsam getragener Ziele, das Ablaufenlassen der nötigen Verhandlungsprozesse, das Treffen und Einhalten von Entscheidungen, das Erreichen von Resultaten, all das sind Voraussetzungen für effizientes, teamorientiertes Arbeiten. Derartiges Verhalten führt zur spezifischen Identität des Teams, die weder durch Vorgesetzte angeordnet noch durch Geld gekauft werden kann. Das Team entscheidet selbst, ob es ein Team ist [1].

Dreh- und Angelpunkt für agile Vorhaben, egal wie umfangreich, ist das Team. Gemeint ist das interdisziplinär besetzte Team mit weniger als zehn Mitgliedern. Es ist mit möglichst geringen Abhängigkeiten zu anderen Teams durch Selbstorganisation in der Lage, regelmäßige und in kurzen Abständen funktionsfähige Produkterweiterungen zu erstellen, zu testen und in einer definierten Umgebung ablaufen zu lassen. Dieser iterative Arbeitsansatz ist besonders geeignet zum Erbringen von Ergebnissen in komplexen Umfeldern, in denen Anpassung und Lernen aller Beteiligten absolut notwendig sind und in denen detaillierte Aprioriplanungen viel kosten und wenig nutzen [2].

Anpassen oder sterben

Jede Organisation muss dem Gesetz des Lebens folgen und sich im Laufe der Zeit an veränderte Bedingungen anpassen – oder sterben. Agilität unterstützt Anpassungsfähigkeit in komplexen Umfeldern. Je wichtiger Lernen und Anpassen in Ihrem Umfeld sind, umso mehr kann agiles Arbeiten Ihre Organisation unterstützen.

Agilität erweitert den Teamgedanken um die iterative Lieferung von Produkterweiterungen. Wenn sie schnell sein wollen, dürfen Teams nicht auf andere Teams warten. Entscheidungen innerhalb der Teams müssen zu Resultaten führen. Teams müssen interdisziplinär und lösungsorientiert besetzt sein, sodass die Teammitglieder mit ihrer Arbeit verbunden sind, nach Meisterschaft streben können und in der Lage sind, sich selbst und ihre Ergebnisse zu hinterfragen und zu verbessern. Für mich hat Agilität mit Sinn, Freude am Schaffen und Potenzialentwicklung zu tun. Das lässt sich nicht mit routiniertem Wohlverhalten und dem Vermeiden von Fehlern erreichen. Vielmehr geht es um das Suchen von Erfolg, die Kunst des Machbaren und die Herausforderung des Status quo [3], [4]. Ist es ein Ziel der Organisation, mit agilen Teams zu operieren, sich Randbedingungen zu setzen, die genau diese beiden Aspekte stärken: selbstorganisierte Teams und wiederkehrende Lieferung von Ergebnissen in kurzen Zeitabständen.

Lesen Sie auch: Groß und (Fr)agil: Lassen sich Retrospektiven skalieren?

An Entwicklungsteams wird die Forderung der regelmäßigen Lieferung funktionierender Lösungen leicht gestellt, manchmal fast schon zu selbstverständlich. Haben Sie als Führungskraft ein entsprechendes Verhalten eigentlich auch schon für sich selbst im Kontext des Managementteams formuliert und umgesetzt? In welchen Zeitabständen räumen Sie organisatorische Hemmnisse aus dem Weg? Die Führungskräfte sind dafür verantwortlich, wie die Organisation als Ganzes funktioniert. Also auch, wie skalierte Agilität funktioniert.

Erfolg: Beginnen Sie vorne. Erarbeiten Sie für Ihren wettbewerblichen und organisatorischen Kontext Antworten auf die Fragen: Was bedeutet Erfolg für uns? Wann wissen wir, dass wir Erfolg haben? Können wir Schritte auf dem Weg zum Erfolg messbar machen? Involvieren Sie die gesamte Organisation und kommunizieren Sie die Ergebnisse. Können Sie eine Verbindung zwischen Ihrer Erfolgsdefinition und agilem Arbeiten herleiten? Wenn ja, kann das die Energie in Ihrer Organisation freisetzen, die es braucht, um mit Ihrer agilen Transformation erfolgreich zu sein.

Führen: Mir ist kein skaliert-agiles Vorhaben bekannt, das ohne aktives Zutun der Führungskräfte erfolgreich war. Wenn Sie als Führungskraft nicht überzeugt sind, wenn Sie nicht in die Richtung agilen Arbeitens führen, scheitern Sie. Wenn Sie selbst nicht teamorientiert arbeiten und regelmäßig Ergebnisse liefern, scheitern Sie. Auch ein Schaffen von Freiräumen für die Entwicklungsteams ohne zugehörige Führung genügt nicht. Es entsteht lediglich ein Vakuum, das beliebig ausgefüllt wird. Die zentrale Aufgabe von Führungskräften in agilen Organisationen ist, Randbedingungen zu schaffen, die den Selbstorganisationskräften eine Richtung geben. Sehr vereinfacht gesagt: Sprechen Sie mehr über das Was und weniger über das Wie. Das macht die Richtung der Selbstorganisation klar und gibt gleichzeitig den nötigen Freiraum dazu.

Transition: Verfolgen Sie diesen einfachen Ansatz [5]: Beginnen Sie mit einem einzelnen Entwicklungsteam und arbeiten Sie so lange, bis dieses Team verlässlich in jeder Iteration eine qualitätsgesicherte Produkterweiterung erzeugt, die in einer definierten Umgebung abläuft. Unterstützen Sie das gesamte Vorhaben durch ein Transitionsteam. Dieses ist für die Anpassung der umgebenden Organisation verantwortlich. Es ist mit Menschen besetzt, die in der Lage sind, die Organisation zu ändern und Probleme zu lösen, die nicht durch das Entwicklungsteam gelöst werden können. So wie das Entwicklungsteam eine priorisierte Liste mit erledigten und zu erledigenden Arbeiten pflegt, so pflegt das Transitionsteam eine Liste für Organisationsanpassungen. Beide Listen sind für alle Beteiligten offen einzusehen. Nutzen Sie die Hinweise des Entwicklungsteams. Sofern das Entwicklungsteam nicht in der Lage ist, in regelmäßigen Abständen Ergebnisse zu liefern, analysieren Sie die Gründe dafür. Liegen die Hemmnisse in der umgebenden Organisation, haben Sie genau die Arbeit identifiziert, die durch das Transitionsteam zu leisten ist.

Wenn Sie mit einem Team erfolgreich sind, skalieren Sie Schritt für Schritt nach dem Bedarf Ihres Vorhabens um weitere Teams. Bauen Sie auf den Lerneffekten der bereits erfolgreichen Teams auf. Beachten Sie die Randbedingung: Jedes Team sollte in der Lage sein, Verantwortung für die erzielten Ergebnisse zu übernehmen. Dazu sind Abhängigkeiten zwischen Teams zu minimieren.

Möglicherweise sehen Sie die Notwendigkeit, sofort mit mehr als einem Team zu beginnen. Das ist zwar möglich, aber schwieriger. Meiner Ansicht nach erspart Ihnen auch keines der einschlägigen agilen Scaling Frameworks, wie zum Beispiel SAFe, den oben beschriebenen Prozess der aktiven Organisationsgestaltung durch ein Transitionsteam. Ich gehe so weit zu behaupten, dass ein agiles Scaling Framework ohne Transitionsteam und ohne lernendes Management nur Dekoration ist. Sehen Sie sich die ScALeD Principles an, die meiner Meinung nach eine gute Hilfestellung zur Skalierung Ihres Vorhabens bieten.

Positive Abweichung: Versuchen Sie positive Lösungsmuster, die an einer Stelle bereits funktionieren, zu erkennen und in Bereiche zu übertragen, in denen für ähnliche Probleme bisher nur schlechte oder keine Lösungen gefunden wurden [6]. Sie müssen nicht alles auf den Kopf stellen. Die Evolution fing auch nicht jedes Mal von vorne an. Bauen Sie auf dem auf, was funktioniert.

Aufgaben klar machen: Ein Team kann selbstorganisiert nur etwas erreichen, wenn das zu lösende Problem oder das zu erreichende Ziel klar ist. Sind Sie sicher, das richtige Ziel zu verfolgen? Wenn ja, ist das Ziel für alle Beteiligten klar? Ohne diese Ausrichtung erhält auch die Selbstorganisation keine Richtung. Sind Sie in der Lage, das Ziel in priorisierte Zwischenschritte herunterzubrechen, für jedes Team, für jede Iteration, in Form qualitätsgesicherter Produkterweiterungen?

Kurze Releases: Eine große Hilfe zum positiven Umgang mit allen zuvor genannten Punkten ist die Verkürzung der Releasezyklen auf drei oder vier Monate und die Unterteilung dieser Releases in zwei- bis dreiwöchige Iterationen.

  • Legen Sie vor jedem Release ein Release Goal schriftlich fest. Das Release Goal ist nicht länger als eine halbe Seite.
  • Legen Sie den Iterationsplan und die Termine für Abstimmungen, Ergebnisprüfungen und Retrospektiven fest.
  • Erarbeiten Sie gemeinsam mit allen Mitgliedern ihres Vorhabens innerhalb der ersten Iteration Anforderungsskizzen für die Funktionen, die in dem Release geliefert werden sollen. Jeff Pattons User Story Mapping [7] ist ein ideales Verfahren, um den Zusammenhang des Releases herauszuarbeiten und Funktionskandidaten zu identifizieren, die Sie weiter vertiefen möchten. Halten Sie nicht funktionale Anforderungen fest und identifizieren Sie die Bereiche, in denen Architekturentscheidungen getroffen werden müssen. Unterlassen Sie die Analyse und Vorbereitung von Anforderungen, die nicht Bestandteil des Release Goals sind.
  • Liefern Sie immer die wichtigsten Dinge zuerst. Verschieben Sie nicht den Releasetermin, sondern streichen Sie die unwichtigeren Funktionen, falls die Zeit nicht reicht.

Die Kürze des Releases vereinfacht vieles: Die Zeitknappheit führt zu größerer Klarheit sowohl für die Priorisierung als auch für die Aufbereitung der Aufgaben, da zwangsläufig weniger Dinge erledigt werden können. Das kurze Release ist ein Container, der Selbstorganisation und Zusammenarbeit erzwingt. Gleichzeit ist die Planung des kürzeren Zeitraums deutlich einfacher.

Lesen Sie auch: Die Scrum-Revolution – Projektmanagement im Wandel

Fakten sichtbar machen: Machen Sie Fakten für alle sichtbar. Dazu gehört, den Fortschritt Ihres Vorhabens nicht mit einem Verbrauchsmaß zu messen, z. B. verbrauchtem Aufwand. Nutzen Sie ein Fortschrittsmaß, z. B. fertiggestellte Softwarefunktionen. Die Kunst besteht darin, mit Metriken zu arbeiten, die sich normierend auf individuelles und soziales Handeln auswirken. Dahinter steht erneut die Frage, wie in der Organisation Erfolg definiert ist und wie der Fortschritt auf dem Weg zum Erfolg sichtbar gemacht wird. Die OLUPCAT-Merkmale, die durch agile Metriken erfüllt sein sollten, geben eine Orientierung:

On demand: Es wird erst gemessen, wenn der Bedarf für die Messung klar ist. Zum Beispiel, wenn ein Problem erkannt ist und der Weg zur Besserung gemessen werden soll. Oder, wenn man sich ein Ziel gesetzt hat und mit einer Metrik den Fortschritt oder Zielerreichungsgrad ermitteln will. Daten zu erheben, nur weil man es kann, bringt niemanden weiter.

  • Lightweight: Agile Metriken haben einen kleinen Fußabdruck. Sie sind methodisch einfach zu ermitteln und ohne hohen Aufwand im Rahmen der Arbeitsprozesse zu erheben – idealerweise automatisiert.
  • Understandable: Jeder in der Organisation versteht die Metrik und weiß, warum sie angewendet wird, also welches Ziel durch die Metrik unterstützt wird.
  • Periodic: Um kurze Rückkopplungsschleifen zu haben, wird kontinuierlich in kurzen Zeiträumen gemessen, z. B. in Arbeitstagen, Iterationen und Releases. Die Auswertung der Messung steht unmittelbar nach der Messung zur Verfügung.
  • Foster Collaboration: Agile Metriken unterstützen die Zusammenarbeit. Das bedeutet, es werden nicht Sachverhalte gemessen, die im direkten Einflussbereich einer Person liegen. Stattdessen misst man eine Ebene oberhalb, sodass Verhaltensanpassungen auf dem Wege der Zusammenarbeit stattfinden müssen. Dieses Vorgehen schützt vor lokaler Optimierung, die einer End-to-End-Optimierung möglicherweise entgegenstehen würde.
  • Accessible: Die Metrik wird nicht nur durch einen kleinen Kreis von Mitarbeitern ausgewertet, sondern alle betroffenen Mitarbeiter haben jederzeit Zugang zu den aktuellen Daten. Es gibt keine Reporting-Parallelwelt für das Management. Nur so kann sich die Lenkungsfunktion einer Metrik entfalten.
  • Trend-oriented: Wenn Metriken unser Verhalten beeinflussen und ändern, werden sich in der Umkehr auch die gemessenen Werte ändern. Die Entwicklungsrichtung und Geschwindigkeit dieser Änderung sind wichtiger als absolute Zahlen.

Ein Randnotiz dazu: Der Scrum Guide kennt keine Story Points. Fortschritt wird in fertiggestellten Product Backlog Items gemessen. Ein Item muss in einem Sprint lieferbar sein. Komplizierte Story-Point-Kalkulationen und Velocity-Paraden sind in diesem Framework nicht vorgesehen. Story Points können hilfreich sein, sie sind aber kein Selbstzweck. Im Mittelpunkt steht immer noch, fertige Software in jeder Iteration zu erzeugen.

Lesen Sie auch: 6 Agile-Tools im Vergleich: Agilo for Scrum – ZenHub – Active Collab – ScrumDo – JIRA – Pivotal Tracker

Fazit

Auch wenn hier besonders Fragestellungen behandelt werden, die den Umgang mit Größe handhabbar machen sollen ‑ die beste Skalierung ist so klein wie möglich, weil Adaptions- und Lernprozesse schneller ablaufen, je kleiner die Organisation ist. Und vergessen Sie nicht: Der Teil eines sozialen Systems, der sich am einfachsten ändern lässt, sind Sie selbst!

Geschrieben von
Ulf Schneider
Ulf Schneider
Ulf Schneider ist Agile Coach bei Wincor Nixdorf und arbeitet gemeinsam mit seinen Kollegen an der Transition der weltweit operierenden Softwareproduktentwicklung hin zur kontinuierlichen Lieferung von Produkterweiterungen. Er teilt seine Gedanken zu agilen Arbeitsweisen auf http://www.ulf.codes.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: