Wie die Arbeit in der Praxis aussieht

Ein skaliertes Programm lief am Ende jedes Increments gegen dieselbe Wand. Die Teams planten nach bestem Wissen und committeten sich auf ihre eigenen Backlogs. Sie stießen dann zusammen, sobald die einzelnen Teile bei der Integration aufeinandertrafen. Ein Signal, das ein Team für stabil gehalten hatte, hatte sich verändert. Eine Schnittstelle, die zwei Teams für gemeinsam hielten, bedeutete auf jeder Seite etwas anderes. Die Retrospektiven nannten das immer wieder ein Kommunikationsproblem und verordneten noch mehr Meetings, doch diese zusätzlichen Meetings änderten sehr wenig. Die tiefere Ursache lag im Planungsprozess selbst. Nichts in diesem Prozess zwang die Teams, ihre Grenzen vor Arbeitsbeginn schriftlich festzuhalten und zu vereinbaren.

Ich übernahm eine Disziplin aus einem Bereich, in dem sie bereits zuverlässig funktionierte. In der AUTOSAR-Entwicklung einigen sich Softwarekomponenten zuerst auf einen Schnittstellenvertrag und entwickeln dann dagegen, eine Gewohnheit, die ihr Zusammenspiel vorhersagbar hält. Dieselbe Idee zog ich eine Ebene höher und wandte sie auf ganze Teams an. Jedes Team behandelte den Arbeitsbereich, den es verantwortete, wie eine exportierte Schnittstelle. Es benannte, worauf andere Teams angewiesen waren, und versionierte diese Punkte. Es sagte außerdem klar, welche Teile zugesichert und welche noch im Fluss waren. Das Mapping der Abhängigkeiten wanderte so aus dem Nebengespräch in die Mitte der Planung. Der Vertrag zwischen den Teams wurde zur Einheit, die jede Teamgrenze überschritt.

Ein Ingenieur war vor Kurzem in eine Koordinationsrolle auf Train-Ebene gewechselt. Das Framework beschreibt diese Rolle in einem einzigen Absatz. Das echte Arbeitsleben beschreibt sie über ein ganzes Jahr. Die Zertifizierung war vorhanden, und jede Zeremonie der Kadenz saß auswendig. Schwieriger war es, die Signale zu lesen, die niemand je aufschreibt. Ein Beispiel ist der Moment, in dem eine kleine Abhängigkeit zu einem ernsten Problem heranzuwachsen beginnt. Ein anderes ist die Art, wie ein sorgfältig formuliertes Status-Update in Wahrheit eine Bitte um Unterstützung ist. Er konnte spüren, wie viel Autorität die Rolle trug, verglichen mit dem, was der Titel zu versprechen schien. Er folgte dem Playbook genau und hatte trotzdem das Gefühl, einen Kalender zu verwalten, obwohl er ein Programm führen wollte.

Wir trafen uns nach einem festen Rhythmus, und die Agenda war immer das, was in der jeweiligen Woche gerade aktuell war. Das konnte eine echte Entscheidung sein, vor der er stand, oder ein Gespräch, das schiefgelaufen war. Es konnte auch ein Risiko sein, das er spüren konnte, ohne es schon benennen zu können. Er verstand das Framework bereits gründlich, also verbrachten wir die Zeit mit der konkreten Wirklichkeit der Aufgabe. Wir übten, eine Abhängigkeit so anzusprechen, dass sie nach gemeinsamem Problemlösen klingt. Wir übten zu eskalieren, sodass die Leute bereitwillig mitkommen. Wir erarbeiteten, wann man ein Problem selbst auffängt und wann das Zurückgeben die verantwortliche Entscheidung ist. Über mehrere Monate verschob sich das Ziel vom korrekten Ausführen der Rolle hin zu echtem Urteilsvermögen.

Eine Engineering-Organisation steckte mitten in der Einführung von Scaled Agile. Sie behandelte das gesamte Vorhaben als Prozess-Rollout. Das hieß, die Leute zu schulen, die Zeremonien zu installieren, die Kadenz zu fahren und zu erwarten, dass der Nutzen folgt. Auf dem Papier sah die Einführung bequem im Plan aus. In der Praxis war die Reibung in jeder Session zu spüren. Das Framework wurde Wort für Wort auf einen sicherheitskritischen Kontext angewandt, für den es nie geschrieben worden war. Safety-Cases, mehrjährige Plattform-Commitments und ein großes Lieferanten-Ökosystem beugen sich keiner Kadenz, die für Web-Skala-Software entworfen wurde. Das Führungsteam hatte begonnen zu vermuten, dass die Methode selbst es im Stich ließ. In Wahrheit hatte es einen wichtigen Schritt übersprungen.

Ich leitete eine Arbeitssession für die Führungsgruppe rund um eine einzige Frage. Wo musste dieses Framework für die Randbedingungen, mit denen sie lebten, neu geschrieben werden? Die Session nahm die Form eines strukturierten Gangs durch ihre realen Randbedingungen an. Ich veranschaulichte sie mit konkreten Beispielen aus der eigenen Leitung derselben Art von Programm. Wir trennten die Teile von SAFe, die sich sauber in ihre Welt übertragen, von den Teilen, die unter sicherheitskritischer Last zu brechen neigen. Wir benannten dann, was es die Organisation kosten würde, jeden Schwachpunkt unbehandelt zu lassen. Das Ziel war durchgehend, den Führungskräften das Framework zurückzugeben. Sie gingen mit voller Erlaubnis, es an ihre eigenen Bedingungen anzupassen.