On Lean and Agility

Bild: Pixabay / Mohamed Hassan - Lizenz

Jedes mineralische Aufblitzen in diesem in Nacht gehüllten Berg ist eine Welt für sich. Der Kampf gegen Gipfel vermag ein Menschenherz auszufüllen. Wir müssen uns Sisyphos als einen glücklichen Menschen vorstellen.

Albert Camus, Der Mythos des Sisyphos

• Das bisherige Redaktionssystem Content Entry war zu einer Zeit selbst gebaut worden als es auf dem Markt kein gutes CMS zu kaufen gab (vermutlich um das Jahr 2000 herum, von den ursprünglichen Entwicklern dürfte damit kaum noch einer da sein)
• Moderne App-Development-Frameworks waren nicht einsetzbar (was es schwer gemacht haben dürfte neue Entwickler an Bord zu holen)
• Das alte System war nicht lauffähig auf aktuellen Browsern, weshalb mit einer alten Version des Internet-Explorers gearbeitet werden musste (für die es vermutlich keinen Hersteller-Support mehr gab)
• Die erstellten Websites waren nicht responsiv (im Zeitalter der mobilen Internetnutzung ein Problem)
• Die Mobile Apps hatten eine überproportionale Dateigrösse (was für Probleme bei Download und Speicherplatz sorgt)
• Änderungen, z.B. im strategisch wichtigen Bezahlbereich, waren nur noch schwer zu implementieren (dadurch behindert die IT die Geschäftsentwicklung)
• Selbst im Normalbetrieb waren die Systeme fehleranfällig (also ressourcenbindend und teuer)
• Andere Medien des Unternehmens (Manager Magazin, Bento) liefen auf eigenen CMS-Varianten, wodurch sich Instandhaltung- und Erneuerungsaufwände nochmal multiplizierten 

Bild: Flickr / Mr. Blue MauMau - CC BY 2.0

1. Scrum nicht komplett in Grossbuchstaben schreiben (und schon gar nicht mit Punkten dazwischen)

2. Seriöse Sprache benutzen

3. Methodische "Anpassungen" kommunizieren

4. Keine Selbstverständlichkeiten aufzählen

5. Klar sagen welche agilen Praktiken schon eingesetzt werden und welche noch nicht

6. Keine technischen Skills verlangen (auch nicht für Jobs in IT-Teams)

7. Herausforderungen ehrlich benennen

8. Kommunizieren ob es verteilte Teams und Heimarbeit gibt

9. Klar machen ob es ein Scaled Agile-Kontext ist

10. Keine Zertifizierungen verlangen

Bild: Unsplash / Dayne Topkin - Lizenz

• Mary Poppendieck: Grown-Up Lean

  Den längsten Essay gleich zu Beginn, und gleichzeitig auch den optimistischsten. Belegt mit vielen Beispielen (Toyota, Linux, Google, Amazon, SpaceX, ING, Spark NZ) schlägt Mary Poppendieck den grossen Bogen von den 80ern bis heute und zeigt auf, dass das was wir heute als Agile oder DevOps bezeichnen seine Ursprünge im Lean Management der japanischen Fabriken des 20. Jahrhunderts hat. Gleichzeitig wirkt sie auch einem verbreiteten Missverständnis entgegen, nämlich dem, dass es in Lean in erster Linie um Effizienzsteigerung, bzw. um die Vermeidung nicht zielführender Tätigkeiten ginge. Als zentrales Element stellt sie die Humanzentrierung heraus, also das in den Mittelpunkt Stellen des Mitarbeiters. Durch Product Ownership, durch dienendes Management, durch die Demokratisierung der Produktionsprozesse. Und als wäre all das nicht schon lesenswert genug beginnt sie ihre Ausführungen mit einer Anekdote aus Deutschland.

• Gunter Dueck: How to innovate if you must

  Trotz des englischen Titels ein deutscher Text, und mal wieder ein echter Dueck. Mit im Verlauf des Artikels zunehmendem Sarkasmus seziert er die Fehler, die die Konzerne seit 30 Jahren bei der Digitalisierung und Agilisierung ihres Geschäfts machen. Zusammengefasst: viel Fassade, viel Hochmut, wenig Mut, wenig Bereitschaft sich auf Neues einzulassen. Das ist nicht falsch (und wird auch hier mit vielen bekannten und neuen Beispielen unterfüttert), lässt aber unerwähnt, dass selbst Konzernvorstände weniger frei in ihren Entscheidungen sind als man denken sollte. Von den Aktionären bis zum Betriebsrat will so ziemlich jeder mitreden. Grundsätzlich hat Dueck aber Recht - ein bisschen mehr ginge immer. Und die Anekdote, dass IBM Google Maps hätte vorwegnehmen können, es aber nicht gemacht hat, hat Potential zum Klassiker.
  

• Steve Denning: Why Budgeting Kills Agile And Innovation

"Die Budgetierung stellt häufig einen der letzten - und grössten - Stolpersteine auf dem Weg zu einer wirklich agilen Organisation dar", lautet gleich der erste Satz von Steve Dennings Streitschrift. Trotz dieses Auftaktes geht es dann aber strukturiert durch verschiedene Argumentationsphasen. Die historischen Hintergründe, die theoretisch möglichen Vorteile klassischer Budgetprozesse, die in der Realität auftretenden Nachteile und zuletzt die grosse Alternative: Beyond Budgeting. Geschrieben ist das aus einer US-amerikanischen Perspektive, aus einer deutschen/europäischen dürfte es sogar noch schlimmer sein. Die Kombination aus übertriebenem Taylorismus (die Mitarbeiter sind so spezialisiert, dass sie nur noch an einer spezifischen Stelle einsetzbar sind) und einem de facto Kündigungsschutz führt dazu, dass häufig nur noch der Schein von Handlungsfähigkeit entsteht. in Wirklichkeit wird das Geld jedes Jahr auf die selbe Art ausgegeben - das Gegenteil von Business Agility..

• Alistair Cockburn: Agile is not dead, quite the opposite

  In der Produkt-, Projekt- und Prozessmanagement-Filterblase kann man leicht den Eindruck gewinnen, dass die agile Bewegung die Gegenwart dominiert, vielleicht sogar so sehr, dass es zu Sellout und Overkill kommt. Die Zahlen die Alistair Cockburn anführt legen etwas anderes nahe: angesichts von hunderten Millionen von Menschen in der Wissensarbeit (davon viele aber keineswegs alle in der IT) fallen die wenigen Millionen die bereits mit dem Thema Agile in Berührung gekommen sind kaum ins Gewicht. Der Bewegung steht ihre eigentliche Wachstumsphase also noch bevor. Dass das in der Öffentlichkeit oft anders dargestellt wird macht Cockburn daran fest, dass diese Mengenverteilung nicht allen bewusst ist. Als die Untergangspropheten der Agilität sieht er jene, die schon vor 10 und mehr Jahren begonnen haben so zu arbeiten. Für die scheint sich der Lebenszyklus dieser Idee dem Ende entgegenzuneigen. Dass sie aber keineswegs repräsentativ sind sollte man im Hinterkopf behalten. Ein wertvoller Beitrag, den man sich in Erinnerung rufen sollte wenn mal wieder jemand "Agile is dead" propagiert.

• Yuri Malishenko: Agile transformation is a bad story and here is why

  Ein lesenswerter Text, hinter dem sich mehr verbirgt als man anhand der Clickbait-Überschrift ahnen könnte. Basierend auf dem Actantial Model von Algirdas Julien Greimas versucht Yuri Malishenko darzustellen mit welchen Betrachtungsweisen und Erwartungshaltungen sich verschiedene Gruppen (Management, Agile Coaches, Mitarbeiter) einer agilen Transition nähern. Die wenig überraschende Erkenntnis: sie sind nicht identisch sondern weichen z.T. stark voneinander ab. Das Interessante daran: mit Hilfe des Actantial Model ist es möglich diese Interessenkonflikte aufzuzeigen und zu visualisieren. Im Fall strauchelnder Veränderungsvorhaben könnte das ein wertvolles Werkzeug sein um aufzuzeigen wo die Beteiligten aneinandervorbeireden.

• Stefan Kühl: Zur Entstehung, Durchsetzung und Regulierung von Regelabweichungen

  Ich muss mich wohl korrigieren. Vermutlich hat nicht Mary Poppendieck den längsten Beitrag in dieser Liste sondern Stefan Kühl. Dass das nicht ganz klar zu sagen ist liegt daran, dass ein nicht unwesentlicher Teil des Textes aus dem Quellenverzeichnis besteht, was ein deutlicher Hinweis darauf ist, dass hier wissenschaftlich gearbeitet wurde. Die in diesem Zusammenhang behandelte zentrale These ist die, dass Gesetzesbrüche und Regelverstösse in Organisationen meistens nicht auf Schlampigkeit oder Indifferenz zurückgehen sondern das Ergebnis von rationalem Abwägen sind. Die Verstösse werden nur in dem Rahmen betrieben, der eine Erkennung oder Sanktionierung unwahrscheinlich macht - und dieser Rahmen wird durch ständiges Ausprobieren erkundet und ausgereizt. Im Grunde ein Inspect & Adapt mit dem Ziel einer möglichst effektiven brauchbaren Illegalität. Bedingt durch diese Brauchbarkeit ergibt sich implizit eine weitere Dimension der Erziehung zur Normverletzung: die Etablierung der Abweichung von Regeln als organisationskulturelle Erwartung. Führt man sich die in aller Konsequenz vor Augen kann einem schwindelig werden.

• Cliff Berg: SpaceX’s Use of Agile Methods

  Die agile Skalierung dürfte mittlerweile als Königsdisziplin der Agilität abgelöst worden sein. Die neue Meisterklasse ist die agile Produktion von komplizierter Hardware mit eingebetteter Software. In der heutigen Form erst durch den 3D-Druck möglich geworden entstehen hier in kurzen Zyklen Produkte deren Komplexität und Disruptivität vor kurzem noch unvorstellbar gewesen wäre. Dass Cliff Berg als Paradebeispiel das Raumfahrt-Unternehmen SpaceX vorstellen kann fügt dieser Entwicklung eine zusätzliche Pointe hinzu: "Rocket Science" gilt im englischen Sprachraum als Synonym für extrem anspruchsvolle Aufgaben - und jetzt gibt es eine Firma die in diesem Bereich nicht nur führend ist, sondern das erst durch den Einsatz von MVPs, iterativ-incrementellem Arbeiten und flexibel konfigurierbaren Delivery Pipelines werden konnte.
  

• Tim Themann: Von Methoden, METHODEN und MeTooden

  Eine schöne Differenzierung. Angelehnt an Tom DeMarco und Timothy Lister unterscheidet Tim Themann zwischen Methoden (Vorgehensmodellen), METHODEN (dogmatischen Regelwerken) und MeTooden (dem Versuch ein an anderer Stelle erfolgreiches Vorgehen zu kopieren). Letzteres kann leicht in Cargo Cult abgleiten, was von Theman nochmal ausdifferenziert wird: Mismatch von Lösung und Problem, versehentlich falsche Übertragung, Unterschätzung des Einführungsaufwandes, ggf. Toolfixierung und Kontaminierung der ursprünglichen, eigentlich guten Idee. Ich würde noch den Survivor Bias hinzufügen, aber das ist nur ein Detail. Was den Charme der MeToode ausmacht ist vor allem der Begriff, der jedem der ein bisschen Englisch kann sofort intuitiv verständlich sein wird.

Bild: Unsplash / Compare Fibre - Lizenz

• Jason Little: Boundaries, Interventions, and Baby Ducks

Zum Ende des Jahrzehnts reflektiert Jason Little über die Unternehmenstransformationen die er in dieser Zeit begleiten durfte. Dabei identifiziert er drei Konzepte die man sich bei derartigen Vorhaben vor Augen führen sollte:

• Interventions-Punkte - Es gibt gute und schlechte Momente um Veränderungen anzustossen. Gut ist z.B. vor oder während der Planung des nächsten Jahres, schlecht unmittelbar danach.
• Einfluss-Sphären - Wo sind Prozesse und Strukturen selbst verantwortet und gestaltbar und wo sind sie es nicht? Und dort wo sie es nicht sind: würde sich der dort verantwortliche an Veränderungen beteiligen?
• Entenküken-Syndrom - Genau wie Entenküken zu den ersten von ihnen wahrgenommenen Wesen eine starke emotionale Bindung entwickeln können Menschen vergleichbare Bindungen zu Programmiersprachen, Management-Ansätzen, etc. entwickeln.
Während die ersten beiden Konzepte weitgehender Common Sense sein dürfte ist das das dritte eines das selten bedacht wird. Eine Gesetzmässigkeit kann man sicher nicht ableiten, einige Überlegungen ist es aber definitiv wert, sowohl in der Organisationsentwicklung als auch in der Selbstreflektion.

• Marcus Raitner: Vorleben und infizieren statt abholen und mitnehmen

  Mehr zum Thema Unternehmenstransformation. Um beim gerade genannten Konzept der Einfluss-Sphären zu bleiben - Change Management kann die offiziellen Prozesse und Vorschriften beeinflussen, die inneren Motivationen und Verhaltensmuster dagegen nicht. Dort wo es versucht wird zeugt schon die Wortwahl von Paternalismus und Entmündigung, etwa dann wenn die Mitarbeiter "mitgenommen" werden sollen. Der von Marcus Raitner bevorzugte Weg sieht anders aus, es ist der "virale Wandel". Um ihn zu starten müssen einzelne kommunikationsstarke und vom Sinn der Veränderungsvorhaben überzeugte Personen gefunden werden, die diese so vorleben, dass andere von sich aus folgen wollen. Die (schwierige) Management-Aufgabe in diesem Modell ist es diese Personen zu finden und in die entsprechenden Positionen zu bringen.

• Sonja Blignaut: Reconceptualising organisations - from complicated machines to flowing streams

  Noch mehr zum Thema Unternehmenstransformation. Sonja Blignaut geht davon aus, dass (produkterzeugende) Organisationen aus nichts anderem Bestehen als aus Wert- oder Handlungsströmen (Flows), die zwar bis zu einem gewissen Grad in bestimmte Richtungen gelenkt werden können, sich aber letztendlich immer den geradesten Weg Richtung Ziel suchen - im Zweifel auch an den offiziellen Prozessen vorbei. Ein interessanter Ansatz, der aber konsequent zu Ende gedacht neue Fragen aufwirft: was passiert mit Einheiten zu denen der Zufluss so verstopft ist, dass der Strom an ihnen vorbeifliesst (→ Thromben und Embolien) und wie kann dafür gesorgt werden, dass an kritischen Stellen Druck nicht zu Ausweichreaktionen sondern zu Gegendruck führt (→ Nicht-Newtonscher Flow)? Auf jeden Fall eine Anregung zum Nachdenken.

• Christiaan Verwijs: Actual stakeholders? Or just your audience?

  Ein Grundlagen-Thema über das zu selten nachgedacht wird: wer sind eigentlich diese Stakeholder mit denen ein agiles Team regelmässig interagieren soll? Ausgehend von dem leider weit verbreiteten Antipattern, dass nur Firmen-interne Kollegen in diese Kategorie fallen versucht sich Christiaan Verwijs an einer besseren Definition. Die von ihm gefundene lautet: "Jeder der etwas zu gewinnen hat wenn das Team gute Arbeit leistet oder etwas zu verlieren hat wenn das nicht der Fall ist". Im Vergleich zur internen Lösung ein deutlich besserer Ansatz, wenn auch einer der immer noch Interpretationsspielraum lässt. Würde beispielsweise eine Audit- oder Revisionsabteilung nach dieser Definition ein Stakeholder sein? Vermutlich läuft es wieder auf die klassische Antwort hinaus - es kommt drauf an.

• Gojko Adzic: Deliberate Side-Products

  Wenn es um die Ursachen der Komplexität von Anwendungen und Produkten geht werden immer die gleichen Gründe genannt. Technischer Wandel, sich ändernde Nutzervorlieben, wachsende Funktionsumfänge, hohe Abhängigkeiten, etc. Was selten genannt wird ist der Wunsch der beteiligten Entwickler innovative oder anspruchsvolle Technologien auszuprobieren. Gojko Adzic beleuchtet von verschiedenen Seiten wie es dazu kommen kann und hat mit seinen "Deliberate Side-Products auch eine Lösung parat. Auch der eine oder andere Agile Coach könnte sich ertappt fühlen, denn auch hier gibt es immer wieder überkandidelte methodische Lösungen, die besser nicht in kritischen Bereichen ausprobiert worden wären.