On Lean and Agility

Manchmal hilft bei der Vermittlung komplexer Sachverhalte ein Video ungemein, so auch in diesem Fall. Erklärt wird die Idee der Verspätungskosten, bzw. der Cost of Delay. Gut verständlich und kompakt zusammengefasst, in nur wenigen Minuten.

Cost of Delay – An Introduction from Joshua Arnold on Vimeo.

Bemerkenswert ist, dass das Video bereits mehr als ein Jahrzehnt als ist. Was seine Erstellung damals für einen Aufwand bedeutet hat mag man sich kaum vorstellen. Heute mit KI ginge es sicher in einem Bruchteil der Zeit.

Bis zur Überarbeitung des Scrum Guide im Jahr 2020 enthielt er in Bezug auf die Definition of Done (DoD), sein zentrales Quality Gate, durch das alle neu erstellten Funktionalitäten passieren müssen, eine Formulierung, die zumindest aus meiner Sicht hochgradig kontrovers war. Sinngemäss stand in ihr, dass die Qualität des erzeugten Produkt oder Service sich verbessern liesse, indem der Umfang der DoD vergrössert würde. Oder im englischen Original:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Scrum Guide, 2017 Version

Nun ist dieser Passus wie gesagt seit dem Jahr 2020 Geschichte, er ist aber in vielen Teams und Organisationen noch immer im expliziten oder impliziten Verständnis von Scrum hängengeblieben. Daher lohnt sich eine nähere Betrachtung - warum kann die Idee einer "expandierenden Definition of Done" problematisch sein, und unter welchen Umständen ist es möglich, diese negativen Aspekte zu vermeiden oder sogar ins Vorteilhafte zu drehen?

Um mit dem problematischen Teil zu beginnen: eine DoD, die versucht, umfassend alle Eventualitäten zu regeln, wird zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen sind. Das ist eine Falle, in die viele Teams tappen. Vor allem in Wikis oder shared Docs mit ihrem unbegrenzten Platz kann es zu einem wuchenden Wachstum von manchmal geradezu absurdem Ausmass kommen.¹

Derartig aufgeblähte Dokumente sorgen dafür, dass die von ihnen betroffenen Teams und Projekte in einer Zwickmühle sitzen. Entweder stellen sie sicher, dass alles was dort steht befolgt und eingehalten wird, verbunden mit einem erheblichen Verwaltungs- und Dokumentationsaufwand. Oder sie riskieren, dass sie einzelne Elemente vergessen und übersehen und damit nicht einhalten (oder die Unübersichtlichkeit führt versehentlich dazu, dass einzelne Teile sich gegenseitig widersprechen).

Jetzt zum positiven Fall, bzw. zu der Frage, wie dieser aussehen kann. Die (vor allem für IT-Produkte naheliegende) Antwort - automatisiert. Genauer gesagt, die Einhaltungs-Überprüfung der DoD findet automatisiert statt. Vorgaben wie Testabdeckung, Lastfähigkeit, maximale Verschachtelungstiefe des Code, das Nichtvorhandensein von auskommentierten oder ausgetoggleten Features oder sogar korrekte Rechtschreibung lassen sich durch automatisierte Tests schnell validieren - auch in grossem Umfang.

Für Teams und Organisationen die so vorgehen wollen, ergibt sich dadurch die folgende Richtlinie: eine Definition of Done wird nur dann durch einen zunehmenden Umfang besser, wenn die enthaltenen Vorgaben zum Grossteil automatisiert validierbar sind.² Die nicht automatisiert überprüfbaren Teile können zwar ihre Berechtigung haben, um Unübersichtlichkeit und Bürokratie zu vermeiden, sollten sie aber regelmässig überprüft und ggf. verschlankt werden.

Bild: Pexels / Ekam Juneja - Lizenz

Stefan Kühl: Die Komplexitätsreduktion durch Managementmoden

Stefan Norrvall: Three Axes — Now What?

Stephanie Ockerman: Self-Managing Teams - From Compliance to Collaboration

Maarten Dalmijn: Red Vs Blue Roadmaps - Why Most Roadmaps Suck

Mike Fisher: Culture Debt

Ich sage es schon seit langem: eine der Hauptzielgruppen von Change-Vorhaben sind Manager, und im Sinn eines zielgruppenorientierten Vorgehens sollte man daher seine Botschaft so verfassen können, dass sie für Manager Sinn ergibt. Alan Holub hat da einige schöne Ideen.

Eine gewisse Ironie der Geschichte ist übrigens, dass Holub plötzlich aus einem unerwarteten Grund zusätzlich Management-kompatibel ist: durch seine Ablehnung des Begriffs "Agile". Die Gründe dafür sind unterschiedliche (bei ihm die mit der Zeit stattgefundene Kommerzialisierug und Formalisierung der agilen Frameworks, bei vielen Managern die enttäuschte Hoffnung auf ein Wundermittel), in der grundsätzlichen Abwehrhaltung kommen sie aber zusammen.

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.