On Lean and Agility

Bild: Unsplash / Fabio Bracht - Lizenz

Nathan Furr, Kate O’Keeffe : The Hybrid Start-Up

Lucas Fernandes da Costa: How processes are born, why they can be damaging, and how to fix them

Johanna Rothman: How to Measure All Your Work in Progress to Make Better Decisions

Dan North: But what about the BAU work?

Willem-Jan Ageling: SAFe Scrum — Is it actually Scrum?

Cognitive Biases, zu deutsch verzerrte Wahrnehmungen, sind häufiger, als wir es uns eingestehen wollen. Nahezu alle Aspekte unseres Lebens sind davon betroffen, dass wir die Realität nicht immer so wahrnehmen wie sie ist, sondern so wie wir sie uns vorstellen. Auch in der Produktentwicklung kommen derartige Verzerrungen vor, und zwei von ihnen können besonders unschöne Auswirkungen haben: die Empathie-Lücke und die subjektive Validierung.

Empathie-Lücken liegen vor, wenn wir nicht in der Lage sind, uns in die Situation anderer Menschen hineinzuversetzen. Die Ursache dafür sind in der Regel Unterschiede in Herkunft, Alter, Geschlecht, Ethnie oder anderen Faktoren. Warum das in der Produktentwicklung ein Problem ist, dürfte offensichtlich sein - schlimmstenfalls entwickeln wir Produkte an den Bedürfnissen oder Vorlieben der Zielgruppe vorbei, mit der Folge, dass sie am Markt nicht erfolgreich sind.

Eine subjektive Validierung bedeutet, dass wir uns selbst unbewusst zum Massstab für andere machen. Unsere eigenen Wahrnehmungen, Gefühle und Vorlieben kommen uns so selbstverständlich vor, dass wir gar nicht auf den Gedanken kommen, dass andere sie nicht teilen können. In der Produktentwicklung bedeutet das, dass wir schlimmstenfalls nur das entwickeln, was wir selbst verstehen und gut finden und nicht das was auch die Zielgruppe verstehen und brauchen würde.

Ein Beispiel, mit dem man das plastischer machen kann, sind die Schlüsselkarten-Lichtschalter in Hotelzimmern. Sir wurden um das Jahr 2000 herum entwickelt und beruhen auf einer simplen Idee: das Licht im Zimmer lässt sich nur einschalten, wenn die Karte, mit der man auch die Zimmertür öffnet, in einen Schlitz an einem Hauptschalter steckt. Verlässt man das Zimmer, nimmt man die Schlüsselkarte mit, das Licht geht wieder aus und das Hotel spart Strom.

Wir können jetzt versuchen uns vorzustellen, wie wir reagiert hätten, wenn man uns damals diese Idee vorgestellt hätte. Vermutlich positiv. Die Idee klingt gut, man versteht sofort worum es geht, sie ist relativ einfach umzusetzen und mit dem Stromsparen dient sie einem Zweck, der Wirtschaftlichkeit und Umweltschutz vereint. Auch die Manager der Hotelketten waren damals sofort überzeugt, Schlüsselkarten-Lichtschalter sind heute der fast überall anzutreffende Standard.

Das Problem an dieser eigentlich schönen Geschichte: die Idee hat in der Realität nicht gut funktioniert. Viele Hotelgäste verstanden die Funktionsweise nicht und hielten das Licht für kaputt, andere fanden im Dunkeln den Schlitz nicht, wieder andere waren es gewohnt, die Schlüsselkarte im Portemonnaie mit sich zu tragen und vergassen sie ständig im Zimmer. Die Folgen waren schlechte Bewertungen und hoher Arbeitsaufwand für das ständig  zur Hilfe gerufene Personal.

Heute steckt in fast allen Hotels eine zweite Karte dauerhaft in den Schlitzen der Hauptschalter, die dadurch ständig angeschaltet sind. Es gibt zwar meistens den Hinweis, dass man durch das Herausziehen Strom sparen kann (wie oben auf dem Bild), wer sich erkundigt wird aber erfahren, dass das nur selten passiert. Am Ende hat die eigentlich gute Idee also nur dazu geführt, dass in allen Zimmern ein zusätzlicher, kaum genutzer und unnötig komplizierter Lichtschalter eingebaut wurde.

Um wieder zum eigentlichen Thema zurückzukommen - wenn es uns schon bei so einfachen Einrichtungen wie Lichtschaltern und Schlüsselkarten schwer fällt uns in die Anwender hineinzuversetzen, wieviel schwieriger ist es dann bei komplizierten Geräten oder Software-Anwendungen? Das Risiko, dass wir an Bedürfnissen und Vorlieben vorbeientwickeln ist immens, auch (und gerade dann) wenn wir das Gefühl haben, das alles einfach und offensichtlich wäre.

Als Mittel gegen Empathie-Lücken und subjektive Validierungen bleibt am Ende nur eine Möglichkeit: Vertreter der Zielgruppe müssen möglichst früh als Tester und Feedback-Geber in den Entwicklungsprozess eingebunden werden. Onsite Custumer in XP, MVPs in Lean Startup, Sprint Reviews in Scrum und viele ähnliche Konzepte wurden aus genau diesem Grund erfunden. Nur so lässt sich feststellen, ob die eigenen Annahmen stimmen oder nicht.

Mit seinen Büchern Lean from the Trenches und Scrum and XP from the Trenches ist Henrik Kniberg vor langer Zeit bekannt geworden, da liegt es nahe das Benennungsmuster weiterzubenutzen, in diesem Fall als Agile Product Design from the Trenches (mal sehen ob daraus auch noch ein Buch wird).

Inhaltlich geht es in diesem Vortrag darum, wie bei Minecraft (seinem aktuellen Arbeitgeber) Produktentwicklung stattfindet. Nicht revolutionär neu, aber auf jeden Fall ist es interessant zu sehen wie die Ideen von Agile und Lean Startup dort angewandt werden.

Bild: Wikimedia Commons / Fred Romero - CC BY 2.0

Da die anekdotische Evidenz auf der viele Berater-Ratschläge beruhen, eine recht dünne Grundlage für Entscheidungen sein kann, ist es um so willkommener, wenn jemand seine Aussage auf Basis einer soliden Datenbasis macht. In diesem Fall ist es einmal mehr der Oxford-Professor Bent Flyvbjerg, dessen Forschung ich ja von Zeit zu Zeit bereits zitiert habe. Seine neuesten Erkenntnisse hat er in einem Buch zusammengefasst, das den schönen Namen How Big Things Get Done trägt.

Das Thema des Buches ist sein Forschungsschwerpunkt, das Scheitern und Gelingen grosser Projekte, wobei "gross" hier eine weite Spanne umfasst. Behandelt werden riesige Vorhaben wie das der Bau des Guggenheim-Museum in Bilbao oder das Drehen eines Hollywood-Films, aber auch relativ kleine wie die (spektakulär aus dem Ruder gelaufene) Renovierung einer Küche in einem New Yorker Wohnhaus. Insgesamt hat er tausende untersucht, und in ihnen macht er zwei Grundmuster aus.

Scheiternde Projekte zeichnen sich für Flyvbjerg durch ein Vorgehen aus, dass er "thinking fast, acting slow" nennt, und bei dem ein wenig durchdachter Plan zu ständigen Umsetzungsproblemen führt. Umgekehrt führt "thinking slow, acting fast", also ein sorgfältiges Planen, zu einer schnellen und problemlosen Umsetzung. Aber bedeutet das etwa, dass er durch seine Forschung die Überlegenheit eines Wasserfall-Vorgehens bewiesen hat? Nun, nicht ganz.

Gute Planung im Sinn von thinking slow zeichnet sich laut seinem Buch dadurch aus, dass sie bereits in sich iterativ angelegt ist und in kurzen Zyklen versucht, Annahmen und Hypothesen zu validieren. Als Methoden mit denen das stattfinden kann, nennt er neben Klassikern wie Coputer-aided Design und Lean Startup auch eher unbekannte wie das Pixar-Planning auch der gleich benannten Firma. Diese Vorgehensweisen entsprechen eher agilem Vorgehen als Wasserfall.

Ebenfalls einem agilen Ansatz entsprechend ist die Art der Umsetzung, die regelmässig in Fällen von thinking slow, acting fast zu finden ist: Modularität. Wenn statt auf einen Big Bang-Release darauf hingearbeitet wird, dass viele kleine, bereits für sich Mehrwert stiftende Liefergegenstände erzeugt werden, dann wird das Projekt erfolgreicher. Und Flyvbjerg erklärt das nicht nur am Beispiel von Software, sondern auch anhand von Hochhäusern, U-Bahnen und Satelliten.

Für alle die seinen Erkenntnissen nicht folgen wollen zeigt er deutliche Konsequenzen auf. Eine der von ihm aufgeführten Statistiken besagt zum Beispiel, dass 18 Prozent aller IT-Projekte die geplanten Kosten um mehr als 50 Prozent überschreiten, dass in dieser Gruppe die Überschreitung im Durchschnitt (!) aber bei 447 Prozent liegt (!). Wenn es schief geht, dann richtig. [Siehe dazu auch seinen Artikel The Empirical Reality of IT Project Cost Overruns]

Um kein Missverständnis entstehen zu lassen, How Big Things Get Done ist keine Buch über Agile Vorgehensmodelle (der Begriff Agile kommt kein einziges mal vor), es zeigt aber empirisch validiert auf, dass viele Grundprinzipien auf denen agiles Arbeiten aufbaut eher zu erfolgreichen Projekten führen als solche die eher klassisch durchgeführt werden. Alleine, dass das aus einer externen Perspektive bestätigt wird, macht das Buch zu einem, dass man auch ausserhalb der Agilen Filterblase empfehlen kann.

Bild: Flickr / Cory Doctorow - CC BY-SA 2.0

Noch einmal einige Gedanken zum Thema Zertifizierungen, beziehungsweise zu ihrem Ursprung in der Frühzeit der agilen Bewegung. Ich selbst bin ja deutlich zu jung um die noch miterlebt zu haben, allerdings gibt es glücklicherweise einige Leute die damals dabeigewesen sind und heute davon erzählen können, unter ihnen Jim Highsmith, einen der Verfasser des agilen Manifests. In seinem Blog hat er einen Eintrag verfasst, der auf einen eher unbekannten Aspekt hinweist.

Ihm zufolge hatte der damals noch recht junge Beruf des Software-Entwicklers in den 80er und 90er Jahren das Problem, dass er von anderen, etablierteren Berufsgruppen noch nicht als professionell und gleichwertig angesehen wurde. Um das auszugleichen strebten viele Entwickler nach Zertifizierungen, die nach dem Vorbild von denen der Wirtschaftsprüfer oder Ingenieure gestaltet waren und ihnen den Anschein geprüfter Professionalität verleihen sollten.

Bedenkt man, dass die verschiedenen agilen Frameworks zum Zeitpunkt ihrer damaligen Entstehung fast ausschliesslich in der Software-Entwicklung im Einsatz waren, wirft das auf die ersten agilen Zertifizierungen ein ganz anderes Licht als das heute übliche. Man kann davon ausgehen, dass sie genau wie die ebenfalls damals entstandenen verschiedenen Software-Zertifizierung dem Zweck dienten, unter Beweis zu stellen, dass auch die IT ein seriöses Berufsfeld war.

Hat man diesen Zusammenhang erst erkannt, sieht man ihn auch an einer anderen Stelle. Ab dem Jahr 2000 haben sich die Berufe des Scrum Masters (und später des Agile Coaches) deutlich gewandelt und werden heute immer seltener mit Software-Entwicklern besetzt. Eine Folge dieser Entwicklung ist das häufige Auftreten des Impostor-Syndroms, d.h. die technikfernen Personen stellen ihre Eignung für ihr technisches Umfeld in Frage. Auch als Kompensation dieser Komplexe lassen Zertifikate sich verstehen.

Sowohl für den einen als auch für den anderen Fall gilt aber etwas Weiteres, das Highsmith in seinem Blogartikel feststellt: auf den ersten Blick mögen die IT- und Agile-Zertifizierung vergleichbar wertvoll erscheinen wie die der älteren Berufe, bei näherer Betrachtung ist das aber fraglich. Während in denen nämlich unter Beweis gestellt wird, dass bestimmte Fähigkeiten in der Anwendung von Wissen gegeben sind, wird im IT- und Agile-Bereich im Wesentlichen Theorie abgefragt.

Zusammen mit den später entstandenen Kommerzialisierungs-Exzessen des agil-industriellen Komplexes (der z.T. nur noch die Zahlung der Lizenzgebühren und einen Multiple Choice-Test zur Zertifizierungs-Voraussetzung macht) hat diese hohe Theorielastigkeit dazu beigetragen, dass die Zertifizierungen von Atlassian, SAFe, ISTQB, Scrum Alliance & Co niemals als gleich hochwertig angesehen wurden wie z.B. die des AICPA, des NCEES oder des TÜV, nach deren Vorbild sie ursprünglich gestaltet sein sollten.

Der Gedanke drängt sich auf, ob eine mit echten Qualitätskontrollen und Erfahrungs-Nachweisen verbundene Zertifizierung nicht auch heute noch eine gute Idee sein könnte. Die Softwareentwicklung hat sich zwar mittlerweile als seriöser Beruf etabliert, bei den "agilen Berufen" tragen die nicht existenten Eintrittshürden aber bis heute dazu bei, dass ihre professionelle Natur immer wieder in Frage gestellt wird (und das in vielen Fällen zu Recht).

Diese Professionalität durch (diesesmal praxisrelevante) Zertifizierungen zu belegen wäre heute vermutlich ähnlich sinnvoll wie damals in den 80er und 90er Jahren. Es wird spannend sein zu beobachten, ob in absehbarer Zeit ein Bedarf dafür entstehen wird.

Grafiken: Freepik / Pikisuperstar - License

Eine der beissendsten Persiflagen von nicht fertig durchdachtem Vorgehen findet man in der Fernsehserie South Park, in der Folge Gnomes. Auf der Suche nach ihren verschwundenen Unterhosen entdecken die Hauptfiguren hier eine Gruppe Gnome, die einen grossen, dreistufigen Plan verfolgen. Stufe eins ist das Stehlen der Unterhosen, Stufe drei ist geschäftlicher Erfolg, wie die verbindende Stufe zwei aussehen soll, ist noch unklar. Obwohl diese Lücke allen bewusst ist, wird der Plan weiter verfolgt.

Da Angestellte von Grossorganisationen in dem Unterhosen-Plan die Unsinnigkeit vieler Vorgänge ihrer eigenen Umgebung wiedererkennen, ist er mit der Zeit zu einem Meme geworden, dessen häufige Zitierung ein starker Indikator dafür ist, dass in einem aktuell vorangetriebenen Vorhaben keine Verbindung zwischen den aktuellen Massnahmen und dem angestrebten Ziel erkennbar ist. Auch in agilen Transitionsprogrammen findet das immer wieder statt, und zwar vor allem in einer Konstellation.

Ein "agiler Unterhosen-Plan" liegt regelmässig dann vor, wenn zu Beginn ausführlich (und gegebenenfalls ausschliesslich) daran gearbeitet wird das Mindset der Mitarbeiter zu verändern, so dass ein "agiles Mindset" entsteht. Selbst wenn wir jetzt nicht näher auf die Frage eingehen ob man das Mindset anderer Menschen überhaupt ändern kann (zweifelhaft) und unterstellen, dass alle das Selbe darunter verstehen (auch zweifelhaft) - wie das zu einer agilen Produktentwicklung führen soll bleibt fast immer offen.

Weist man auf diese Lücke hin bekommt man häufig die Erklärung, dass ein agiles Mindset alleine deshalb zu Verbesserungen führt, weil jeder der es hat sich automatisch besser verhält. Allerdings ist das wenn überhaupt nur in Kleinorganisationen richtig, in grösseren Organisationen sorgen organisatorische Silos, Überregulierung, Ressourcen-Überoptimierung, Customer-Vendor-Beziehungen, Code Ownership und ähnliche Phänomene dafür, dass man gar nicht beschliessen darf das eigene Verhalten zu ändern.

Diese Begrenzungen des eigenen Handlungsspielraums sind auch jedem klar, der in grösseren Organisationen arbeitet (man wird schliesslich regelmässig auf sie hingewiesen). Bemerkenswerterweise ändert das aber nichts daran, dass man trotzdem immer wieder auf die agilen Unterhosen-Pläne trifft, in denen davon ausgegangen wird, dass nach der Herstellung des agilen Mindsets schon irgendetwas noch Unbekanntes passieren wird, was dann die agile Transformation erfolgreich macht.

Eine naheliegende Erklärung dafür wäre Esoterik, was leider öfter man man denken sollte stimmt, aber in vielen Fällen zu kurz greifen dürfte. Wahrscheinlicher ist, dass den Beteiligten einfach nicht klar ist wie sonst Veränderungen Richtung Agilität funktionieren könnten. Change Management-Abteilungen stecken viel zu oft noch in sehr klassischen Ideen von Veränderungsbegleitung fest und auf den unteren Ebenen fehlen einfach Erfahrungen und Systemverständnis, da sie dort nie vermittelt wurden.

Das muss allerdings nicht so bleiben. Dem Change Management kann man die Ideen von iterativem, incrementellem und adaptivem Arbeiten näherbringen den unteren Hierarchie-Ebenen kann man erklären wie das Systemdesign bestimmte Verhaltensweisen möglich, wahrscheinlich oder unmöglich macht und an welchen Stellen es notwendig ist dieses Design zu verändern, wenn man mit einer individuellen Mindset-Getriebenheit nicht vor Wände laufen will.

Dort wo das stattgefunden hat und angenommen wurde, werden agile Unterhosen-Pläne deutlich seltener werden, und das alleine deshalb, weil ab diesem Moment das Arbeiten an dem Mindset der einzelnen Personen sicher nicht mehr die erste Phase von Veränderungsprogrammen sein wird. Mit grosser Wahrscheinlichkeit wird diese Idee sogar ganz verschwinden, samt der Lücke, die bis dahin in der folgenden Phase zwei geklafft hat.

Bild: Pexels / Yan Krukau - Lizenz

Wie stark die "agile Bewegung" über ihr ursprüngliches Umfeld in der Produktentwicklung von Software (und Hardware) hinausgewachsen ist lässt sich an einem besonderen Phänomen beobachten: es gibt mittlerweile die ersten Hypes und Buzzwords die zu diesen Ursprungsgebieten keinen Bezug mehr haben und dort auch weitgehend unbekannt sind. Ein Beispiel dafür aus den letzten Jahren ist die "Agile Workforce". Was soll das jetzt schon wieder sein?

Zunächst kurz zur Begriffserklärung: "Workforce" wird meistens mit "Belegschaft" übersetzt, was aber die Bedeutung nicht zur Gänze wiedergibt. "Arbeitskraft" kommt ihr schon näher, ist im Deutschen aber bereits anders belegt. Die sinngemässe Übersetzung wäre in etwa "die Gesamtgruppe aller Arbeiter", woraus sich ergibt, dass "Agile Workforce" eine Belegschaft beschreibt, die zu agilem Arbeiten in der Lage ist. Der eine oder andere wird jetzt bereits ahnen, wo diese Idee her kommt.

Fast alles was man bei einer Literatur-Recherche zu Agile Workforces findet kommt aus dem HR-Bereich, und das mit einem besonderen Schwerpunkt auf Personalentwicklung. Es handelt sich dabei also nicht um eine Zustandsbeschreibung, sondern um ein Zielbild, an dessen Erreichung Personal- und Learning & Development-Abteilungen sowie externe Dienstleister arbeiten wollen, um so ihren Beitrag dazu zu leisten, dass ihre Unternehmen oder Kunden agil arbeiten können.

Der Nebel lichtet sich durch diese Erkenntnis etwas, einiges bleibt aber unklar. Was genau kann denn im Rahmen der Personalentwicklung gemacht werden, um die Belegschaft zu agilem Arbeiten zu befähigen? Wer in der Literatur nach Antworten hierauf sucht, wird sich erstmal durch eine Buzzword-Wolke kämpfen müssen, in der in verschiedenen Konstellationen Begriffe wie Mindset, Kultur, Werte und Prinzipien aufgezählt und als notwendig bezeichnet werden. Nicht falsch, aber auch nicht hilfreich.

Klarer wird es wenn man sich vor Augen hält, dass es zwei Dimensionen von Personalentwicklung gibt: Positionsorientiert und Potentialorientiert. In der ersten Dimension werden einzelne Personen auf bestimmte Aufgaben vorbereitet, z.B. die eines Product Owners oder DevOps Engineers. Das kann durch Aus-, Fort- und Weiterbildung geschehen, alternativ auch durch gezielte Rekrutierungen. Hier finden oft klassische HR-Techniken Verwendung, etwa Assessment Center und Schulungen.

Schwerer tun sich die meisten Firmen mit der zweiten, potentialorientierten Dimension. Die findet statt wenn es noch nicht um die Besetzung bestimmter Positionen geht, sondern darum, unternehmensweit einen Talentpool an qualifizierten Mitarbeitern aufzubauen. Im Fall der angestrebten Agile Workforce sollen dabei möglichst viele Mitarbeiter auf einer abstrakten Ebene verstanden haben was Agilität bedeutet, um dieses Wissen in allen potentiell möglichen Rollen anwenden zu können.

In der Praxis tritt diese Wissensvermittlung dann meistens in Form von Workshops zu Kultur und Werten auf, was auch grundsätzlich richtig ist. Schliesslich handelt es sich gerade bei diesen beiden Phänomenen um organisationsweit vorhandene Faktoren, die in praktisch jeder denkbaren Position Wirkung entfalten können. Vor allem in Umfeldern, in denen bereits agile Frameworks im Einsatz sind können Sie sogar wesentlich dazu beitragen, dass diese funktionieren wie gedacht.

Wie derartige Workshops aussehen können ist nochmal ein Thema für sich, grundsätzlich sollte aber vermittelt werden was Kultur und Werte sind, wie sie vor allem dort wo es keine (oder widersprüchliche) Prozessvorgaben gibt den Arbeitsalltag prägen und wie sie gestaltet sein müssen um sicherzustellen, dass die von den agilen Frameworks bewusst offen gelassenen Lücken im Einzelfall so gefüllt werden, dass agiles Arbeiten möglich ist.

Beide Personalentwicklungs-Dimensionen sind aber auch nicht ohne Risiko: überall dort wo nur für die Zukunft geschult oder geworkshopt wird, werden die vermittelten Inhalte durch ihre Gegenläufigkeit zur noch gelebten Praxis als Paradoxe Kommunikation wahrgenommen und ggf. abgelehnt werden. Und falls die Durchführung von Schulungen selbst zum Messkriterium für die Schaffung einer Agile Workforce wird, ist ein Abkippen in den agil-industriellen Komplex hochwahrscheinlich.

Das heisst natürlich nicht, dass man die Arbeit an der Herstellung einer Agile Workforce unterlassen sollte, man sollte es aber (wenig überraschend) selbst auf Basis agiler Prinzipien tun, also in kurzen Zyklen, ohne zu langen Planungsvorlauf und mit regelmässigen Validierungen und Feedbackschleifen. Dann kann es zu einem "Learning by doing" kommen, und zwar nicht nur bei der zu agilisierenden Belegschaft, sondern auch bei den damit beschäftigten HR- und Learning & Development-Abteilungen selbst. Ein nicht zu unterschätzender Seiteneffekt.

Zu den bekanntesten Erklärvideos im Umfeld von (nicht nur) Scrum gehört Agile Product Ownership in a Nutshell, das von mittlerweile mehr als zehn Jahren von Henrik Kniberg veröffentlicht wurde. Es wurde immer wieder angemerkt, dass etwas Vergleichbares auch für den Scrum Master gut wäre. Jetzt endlich hat sich jemand der Sache angenommen:

Selbst wenn Geoff Watts, der dieses neue Video erstellt hat, einen eigenen Stil hat, passen The Scrum Master in a Nutshell und Agile Product Ownership in a Nutshell erstaunlich gut zusammen. Was jetzt noch fehlt wäre ein In the Nutshell-Video für die dritte Rolle Scrum, die Entwickler. Mal sehen wann es kommt.