On Lean and Agility

Ich sage es immer wieder, ein zentraler Schlüssel zu mehr Agilität ist der Abbau von Abhängigkeiten. Das bezieht sich auf Organisationen und Prozesse, es bezieht sich aber auch auf Software. Michael Nygard zeigt sehr schön auf, warum das so ist und was man dagegen tun kann.

Was man an seinem Vortrag besonders hervorheben kann ist, dass er Zusammenhänge der Softwareentwicklung so erklärt, dass man ihm in weiten Teilen auch ohne Informatik-Expertise folgen kann. Er ist daher gut geeignet um Stakeholdern ausserhalb der IT Problemfelder aufzuzeigen.

Bild: Pixabay - Mabel Amber - Lizenz

Zu den Firmen, die in der agilen Community gehypt und als Vorbild gesehen werden, gehört seit einigen Jahren auch Tesla. Dass das so ist, hängt weniger damit zusammen, dass man wirklich weiss wie dort gearbeitet wird, und mehr mit einem bekannten "Methodenbotschafter". Joe Justice hat dort als Agile Coach gearbeitet und erzählt oft von dieser Zeit (zum Beispiel hier). Und die eine Erzählung die zum "agilen Mythos" von Tesla beiträgt ist diese: dort gibt es Teams, deren Sprint nur drei Stunden dauern.

Wie genau das vor sich geht, verrät er mit Verweis auf eine Geheimhaltungsvereinbarung nicht, er betont aber, dass am Ende jedes Sprints ein Increment steht, was durchaus beeindruckend ist. Wenn wir jetzt unterstellen, dass sich dahinter nicht nur eine Fantasie-Geschichte verbirgt, sondern ein echter Erfahrungsbericht, verlockt all das sehr zur Spekulation. Wie kann es Tesla wohl geschafft haben, auf diese unglaublich wirkenden Lieferzyklen zu kommen?

Um mit etwas nicht Unwesentlichem zu beginnen - es ist nicht so, dass alle Teams diese schnelle Taktung haben. Justice berichtet selber, dass es nur einige Teams sind die so organisiert sind, bei anderen dauert es deutlich länger, bis zu drei Monaten.¹ Das relativiert die Geschichte bereits ein bisschen, alleine deshalb weil nicht klar wird, wie die Mengenverhältnisse sind. Würden z.B. nur 10 Prozent der Teams in Dreistunden-Sprints arbeiten wäre das immer noch beachtlich, aber nicht so sehr wie bei 90 Prozent.

Eine zweite wesentliche Rahmenbedingung ist die, dass es sich nicht um Sprints handelt, wie wir sie aus Scrum kennen. Scrum ist für eine bis vier Wochen konzipiert und würde in derartig kurzen Zeiträumen für Meeting-Overhead sorgen, dazu kommt, dass es die zentrale und im Framework zwingend vorgegebene Scrum Master Rolle laut Justice bei Tesla nicht gibt. Dort wird also nicht nach Scrum gearbeitet. Um welche andere Variante von Sprints es sich handelt, bleibt offen, es könnten z.B. auch Endsprints sein.

Eine dritte Information gibt es wieder bei Justice selbst: bei vielen Teams handelt es sich nicht um langfristig stabile Produktteams, sondern um Ad hoc-Teams, die kurzfristig in einem Open Space-artigen Prozess aus den gerade verfügbaren Mitarbeitern zusammengestellt werden. Das bedeutet aber auch, dass diese Teams nicht alle drei Stunden, bzw. jeden Sprint, ein Increment liefern, alleine deshalb nicht, weil sie sich nach jedem Sprint wieder auflösen und ihre Mitglieder ins nächste Ad hoc-Team wechseln.

Mit diesem Wissen im Hinterkopf - möglicherweise ist es am Ende viel banaler als man denkt. Ein Teil der Mitarbeiter arbeitet in tage-, wochen- oder monatelangen Zyklen mehr oder weniger agil, nur der andere Teil findet sich in kurzfristig gebildeten Ad hoc-Teams zusammen, die dann relativ kleine Aufgaben übernehmen (etwa den Austausch eines Maschinen-Bauteils oder das Anpassen eines Formulars auf einer Webseite). Und diese schnellen Klein-Arbeiten nennt man dann "Sprint".

Bild: Unsplash / Jud Mackrill - Lizenz

Dass es in einer Software entwickelnden Organisation schwierig ist, wenn nur eine Minderheit der Angestellten selbst in der Lage ist zur Software-Entwicklung beizutragen, dürfte nachvollziebar sein. Das Risiko ist in solchen Fällen gross, dass es zu Silo-Bildung, Prozess-Overhead und Arbeits-Rückstaus kommt. In grossen Organisationen ist diese Problemlage aber oft nicht ohne weiteres ersichtlich, so dass ihre Entdeckung oft überraschend wirkt.

Der Grund dafür ist die fehlende Einsicht der meisten Beteiligten in die tatsächlichen Mengenverteilungen. Damit ist weniger gemeint, dass keinem bewusst ist, wie wiele Entwickler im Unternehmen sind und wie gross ihr Anteil an der Gesamtbelegschaft ist, vielmehr geht es darum, dass nur den wenigsten Mitarbeitern ausserhalb der IT klar ist, wer (ausserhalb der eigenen Abteilung) sie regelmässig beauftragt, mit was und in welchem Umfang.

Irgendwo gibt es zwar eine Portfolio- und Aufwandsplanung, aus der man herleiten könnte, für wen alles intern Software entwickelt wird, meistens ist die aber nicht so einfach zugänglich, man sieht nur das was einen selbst betrifft. Und so lange Organisation so aufgebaut sind, dass IT und Fachabteilungen eigene organisatorische Einheiten sind (in der Regel nochmals mit einer auf Funktionen basierenden Aufteilungen in Untergruppen), wäre das Gewinnen eines Gesamtbildes auch relativ aufwändig.

Im Rahmen agiler Transformationen gibt es aber einen Punkt, an dem die Mengenverteilungen schlagartig offensichtlich werden, nämlich dann, wenn versucht wird, die Organisation auf Value Stream- oder Produktorientierung umzustellen. Im Rahmen einer solchen Umstellung werden in der Regel alle Fachspezialisten, Produkt- und Projektmanager, Kundenbetreuer, Marketing- und Vertriebsmitarbeiter und eben Softwareentwickler in einer Einheit oder einer Querschnittsorganisation zusammengefasst.

Dort wo ich derartige Umstellungen in Grossorganisationen erlebt habe, waren am Ende (je nach Produktschnitt) zwischen 10 und 30 Menschen in einer solchen Produkt- oder Value Stream-orientierten Einheit zusammengefasst. wovon (und jetzt kommt es) in fast allen Fällen weniger als 10 Prozent Software entwickeln konnten. Ich kann mich sogar an Fälle in verschiedenen Firmen erinnern, in denen es mehr Value Streams als Entwickler gegeben hat.

Je nach Einzelfall kann man zwar immer argumentieren, dass es immer auch eine Reihe von Nicht-Entwicklungstätigkeiten für das jeweilige Produkt braucht, Fälle wie die gerade genannten (von denen es in grossen Organisationen erstaunlich viele gibt) sind aber offensichtlich dysfunktional und erinnern völlig zu Recht an das Single worker digging hole-Meme. Und dass eine solche Situation nur in einem Nerven- und zeitfressenden Kampf um die knappen Kapazitäten enden kann, dürfte auch klar sein.

Anders als in vielen anderen Fällen ist in einer solchen Situation die Lösung auch realativ klar: man kann entweder die Umsetzungskapazität in der Software-Entwicklung ausbauen (Leute einstellen) oder den umgebenden Overhead abbauen (Leute entlassen oder versetzen). Und wenn man sich dazu nicht durchringen kann sollte man zumindest eines Allen klarmachen - wenn man irgendein Ergebnis nicht so schnell bekommt wie man es gerne hätte liegt das nicht daran, dass die IT so langsam ist, sondern dass die Dev/Non-Dev Ratio völlig unausgewogen ist.

Bild: CCNull / Marco Verch - CC BY 2.0

Dass willkürlich gesetzte Deadlines problematisch sind, dürfte wohl bei kaum jemandem einen Widerspruch auslösen. Dass sie trotzdem immer wieder anzutreffen sind, hat menschliche und politische Gründe, die leider immer wieder vorkommen werden. Wer in einem solchen Umfeld beruflich unterwegs ist, muss sich daher mit diesem Thema beschäftigen und sollte am Besten überzeugende Gründe parat haben, warum sie keine gute Idee sind.

Zu den überzeugendsten dieser Gründe dürfte gehören, dass willkürliche Deadlines negativ auf den zurückfallen, der sie festlegt. Das ist zunächst für viele Menschen kontraintuitiv, schliesslich scheint in solchen Fällen der schwarze Peter doch bei denen zu liegen, die die gesetzten Fristen nicht einhalten können. Ein Praxisbeispiel zeigt aber, dass auch die andere Seite in Mitleidenschaft gezogen werden kann: das Onlinezugangsgesetz (OZG).

Das OZG wurde im Jahr 2017 im Parlament verabschiedet und legte fest, dass bis zum Jahr 2022 alle Behördengänge auch digital zu erledigen sein müssen. Der letzte Tag dieses Jahres, der 31.12.2022, wurde damit automatisch zur Deadline für die Umsetzung. Schon damals gab es Zweifel, dass diese Fristsetzung realistisch war, mittlerweile weiss man, sie war es nicht. Selbst Monate später sind erst 101 von 600 geplanten Leistungen online.

Die offensichtlichste Folge eines solchen Verzuges: weitere Fristsetzungen verlieren durch ihn ihre Glaubwürdigkeit nach aussen. Neben der fristsetzenden und der (verspätet) umsetzenden Seite gibt es nämlich fast immer eine dritte Partei, die externen Stakeholder. Und um beim Beispiel des OZG zu bleiben: verschiedene Kommentare in den Medien lassen keinen Zweifel daran, dass zukünftigen Zielsetzungen nicht mehr vertraut wird.

In Folge dessen werden zukünftige Zeitpläne von Anfang an mit grosser Skepsis begleitet, regelmässig hinterfragt und mit der ständigen Forderung nach Transparenz in Form von Zwischen-Fristen und Zwischen-Berichten konfrontiert. Diese führen bei allen Beteiligten zu z.T. erheblichen Mehraufwänden, die die Umsetzung nochmals verzögern und dadurch selbst solche Teilziele gefährden, die eigentlich erreichbar gewesen wären. Auch hierzu gibt es Beispiele aus dem OZG-Umfeld.

Anders, aber ähnlich schwerwiegend sind die Folgen nach innen. Das offensichtliche und deutliche Verpassen der Frist führt nämlich bei den mit den unrealistischen Umsetzungszielen beauftragten Menschen zu der Erkenntnis, dass ein solcher Verzug eigentlich kein Problem ist, schliesslich gibt es keine negativen Folgen (die meistens einzig vorhandene Sanktionsmöglichkeit, das Entziehen von Mitteln, würde schliesslich nur zu noch mehr Verzögerung führen).

Ist dieser Eindruck erstmal entstanden, kann von einem weiteren Effekt fast sicher ausgegangen werden - ohne ernsthafte Konsequenzen schwindet die Motivation, sich bei der Umsetzung über das übliche Mass hinaus zu engagieren. Selbst mit relativ geringen Mehraufwänden erreichbare Zieldaten lässt man verstrechen, erst recht wenn diese in einer grösseren Menge von Bitten, Forderungen und Eskalationen untergehen, von denen "alles wichtig ist". Es kommt ungewollt zur Erziehung zur Normverletzung.

In Summe entsteht so durch willkürliche Deadlines extern ein grundlegender Zweifel, der durch (gut gemeinte) Kontrollmassnahmen alles noch weiter verzögert und intern ein gewisser Nihilismus, der Eigeninitiative und Engagement verdrängt und ab einem gewissen Grad sogar dazu führt, dass es zu einer Abstimmung mit den Füssen kommt, also zu Kündigungen, durch die es nochmal zu zusätzlichen Verzögerungen kommt.

Ich habe als externer Berater Fälle erlebt, in denen willkürliche Deadlines zu solchen Aufwands-Explosionen geführt haben, dass eigentlich nur leicht verspätete Vorhaben sich um Jahre verlängert haben oder sogar abgebrochen werden mussten - häufig verbunden mit einem empfindlichen Karriereknick der verantwortlichen Manager. Und alleine die Aussicht das am eigenen Fall zu erleben sollte eigentlich ein überzugender Grund sein, sich bei "ambitionierten Zielsetzungen" zurückzuhalten. Schliesslich kann nicht jeder Probleme so einfach aussitzen wie die Digitalisierungs-Politiker.

In vielen Entwicklungsteams ist Compliance (die Ausführung, Überwachung und Dokumentation von regelkonformem Verhalten) etwas das sie zutieft verabscheuen, da es bürokratisch und aufwändig ist. Effy Elden zeigt auf, dass das nicht so sein muss. Integriert in den Code kann Compliance zu einem Teil der Entwicklung werden, der ähnlich zu entwickeln ist wie die restliche Anwendung.

Was sie hervorhebt, und was aus meiner Sicht auch richtig ist, ist, dass Compliance as Code nicht ohne Vertrauen in die Entwicklungsteams machbar ist. Im Quelltext vorhandene Kontrollen können nur von Entwicklern auf Konsistenz und Wirksamkeit überprüft werden. Allerdings: klassische Compliance-Prozesse der IT bestehen häufig auch nur aus Checklisten, in denen Entwickler durch das Setzen von Haken bestätigen müssen, dass sie sich an alle Regeln gehalten haben. Auch in dem Fall muss man darauf vertrauen, dass sie wissen, was sie tun.

Heute ist das eine Bild das mehr als 1000 Worte sagt ein Klassiker. Ich habe es vor einiger Zeit bei einem Kunden erstellt, angelehnt ist es an das bekannte Original von Klaus Leopold. Die Aussage ist bei beiden die gleiche: so funktioniert Agilität nicht.

"We are soooo Agile but we don't see any improvement in TTM." Really?! Guess why? pic.twitter.com/zEIvmU9aCV

— Klaus Leopold (@klausleopold) August 13, 2017

BTW: dass ich das Original nicht einfach übernommen habe liegt daran, dass die Abläufe dieses Kunden etwas anders waren.

Bild: Unsplash / Fabio Bracht - Lizenz

Barry Overeem: How Poor Facilitation Of The Scrum Events Can Cause Zombie Scrum

Bruno Baketarić: You should not track flow efficiency!

Jim Highsmith: Micromanaging the Right Way

Fagner Brack: Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in Software Development

Jeff Gothelf: The Product is the Variable

Bild: Encyclopædia Britannica - OGL 3.0

Dass es in den Politikwissenschaften nennenswerte Impulse für die Agile Produktentwicklung zu holen gibt, überrascht immer wieder, bei genauerer Bertrachtung ist es aber naheliegend. Die Aufteilung und Neuverteilung von Macht (Weisungsbefugnis, Budgets, Vetorecht, etc.) ist ein politischer Prozess, sowohl in einem Land als auch in einem Unternehmen. Und damit das während einer agilen Transition nicht in Konflikten endet, bedarf es einer besonderen Einrichtung: der loyalen Opposition.

Die Idee der loyalen Opposition stammt aus Grossbritannien, genauer gesagt aus dem britischen Parlament. Ursprünglich hatten hier alle Abgeordneten, die nicht die Regierung unterstützten, unter dem Verdacht gestanden, die vorhandene Ordnung komplett abzulehnen. Dadurch, dass die Opposition sich loyal zu dieser Ordnung erklärte und nur in ihrem Rahmen anders handeln wollte, wurden potentielle Konflikte entschärft und Regierungswechsel unproblematisch.

Übertragen auf Unternehmen und agile Transitionen bedeutet das, dass bestimmte grundlegende Rahmenbedingungen und eingegangene Verpflichtungen nicht ohne weiteres abgeschafft werden dürfen, wenn Macht (Weisungsbefugnis, Budgets, Vetorecht, etc.) an andere Gruppen übergeht. Welche das sind kann von Fall zu Fall anders sein, gegebenenfalls kann es sinn machen sie explizit zu machen, so dass alle Beteiligten das gleiche Verständnis haben.

Die sich daraus ergebende erste Funktion einer solchen loyalen Opposition ist es, die Vorbehalte gegen eine neue Machtverteilung abzuschwächen. Wenn beispielsweise klar ist, dass die Gewinnerzielungs-Absicht nicht in Frage gestellt werden wird, werden Widerstände von Besitzern und Aktionärsvertretern geringer werden, und wenn klar ist, dass Qualitätsstandards und Rechtssicherheit auch weiter für wichtig gehalten werden, werden sich Rechts- und Testabteilungen leichter mit Veränderungen abfinden.¹

Die zweite, häufig unterschätzte Funktion einer Loyalen Opposition ist die Bereitschaft, die nicht ohne weiteres abschaffbaren Teile der vorhandenen Ordnung nicht nur zu tolerieren, sondern aktiv an ihrer Aufrechthaltung mitzuwirken. Um bei den gerade genannten Beispielen zu bleiben: eine Entwicklungseinheit, die nicht von aussen bestimmt werden will muss im Gegenzug selbst bereit sein Profitabilität, Qualitätsstandards und Rechtssicherheit zu gewährleisten.

Natürlich ist der Begriff der loyalen Opposition in den meisten Unternehmens-Kontexten nur eingeschränkt benutzbar, da er zu erklärbedürftig oder wunderlich wirken dürfte, die dahinterstehenden Ideen sind aber einfach zu erklären und sollten dafür sorgen, dass Machtverschiebungen wesentlich konfliktfreier ablaufen als in nicht derartig fundierten Veränderungen.