On Lean and Agility

Bild: Unsplash / Vitaly Gariev - Lizenz

Eine der interessanteren Studien der letzten Zeit trägt den schönen Namen Führungsetage leer?¹ und kommt vom Kompetenzzentrum Fachkräftesicherung des Instituts der deutschen Wirtschaft. Ihr zufolge sind in deutschen Unternehmen fast 30.000 Führungskräfte-Positionen unbesetzt, gleichzeitig können sich aber nur wenige Nicht-Führungskräfte vorstellen, dorthin nachzurücken - nur 14 Prozent aller Angestellten wären ohne Vorbehalte bereit. Wir laufen damit in eine Art von Führungsproblem hinein.

Auch die Gründe dafür hat die Studie unter 5000 Teilnehmern abgefragt. Es sind hohe Arbeitsbelastung, zu grosse Verantwortung, zu grosse Einschnitte ins Privatleben, zu geringe finanzielle Anreize, der Kontaktverlust zur eigentlichen Arbeit (bzw. den dort arbeitenden Kollegen) und eine zu geringe Unterstützung von mittleren Führungspositionen durch das Topmanagement. Das sagt viel aus über die befragten Menschen, aber noch mehr über ihre Unternehmen.

Als jemand der seit 15 Jahren als externer Berater in zig Unternehmen unterwegs war muss ich leider sagen, dass diese Befürchtungen in vielen Fällen berechtigt sind, da es systemische Ursachen gibt, die zu genau diesen Ergebnissen führen. Zu grosse Aufgabenteilung und die Delegation von Verantwortung ohne Gestaltungsspielraum führen zu ständigen Abstimmungen und Eskalationen, wodurch die Rollen immer politischer werden und sich immer stärker von der eigentlichen Arbeit entfremden.

In diesen Zusammenhängen liegt aber auch die Chance es besser zu machen. Durch eine auf Produkte oder Kunden (statt auf Ressouceneffizienz) ausgerichtete Organisation lässt sich der Abstimmungs- und Eskalationsaufwand reduzieren, durch ein Konnexitätsprinzig kann Verantwortung an Gestaltungsspielraum gekoppelt werden und durch beides geht der Politik- und Bürokratie-Anteil der Arbeit zurück, wodurch wieder mehr Zeit für Fachlichkeit und Technikbezug bleibt.

Das ist natürlich in der Umsetzung eine alles andere als einfache Aufgabe, und die in diesen Ansätzen enthaltenen Ideen von dezentraler Autonomie und bewusstem Verzicht auf (temporäre) finanzielle Optimierung sind genau gegenläufig zur mehrheitlich gelebten Praxis grosser Organisationen. Eine Umgestaltung in diese Richtung wird daher in vielen Fällen auf Skepsis und Widerstände stossen. Stattfinden sollten sie aber trotzdem.

Ist das nämlich nicht der Fall, drohen sich die Tendenzen aus der Studie des Kompetenzzentrum Fachkräftesicherung zu verstärken. Dann wird (oder bleibt) die Arbeit als Führungskraft so unattraktiv, dass zu wenige sie ausüben wollen. Die zwangsläufige Konsequenz ist, dass Führungspositionen gar nicht besetzt werden, oder in Ermangelung geeigneter Kandidaten durch ungeeignete Personen. Und da kann ich wieder aus eigener Beratererfahrung sprechen: beides ist etwas, das man besser vermeiden sollte.

Seit kurzem kann ich einen weiteren Punkt in meiner grossen, ständig nachwachsenden To Do-Liste abhaken: ich habe einen Beitrag in einem juristischen Fachbuch veröffentlicht, und zwar in Product Compliance, Herausgegeben von Chibanguza und Steege im Nomos Verlag. Damit habe ich jetzt einen zweiten Grund um mich Autor zu nennen, aber auch darüber hinaus ist das Thema eines, das für mich schon seit längerer Zeit wichtig ist.

Wie ich schon einmal geschrieben habe, wird in einem agilen Vorgehen Compliance sichergestellt, indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden. Das bedeutet zwar, dass mehr (und unterschiedlichere) Arbeit parallel stattfinden muss, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell (denn: ohne Compliance keine Auslieferung). Und die Nachdokumentations-Aufwände am Ende fallen weg.

Um sicherzustellen, dass es so kommt, kann mit zweien der klassischsten unter den agilen Praktiken gearbeitet werden: der Definition of Ready (DoR) und der Definition of Done (DoD) bezw. mit ähnlich funktionierenden aber abweichend benannten Policies, Quality Gates oder vergleichbaren Ansätzen. Unanhängig vom Namen ist dabei wichtig, dass im Voraus klar ist, wie mit Compliance-Themen umgegangen wird, und dass bei jeder einzelnen Auslieferung eine Konformität gegeben ist.

Zunächst zur im Voraus nötigen Klarheit. Die bedeutet nicht, dass schon vor Beginn der Arbeit feststehen muss, welche Normen erfüllt werden müssen. Bei einem Vorgehensmodell, das die Art der Umsetzung möglichst lange offen lässt wäre das auch schwierig. Es kann aber in der DoR im Voraus festgelegt werden, welche Vorgaben zu prüfen oder welche Experten zu konsultieren sind, um das aktuelle Increment für compliant erklären zu können (zum Increment gleich mehr).

Die Art auf die das geschieht, kann dann Teil der DoD sein. Je nach Kontext kann die Ausgestaltung unterschiedlich sein, mögliche Varianten sind aber wie oben gesagt der Abgleich mit bestehenden Regeln und Gesetzen, die Freigabe durch einen Juristen, Datenschützer, o.Ä. und wenn erforderlich die Erstellung der dazugehörigen Dokumentation. Das kann natürlich bedeuten, dass z.B. ein Jurist Teil eines Softwareentwicklungsteams werden muss - aber das ist eben Crossfunktionalität.

Um sich dabei nicht zu verzetteln ist es schliesslich wichtig, sich darüber im Klaren zu sein, welcher Arbeits- oder Funktionsumfang denn jeweils Compliance-konform sein muss. Es ist das Increment, ein Begriff mit sehr spezifischem Inhalt: zu ihm gehört nicht nur der Umfang des letzten Sprints oder Arbeitspakets, sondern ausserdem die Summe aller bereits vorher erstellten Arbeitsergebnisse. Nur als Ganzes kann ein Increment compliant sein, und nicht lediglich in Teilen.

Wer ein bisschen Zeit in grossen Organisationen verbracht hat, dem wird früher oder später ein bemerkenswertes Phänomen aufgefallen sein - neben den offiziellen Führungs- und Koordinations-Positionen (Teamleiter, Projektmanager, etc.) gibt es auch inoffizielle Positionen, die für das Funktionieren der Zusammenarbeit mindestens genauso wichtig sind, wenn nicht sogar wichtiger. Eine dieser inoffiziellen Positionen sind die so genannten Glue People.

Hintergrund dieser Benennung ist, dass diese Menschen (deren Rolle sich im Deutschen wörtlich mit "Klebe-Personen" übersetzen lässt, sinngemäss aber eher Verbindungsperson bedeutet) dafür sorgen, dass bei Bedarf verschiedene Organisationseinheiten oder Prozessabläufe zusammengebracht und zusammengehalten werden. Wichtig ist dabei, dass das eben nicht im Rahmen der oft bürokratischen formalen Rollen und Beauftragungen erfolgt, sondern im Rahmen von Eigeninitiative.

Was für das Funktionieren einer Glue Personen-Rolle wichtig ist, ist aber nicht nur die Bereitschaft, sie einzunehmen, sondern auch das Vorhandensein eines bereits bestehenden Netzwerks in der Organisation. Erst dadurch, dass potentielle Ansprechpartner und Wissensträger (und deren Bereitschaft zur inoffiziellen Kooperation) schon bekannt sind, ist es möglich, vorbei an den offiziellen Abläufen Klärungen und Absprachen direkt vorzunehmen.

Wie dieses Netzwerk entstanden ist, kann dabei sehr unterschiedlich sein, sehr verbreitete Hintergründe sind aber eine lange Betriebszugehörigkeit, eine Versetzungsgeschichte durch verschiedene Abteilungen oder Projekte, ein Engagement in firmenübergreifenden Einrichtungen (Betriebsrat, Betriebssportverein, etc.) und dazu auf persönlicher Ebene die Fähigkeit und Bereitschaft zu Kommunikation, Informations-Weitergabe und gegenseitiger Unterstützung.

Ist all das gegeben, können Glue People zu einer spürbaren Erleichterung und Beschleunigung von Abläufen beitragen. Statt auf dem offiziellen Weg zuständige Personen ausfindig machen zu müssen, um dann an die Informations- oder Zusammenarbeits-Anfragen zu stellen und auf deren Beantwortung warten zu müssen, kann der notwendige Ansprechpartner direkt identifiziert und kontaktiert werden. Ggf. reduziert sich die Wartezeit dadurch von Wochen auf Stunden.

Zu beachten ist dabei aber auch, dass das Vorhandensein (und abhängig sein) von Glue People auch Probleme mit sich bringt. Durch ihre inoffizielle Natur sind sie in der Organisation häufig unsichtbar und unsteuerbar, ausserdem kann es dazu kommen, dass sie (wenn es nur wenige von ihnen gibt) Flaschenhälse oder Single Points of Failure bilden. Aus Systemsicht ist daher zwar nicht das Vorhanden sein von Glue People problematisch, aber die Abhängigkeit von ihnen.

Ein zusätzliches Thema kann sein, dass das Aufrecht-Erhalten des unternehmensweiten Netzwerks von Glue People Ressourcen kostet, allein dadurch, dass es auch ausserhalb konkreter Anlässe regelmässige Begegnungen und Austäusche erfordert, deren Dauer dann nicht mehr für die eigentliche Arbeit zur Verfügung steht (und die in Summe erstaunlich viel Zeit kosten können). Viele Firmen (wie z.B. Google) sehen Glue People daher eher kritisch und versuchen sie tendenziell unnötig zu machen.

Der Versuch, eine Organisation ganz ohne Glue People zu betreiben ist allerdings anspruchsvoll: um es zu können ist es notwendig, alle Prozess- und Zuständigkeitslücken zu schliessen, deren Vorhandensein sonst den Bedarf nach diesen Personen wieder erst entstehen lassen würde. Das wird nochmal erschwert dadurch, dass es nicht reicht, das nur einmal zu machen - in einer sich ständig ändernden Umwelt muss es vielmehr ein dauerhaftes anpassungsgetriebenes Vorgehen sein, das niemals aufhören kann.

Entweder ein Remix des Klassikers von Geek & Poke, oder jemand hat die gleiche tragikomische Idee nochmal gehabt. Sie ist aber auch (leider) zu naheliegend.

Unter den vielen verschiedenen agilen Frameworks dieser Welt ist Continuous Coordination in einer Hinsicht etwas Besonderes: es ist nicht als abstraktes Konzept aus Rollen und Regeln entstanden, die man dann später versucht hat, durch prozessunterstützende Software zu formalisieren (so wie es mit Scrum und Jira passiert ist), sondern am Anfang stand eine prozessunterstützende Software (Steady), aus deren Anwendungs-Erfahrungen irgendwann ein eigenständiges methodisches Vorgehen entstanden ist.

Die Idee dahinter dürfte gewesen sein, dass eine Koordinations-Software (genau wie jedes andere Tool) auch missbräuchlich oder versehentlich falsch genutzt werden kann. Um dem entgegenzuwirken entwickelten mehrere Entwickler und Nutzer mit der Zeit ein Set von Prinzipien und Praktiken, die eine Anwendung im ursprünglichen Sinn sicherstellen sollen. Und da diese auch mit jeder anderen Software umsetzbar sind, wurde Continuous Coordination zu etwas Eigenständigem.

Bedingt durch diese Entstehungsgeschichte finden sich in diesem Framework einige Besonderheiten. Zum einen ist es (genau wie die Software aus der es entstanden ist) für asynchrone Zusammenarbeit gedacht, also für eine in der die Kommunikation in Textform die meisten Meetings ersetzt. Zum anderen besteht es vor allem aus relativ abstrakten Prinzipien, die weniger einen Anleitungs-Charakter haben und eher die zugrundeliegenden Ideen klar machen sollen. Es sind die folgenden:

01: Keep a steady beat

Im Grunde eine Abwandlung des Constant Pace aus dem Manifest für agile Software-Entwicklung. In regelmässigen Abständen (meistens täglich) schreibt jeder in gemeinsame Chat-Gruppen oder Kanäle woran er arbeitet, wo Abhängigkeiten sind, wie der Fortschritt ist, etc. Teamübergreifend sind die Frequenzen seltener, z.B. wöchentlich.

02: Lead with context

Führung in diesem Zusammenhang ist nicht nur disziplinarische Führung, es kann auch hierarchiefreie fachliche oder technische Führung sein. Wichtig ist in allen diesen Fällen, dass schriftlich explizit gemacht wird, welches Ziel, welche Abhängigkeiten und welche Rahmenbedingungen oder eine Anforderung hat. Die Umsetzung soll dann selbstorganisiert erfolgen, ohne Anleitung und Kontrolle.

03: Work in the open

Aufbauend auf dem letzten Punkt stellt sich die Frage, wie Fehler, falsche Annahmen und Ähnliches in diesem Modus entdeckt werden können. Die Antwort: durch maximale Transparenz der eigenen Arbeit. Alle Anforderungen, alle fachlichen Diskussionen, Deployments und Dokumentationen stehen allen anderen in Schriftform in Wikis, gemeinsamen Laufwerken oder Versionshistorien zur Verfügung.

04: Tell the future

Entlehnt von der Intent-based Leadership aus David Marquets Buch Turn the Ship around kann jeder durch regelmässige Absichtserklärungen transparent machen, wie und woran er als nächstes arbeiten wil. Wer Fragen, Ergänzungen oder Einwände hat kann die dann äussern und klären, und so ggf. Konflikte vermeiden bevor sie überhaupt entstehen.

05: Spare the meetings

Bevor falsche Ideen aufkommen: Continuos Coordination legt Wert darauf, dass Meetings existenziell wichtig sind, aber eben nicht alle. Während z.B. Retrospektiven, Kreativ-Sessions oder Wissenstransfer-Termine auf jeden Fall stattfinden sollten, können Dailies, Status-Meetings, Feedback-Sammlungen oder Informationsveranstaltungen auch asynchron in Schriftform stattfinden.

06: Write it down

Gemeint ist hier nicht etwa ein Ergebnis-Protokoll, sondern im Gegenteil ein im Voraus stattfindendes Aufschreiben von Zielen, Erfolgsfaktoren, Zusammenhängen und angestrebten Effekten. Das hilft zum einen bei der Strukturierung der eigenen Gedanken und hilft zum anderen bei der Erfolgsmessung. Übernommen ist es von Amazons Press Releases.

07: Track output, not input

Zuletzt ein klarer Bruch mit vielen klassischen Management-Praktiken. Statt zu messen und steuern zu wollen, wie viel Arbeitszeit und Ressourcen in eine Aufgabe hineingehen soll der Focus von Messungen das erzeugte Ergebnis sein, und das nicht etwa in Form von des Zählens von Features oder Code-Zeilen, sondern von Ergebnissen wie Kundenzufriedenheit, Nutzungsintensität oder Profitabilität.

Trotz ihrer Abstraktheit haben diese Prinzipien bei Befolgung deutlich spürbare Auswirkungen, und sorgen dafür, dass eine Organisation die sie befolgt sich deutlich von anderen unterscheidet - sowohl von agilen als auch von nicht-agilen. Kern-Element ist dabei die möglichst intensive Nutzung von asynchroner, schriftlicher Kommunikation und die Beschränkung von synchroner Kommunikation auf der Tonspur auf wenige, dafür aber zentrale Formate.

Für jeden, der sich von zu vielen Meetings von der Arbeit abgehalten sieht wird dieser Arbeitsmodus sofort attraktiv erscheinen, und er kann auch sehr gut funktionieren, er kommt aber mit einem Preis - die Arbeit wird auf diese Weise unpersönlicher, abstrakter und für viele Menschen gefühlt einsamer. Dessen sollte man sich zu Beginn bewusst sein, und man sollte in regelmässigen Abständen überprüfen ob und wie die Beteiligten damit klarkommen. 

Und zuletzt: dieser Modus benötigt einfach bedienbare, für alle zugängliche, wenig reglementierte digitale Tools. Auch die müssen erst mal da sein.

Bild: Wikimedia Commons / David.Monniaux - CC BY-SA 3.0

Von den so genannten "Gesetzen der Softwareentwicklung" oder "Gesetzen des Projektmanagement" gibt es mittlerweile unübersehbar viele, allerdings stehen einzelne deutlich aus dieser Menge heraus. Eines davon ist Brooks's Law, benannt nach seinem Verfasser, dem amerikanischen Informatiker Frederick Brooks¹, der es 1975 im Essay The Mythical Man-Month in seinem gleich benannten Buch zum ersten mal veröffentlichte. Es lautet:

Adding manpower to a late software project makes it later / Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt sorgt für noch mehr Verspätung

Frederick Brooks, The Mythical Man-Month, S.25

Der Grund dafür, dass Brooks diese Gesetzmässigkeit verfasste war der, dass das übliche Management-Verhalten in Software-Projekten damals genau gegenläufig war.² Tatsächlich erscheint es auf den ersten Blick auch naheliegend - jede einzelne Person kann eine bestimmte Menge Arbeit pro Zeiteinheit erledigen, wenn man also weitere Personen hinzufügt könnte man davon ausgehen, dass in der selben Zeit mehr Arbeit erledigt werden kann. Aber so einfach ist es nicht.

Brooks nannte gleich mehrere Gründe, die dafür sorgen, dass statt einer Beschleunigung eine zusätzliche Verspätung auftritt. Der erste und offensichtlichste: neue Kollegen müssen zuerst eingearbeitet werden um arbeitsfähig zu sein, und das kann in der Regel niemand anderes tun als eine der Personen, die bereits länger mitarbeiten. Für die Dauer der Einarbeitungszeit kann er daher selbst nur eingeschränkt produktiv sein, die Arbeitskapazität nimmt also zunächst ab.

Selbst wenn die Einarbeitung abgeschlossen ist, gehen die verzögernden Effekte aber weiter. Wenn ein Vorhaben ursprünglich für eine geringere Umsetzungsmannschaft ausgelegt war, müssen als nächstes die Umsetzungsplanung und Aufgabenteilung überarbeitet werden, um sicherzustellen, dass synchrone und sequenzielle Abhängigkeiten berücksichtigt werden. Auch das benötigt wieder Arbeitskapazität, die dann bei der Umsetzung fehlt und diese dadurch verzögert.

Nun könnte man davon ausgehen, dass diese Verlangsamungs-Faktoren nur temporär sind. Irgendwann sind Einarbeitung und Umplanung abgeschlossen, und es kann mit erhöhter Geschwindigkeit weitergehen. Aber zum einen ist in den meisten verspäteten Projekten die dafür notwendige Zeit gar nicht gegeben, und zum anderen gibt es noch einen weiteren Faktor, der nicht temporär sondern dauerhaft sind, und der speziell mit den Abläufen der Softwareentwicklung zu tun hat.³

Wenn bei der Entwicklung einer Software neuer Code geschrieben wird, muss dieser danach in den bestehenden integriert werden. Um sicherzustellen, dass dieser danach noch immer funktioniert, sind Tests notwendig, und bei steigender Menge von Code schreibenden Entwicklern steigen auch Frequenz und Umfang der durchzuführenden Tests. Aufgrund dessen wird ein immer grösser werdender Teil der Arbeitskapazität dafür benötigt, die Tests aktuell zu halten, durchzuführen und auszuwerten.

Selbst wenn Softwareentwicklung heute etwas anders funktioniert als zu Brooks Zeit (sein Gesetz ist mittlerweile schon über 50 Jahre alt) haben sich die von ihm beschriebenen grundlegenden Zusammenhänge bis heute erhalten. Man kann daher noch immer davon ausgehen, dass das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt nicht für eine Beschleunigung sorgt, sondern für noch mehr Verspätung, und das nicht nur kurzfristig, sondern dauerhaft.

Bild: Pexels / Ekam Juneja - Lizenz

James Shore: The Best Product Engineering Org in the World

Charles Lambdin: Why Agile Is Losing Steam

Itamar Gilad: Embracing Uncertainty - A Modern Take On Strategy, Goals, and Roadmaps

Steve Denning: How Networks Of Competence Help Avoid The Trauma Of Reorganizations

Tobias Mayer: A simple Guide to Scrum

Charity Majors: In Praise of “Normal” Engineers

Benji Weber: Teamwork & XP in the era of Genies

Mike Fisher: How Culture Scales (or Doesn’t)

Melissa Suzuno: The Product Operating Model Explained

Jeff Gothelf: What if there’s no behavior change to measure?

Grafik: Pixabay / Brian Penny - Lizenz

John Cutler: Product Operating Models vs Operating Systems (Part I, Part II)

Roman Pichler: Should Product Teams be Self-Managing?

Andi Roberts: Why Tuckman’s model may no longer serve 21st century teams

Jessica Wolfe: Rethinking “The Developer” - Builders, Modernizers, Orchestrators

Mike Fisher: When Change Outruns Us