Kommentierte Links (CIX)

Grafik: Pixabay / Geralt - Lizenz

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

Pavel Samsonov: Design is the art of being wrong safely

Pavel Samsonov zeigt hier einen interessanten Blickwinkel auf die Ergebnisse früher Design Thinking-, Design Sprint und Lean Startup-Phasen auf. Das was in ihnen erzeugt wird, ist fast immer ein falsches Ergebnis, und zwar falsch in dem Sinn, dass es auf Hypothesen basierende Prototypen oder MVPs sind, die per Definition noch gar nicht richtig sein können, da der Product-Discovery-Prozess mit ihnen erst beginnt. Um das nicht nur zu akzeptieren sondern sogar wertzuschätzen sind besondere Unternehmen und besondere Unternehmenskulturen notwendig.

Jeff Patton: Product Vision is Science Fiction

Mit der Produktvision verhält es sich wie mit vielen nicht abschliessend beschriebenen Fachthemen: je mehr Experten man befragt, desto mehr unterschiedliche Antworten bekommt man. Jeff Patton hat zwar nicht die eine Version auf die sich alle einigen werden, dafür aber eine gute: Seine Produktvision beschreibt eine zukünftige Welt, einschliesslich des zukünftigen Produkts und der Zwecke die es dort erfüllt. Ebenfalls wertvoll ist die Abgrenzung die er vornimmt, u.a. zu Business Goal, Wchstumsziel und Mission Statement. Nicht dass diese Dinge schlecht wären, aber es sind eben keine Produktvisionen.

Charity Majors: Deploys Are The ✨Wrong✨ Way To Change User Experience

Agile Software-Entwicklung hat (Überraschung) mit Software zu tun, und zwar nicht nur damit wie sie entwickelt wird, sondern auch damit, wie die fertig entwickelten neuen Funktionen zum Anwender kommen. Der klassische Weg ist der über den sich Charity Majors hier aufregt: durch Deployments, also dadurch, dass sie auf der Produktionsumgebung ausgerollt werden und ab diesem Moment sichtbar und benutzbar sind. Da das bei zusammenhängenden Funktionalitäten doch wieder zu Big Bang-Releases führt, zeigt sie einen besseren Weg auf - Continuous Delivery mit Feature Flags.

Constance Noonan Hadley, Mark Mortensen, Amy C. Edmondson: Make It Safe for Employees to Speak Up - Especially in Risky Times

In diesem Artikel eines ganzen Autoren-Kollektivs geht es um psychologische Sicherheit, genauer gesagt darum, wie man sie auch erzeugen kann, wenn die Gesamtsituation gerade kritisch ist. Gerade dann ist es nämlich wichtig, dass alle Beteiligten sich trauen, Missstände anzusprechen und Verbesserungsvorschläge zu machen; wenn das nicht der Fall ist, kann ein Runaway Projekt eintreten, der die Probleme ausser Kontrolle geraten lässt. Spannend ist, dass hier nicht nur erklärt wird wie psychologische Sicherheit gefördert werden kann, sondern auch weshalb sie häufig nicht gegeben ist.

Phil Norman: Sensenmann - Code Deletion at Scale

Das hier ist ein wirklich innovativer und bemerkenswerter Ansatz. Phil Normans Firma Google hat erkannt, dass eines der grössten Hindernisse für agile Produktentwicklung die Aufblähung des Quellcodes ist, die zu Unübersichtlichkeit, Unberechenbarkeit und Aufwändigkeit von Änderungen führt. Die Lösung ist radikal: ein Programm namens Sensenmann [sic] identifiziert redundanten oder überflüssigen Code und löscht ihn automatisch. Das kann natürlich nur bei hoher Test- und Monitoring-Abdeckung funktionieren, ist dann aber hocheffektiv.

Trisha Gee: Why I prefer trunk-based development

Irgendwann habe ich mal über das Problem von Branching und Merging geschrieben, mit der Kernaussage, dass Branches keine gute Idee sind. Trisha Gee führt das mit deutlich mehr Detail und Sachverstand aus und hat auch eine Lösung parat wie es besser geht: durch Trunk-based Development (das kontrollierte Einchecken von neuem Code direkt in den Master Branch) wird höhere Geschwindigkeit und Reaktionsfähigkeit erreicht, höhere Stabilität, bessere Zusammenarbeit, bessere Entwicklungspraktiken und geringere technische Schuld. Es lohnt sich also, darauf hinzuarbeiten.

Richard Seroter: Shifting left is for suckers. Shift down instead

Noch einmal ein Bericht von Google. Laut Richard Seroter wird die Idee der Fullstack- und T-Shape-Skills, durch die Personen an möglichst vielen Themengebieten mitarbeiten können, dort eher kritisch gesehen, da sie das Risiko eines zwar breiten, dafür aber nicht besonders tiefgehenden Wissens mit sich bringt. Seine Alternative nennt er Shift Down, und sie besteht daraus, dass den Entwicklern in seiner Firma möglichst viel Arbeit abgenommen wird indem sie in einfach bedienbare Plattform-Services ausgelagert wird. So kann die kognitive Last gering bleiben und die Expertise hoch.

Anthony Mersino: Should We Fire All the Agile Coaches?

Einer der interessanteren Trends des letzten Jahres sind die grossflächigen Entlassungen von Agile Coaches und Scrum Mastern, die in mehreren deutschen und amerikanischen Konzernen stattgefunden haben. Viele der Reaktionen darauf beschränken sich auf ein marktschreierisches füt tot erklären der Agilität, es gibt aber auch differenzierte Analysen. Diese hier von Anthony Mersino gehört in die zweite Gruppe. Verkürzt gesagt zeigt er Gründe auf, wegen denen diese Rollen als nicht mehrwertstiftend wahrgenommen und daher in Krisenzeiten abgebaut werden.

Bill Lescher: Lessons from the U.S. Navy on Building a Culture of Learning

Und noch einmal ein Praxis-Bericht, diesesmal nicht von Google sondern von der amerikanischen Marine, bzw. deren Programm zur Verbesserung der Einsatzfähigkeit ihrer Flugzeuge. Vieles davon kennt man aus agilen Teams, z.B. das Delegieren von Verantwortung, das datengetriebene Vorgehen und das Suchen nach Lösungen statt nach Schuldigen. Darüber hinaus gibt es in Bill Leschers Artikel aber auch interessante neue Aspekte, wie z.B. den, dass dort bei den Beurteilungen der verantwortlichen Personen das Systemverständnis und die Prognose-Genauigkeit ähnlich wichtig sind wie die Erfolgsquote.

Barry Overeem, Christiaan Verwijs: What 3 Years Of Our Own Scientific Research Brought

Ein Hoch auf die Wissenschaft! Dass zu vieles von dem, was Agile Coaches und Scrum Master für richtig halten, eher auf anekdotischer Evidenz als auf überprüfbaren Daten beruht wird oft beklagt - Barry Overeem und Christiaan Verwijs tun etwas dagegen. Zusammen mit der Universität Aalborg haben sie einige der gefühlten Wahrheiten einer wissenschaftlichen Überprüfung unterzogen, mit zum Teil überraschenden Ergebnissen. Von derartigen Untersuchungen bräuchte es deutlich mehr.

Kommentierte Links (CVIII)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Stay Saasy: Practical Ways To Increase Product Velocity

Die Velocity, also die Durchsatzmenge erledigter Arbeit pro Zeiteinheit, ist häufig ein kontroverses Thema, da viele Teams darin ein Werkzeug sehen, mit dessen Hilfe sie in die Akkordarbeit getrieben werden sollen. Das kommt auch tatsächlich vor, allerdings nur dort, wo das "schneller Arbeiten" als einziges Mittel gesehen wird, die Velocity zu erhöhen. Dass eine Steigerung auch durch Arbeit am System, an den Kommunikationswegen oder an der Technologie erreicht werden kann, wird zu häufig übersehen. Um so besser, dass Stay Saasy einiges davon zusammengefasst hat.

Thomas Knüwer: Wie bekommen Unternehmen Mitarbeiter zurück ins Büro?

Man bekommt es aus fast allen Firmen mit - die Versuche, die Mitarbeiter zu regelmässiger Anwesenheit im Büro zu überreden, haben entweder nur geringe Erfolge oder erzielen diese mit dem Preis von Unzufriedenheit und Konflikten. Die Lösung, die Thomas Knüwer präsentiert, um die Motivation für die Präsenzarbeit zu erhöhen, scheint zuerst offensichtlich: man sollte die Büros so gestalten, dass die Menschen gerne in ihnen arbeiten. Der entscheidende Punkt ist seine These (die ich teile): dafür müssten die Grossraum-Büros wieder in kleinere Einheiten umgebaut werden, so wie sie früher waren.

John Cutler: The Predictability Trap

Das was John Cutler hier ausspricht, dürfte für viele klassisch sozialisierte Manager hart zu schlucken sein: je mehr man Umsetzungsteams dazu drängt, prognostizierte Lieferzeitpunkte und -umfänge einzuhalten, desto geringer ist die Wahrscheinlichkeit, dass das dauerhaft gelingen wird. Denn gerade das, was vernachlässigt wird, wenn alle Energie in die pünktliche Fertigstellung des nächsten Features fliessen muss, ist das was auf Dauer für Lieferfähigkeit sorgt: Aufräum- und Reparatur-Arbeiten am Prozess, an der Technik und am Produkt.

Kent Beck: Canon TDD

Gerade bei den einfachsten Begriffen können mitunter die grössten Missverständnisse auftreten. Irgendwie erscheint alles offensichtlich und naheliegend, so dass man die Dinge einfach tun kann ohne darüber nachzudenken - und ohne es zu merken ist man plötzlich in der falschen Richtung unterwegs. Kent Beck ist aufgefallen, dass das auch beim von ihm entwickelten Test Driven Development (TDD) immer wieder der Fall ist. Aufgrunddessen hat er die Idee und das Vorgehen noch einmal kompakt zusammengefasst, so dass jeder sich mit dem Ansatz im Original vertraut machen kann.

Mike Cohn: How Much Can You Really Tinker with Scrum?

Ein grosser Klassiker. Welche Bestandteile von Scrum sind optional und können weggelassen werden und ohne welche geht es nicht? Mike Cohn beantwortet diese Fragen nicht nur (zumindest anhand einiger der am häufigsten gefragten), sondern er tut es auch noch multimedial - man kann seine Antworten entweder lesen oder als Kurzvideo ansehen und anhören.

Agile Night Xmas

Die Weihnachtsfeiertage sind viel zu beschaulich für steile Thesen, tiefschürfende Analysen oder methodische Meta-Betrachtungen. Daher gibt es heute etwas ganz anderes: Musik. Adam Janosch setzt sich für die agile Festtagsstimmung ans Klavier.

Je nach persönlicher Vorliebe empfehle ich übrigens, zu seinem Lied mit Glühwein, Eggnogg oder Weihnachtsbock anzustossen. Der stimmungshebende Effekt wird dadurch nochmal verstärkt.

Customer-Vendor Antipattern (III)

Bild: Pexels / Antoni Shkraba - Lizenz

Ursprünglich ist das Customer-Vendor Antipattern eine Verhaltensweise, die zwischen Menschen auftritt. Mehrere von ihnen planen ein gemeinsames Vorhaben, trauen sich aber nicht so ganz. Also versuchen sie möglichst genau festzulegen, wer für was zuständig ist. Das paradoxe Ergebnis sind mehr Streit und Zuständigkeitslücken, da alle Seiten sich bei ungeplanten Zusatzaufwänden auf den Standpunkt zurückziehen können, diese nicht in ihrem offiziellen Aufgabenbereich zu haben.

Vor allem in grossen Organisationen legen aber auch ganze Organisationseinheiten dieses Verhalten an den Tag. Das ist vor allem dort der Fall, wo hochspezialisierte Einheiten sich gegenseitig beauftragen, z.B. dann, wenn eine Fachabteilung eine Kampagne vom Marketing oder eine Vertriebs-Ressort neues Feature vom konzerneigenen IT-Systemhaus haben möchte. Sobald eine oder mehrere Seiten sich in solchen Szenarien gegen ungeplante Entwicklungen "absichern" möchten, nimmt das Drama seinen Lauf.

Als erste Folgeauswirkung werden mit z.T. riesigem Aufwand telefonbuch-dicke Lasten- und Pflichtenhefte erstellt, in denen selbst kleinste Details fachlich und technisch beschrieben werden und in denen (offen oder verklausuliert) jeder versucht, der jeweils anderen Seite die Verantwortung für unentdeckte Risiken oder unvorhersehbare Entwicklungen zuzuschieben. Die beauftragende Seite strebt dabei in der Regel einen Festpreis an, die beauftragte Seite einen Fixed Scope.

Da den meisten Organisationen mittlerweile klar ist, dass die meisten Pläne nicht umsetzbar sind wie gedacht, kommt es als zweite Folgeauswirkung zur Festlegung von Prozessen, mit denen diese Anforderungen gegebenenfalls geändert werden können. Um dabei nicht übervorteilt werden zu können, enthalten sie oft Kontroll- und Freigabeschritte in einem Ausmass, dass die Umsetzung selbst beim besten Willen aller Beteiligten nur noch bürokratisch sein kann.

Als dritte Folgeauswirkung wird in der Regel versucht, ein möglichst kleinteiliges Reporting über dem Umsetzungsprozess zu etablieren, mit regelmässigen und eng getakteten Meilensteinen, Fortschrittsberichten, Lenkungsausschüssen, Abnahmen und Change Requests. Besonders die beiden letzten sind häufig stark formalisiert und nur mit grossem Aufwand revidierbar, auch das wieder getrieben vom Wunsch nach möglichst viel Sicherheit und Kontrolle.

Sobald in einem derartigen Szenario die Umsetzung beginnt, ist es meistens nur eine Frage weniger Wochen oder Monate bis alles entgleist. Es werden Notwendigkeiten entdeckt, die in den den Lasten- und Pflichtenheften nicht abgedeckt sind, die Änderungsprozesse werden angestossen, dauern ewig, führen aber zu keiner Einigung, Streitpunkte werden bis auf die höchste Hierarchie-Ebene eskaliert und schlimmstenfalls muss bis zu einer Klärung die Umsetzung pausieren.

Nochmal zur Erinnerung: wir reden hier nicht von verschiedenen Firmen, sondern von verschiedenen Einheiten eines gemeinsamen Unternehmens oder Konzerns.

Dass eine derartige Konstellation auf jeden Fall vermieden werden sollte, dürfte alleine beim Lesen jedem klar sein, wie das zu erreichen wäre, ist dagegen weniger offensichtlich. In den meisten Unternehmen gibt es nämlich einen strukturellen Grund dafür, dass das Customer-Vendor Antipattern immer wieder entsteht: die Budgets und die Umsetzungskapazität liegen in jeweils unterschiedlichen Einheiten, die beide angwiesen sind, "wirtschaftlich zu arbeiten".

Für die beauftragende Einheit bedeutet das, dass sie versuchen muss, für möglichst wenig Geld möglicht viel Leistung einzukaufen (und dass ohne im Detail zu verstehen, wie die Erbringung funktioniert), für die auftragsannehmende Einheit bedeutet das, dass sie versuchen muss, mit möglichst geringem Aufwand möglichst hohe Einnahmen zu erzielen (und das ohne verstehen zu können, ob die zu diesem Zweck in Rechnung gestellten Tätigkeiten fachlich durchgehend sinnvoll sind). Das kann nicht gut gehen.

Eine nachhaltige Lösung kann daher nur daraus bestehen, die strukturellen Gründe für das Customer-Vendor Antipattern zu beseitigen. Und das kann eigentlich nur dadurch nachhaltig stattfinden, dass die verschiedenen organisatorischen Silos aufgelöst werden und ein und die selbe Einheit sowohl für das Budget, als auch die Fachlichkeit und die Umsetzung verantwortlich ist, also möglichst weite Teile der Wertschöpfungskette verantwortet.

Natürlich wäre das für fast jede grössere Organisation eine radikale Abkehr von ihren bisherigen Organisations- und Arbeitsteilungs-Prinzipien, aber es wäre auch eine die gut begründbar ist und alleine durch die Auflösung interner Konflikte und Blockaden für mehr Effektivität und Effizienz sorgen würde.

SpotiSAFe

Irgendwann zwischen 2015 und 2020 hat ein zunächst merkwürdig anmutender Trend begonnen. Waren die Berichte aus den agilen Methoden-Implementierungen grosser Konzerne bis dahin entweder von den Buzzwords aus SAFe oder denen aus dem Spotify Model durchsetzt, gab es ab diesem Zeitraum plötzlich viele, in denen beides vermischt wurde. Tatsächlich taucht seitdem in immer mehr Unternehmen ein Hybrid aus beiden Ansätzen auf, häufig als "SpotiSAFe" bezeichnet.¹

Um zu verstehen wie es dazu gekommen ist, muss man sich eine Besonderheit von SAFe vor Augen halten: als einziges agiles Framework gestaltet es auch die Budgetierung um. Während klassische projektorientierte Organisationen Pools gleichartiger Spezialisten finanzieren (Entwickler, UX-Designer, etc.), von denen die Projekte ihre Teammitglieder "mieten" müssen,² geht das SAFe Lean Portfolio Management einen anderen Weg und budgetiert die Value Stream-basierten Release Trains direkt.

Wenn eine Organisation aber ihre Matrix-Organisation aus Spezialisten-Pools und Projekt-/Produktteams beibehalten will, sei es aus schlechten Gründen (haben wir schon immer so gemacht) oder aus guten (zur Förderung fachlicher Exzellenz oder zur Ermöglichung langfristiger Personalentwicklung über mehrere Projekte hinweg), dann muss sie SAFe an dieser Stelle anpassen. Wenn aber vorgegeben ist, "dass alles agil werden soll"³ braucht es in diesem Fall auch eine "agile Variante der Matrix-Organisation".⁴

Und an dieser Stelle kommt das Spotify Model ins Spiel, dass ja nichts anderes als eine derartige Matrix ist. Die Spezialisten-Pools heissen in ihm Chapter und die "entleihenden" Einheiten sind die "Squad" genannten Teams, bzw. die aus mehreren Squads bestehenden Tribes. Dadurch, dass diese Chapter jetzt auch in SAFe eingeführt werden, so dass die Release Trains aus ihnen ihre Mitglieder beziehen können, entsteht auch dort eine Matrix-Organisation in Form von SpotiSAFe.

Je nachdem wie weit die "Spotifyisierung" von SAFe getrieben werden soll können auch noch weitere Elemente aus SAFe nach vergleichbaren Einheiten aus dem Spotify Model umbenannt werden, so dass z.B. aus den Teams die Squads werden, aus den Release Trains die Tribes und aus den Communities of Practice die Gilden. Der zentrale Punkt bleibt aber die Kombination von SAFe und Matrix-Organisation (mit irgendwie "agil klingenden" Namen).

Das ist es also, das SpotiSAFe Model, das seit etwa einem Jahrzehnt von den McKinseys, Boston Consultings und anderen Beratungen in einem Konzern nach dem anderen eingeführt wird. Es zu bewerten ist nicht eindeutig möglich, wie oben gesagt gibt es sowohl gute als auch schlechte Gründe für eine Beibehaltung eines Matrix-Aufbaus. Wie immer gilt also auch hier, dass es auf den jeweiligen Einzelfall ankommt - und darauf, wie gut man "agile Buzzwords" verträgt.⁵

¹Die früheste Erwähnung dieses Begriffs die ich gefunden habe war 2016 im Blog Agile Mouse
²Mit dem Customer-Vendor-Antipattern als häufiger Folge
³Die Sinnhaftigkeit einer solchen Vorgabe wäre nochmal ein Thema für sich
⁴Bevor einer schreit: das steht da nicht ohne Grund in Anführungsstrichen
⁵Wer SAFe oder das Spotify Model oder beides ohnehin doof findet, wird natürlich aus SPotiSAFe doof finden

The Agile Bookshelf: Wild West to Agile

Die vermutlich treffendste Würdigung von Jim Highsmiths Buch Wild West to Agile: Adventures in software development evolution and revolution steht in einer der in ihm abgedruckten Rezensionen: Highsmitsch scheint der Forrest Gump der Softwareentwicklung zu sein - überall dort wo es neue und spannende Entwicklungen gab ist er irgendwie beteiligt gewesen, und das von den siebziger Jahren bis in die Gegenwart.

Dieser bemerkenswerte Werdegang, der neben vielen anderen Stationen unter anderem eine Anstellung im Apollo-Programm, Qualitätsmanagement bei Microsoft und eine Beteiligung an der Entstehung des Manifests für agile Softwareentwicklung umfasste, macht es möglich, zwei Literaturformen zu kombinieren: Highsmiths Buch ist gleichzeitig eine Autobiografie und ein Werk über die Technik- und Management-Geschichte der letzten Jahrzehnte.

Was in seinem Werk erkennbar wird, ist wie die verschiedenen Entwicklungs- und Management-Ansätze dadurch entstanden sind, dass sie auf die jeweils vorherigen reagieren: auf die autodidaktisch-chaotische Wild West-Phase zu Beginn folgt der Versuch, Sicherheit und Ordnung durch Regeln und Prozesse zu erzeugen, die dadurch entstehende Unflexibilität führte wiederum zu Gegenbewegungen, die dann 2001 im agilen Manifest unter dem Label "Agile" zusammengefasst wurden.

Diese begriffliche Zusammenführung von 2001 wird in Wild West to Agile als derartig zentrale Zäsur gesehen, dass sie die "agile Ära" in zwei Teile trennt: die "Roots of Agile"-Phase von 1990 bis 2001, in der Ansätze wie scrum, XP, ASD, DSDM und Crystal nach und nach entwickelt wurden und die eigentliche agile Phase ab 2002, in der sich die ursprünglich teambasierten Ansätze nach und nach auf die Ebene des Gesamtunternehmens ausbreiteten.

Angereichert wird diese Übersicht durch zahlreiche selbst erlebte Anekdoten, Fallstudien verschiedener Unternehmen und unbekannte, bzw. vergessene Hintergrund-Informationen, wie z.B. die in den 70ern ernsthaft diskutierte Frage, des Gewichts von Software oder die Erwähnung, dass die Entstehung des Agilen Manifests 2001 in Snowbird, Utah kein Heureka-Moment war, sondern u.a. auf ein vergleichbares Treffen aufbaute, dass ein Jahr zuvor in Rogue River, Oregon stattgefunden hatte.

Allen, die sich für Hintergründe und zugrundeliege Muster von Software-Entwicklung und Agilität interessieren, denen reine Fachbücher aber zu trocken sind, kann man Jim Highsmiths Buch empfehlen, besonders wenn man seiner abschliessenden Prognose zustimmt: er ist überzeugt davon, dass die Gründe wegen denen die agilen Frameworks entwickelt wurden, noch immer bestehen, und dass die agile Bewegung aufgrunddessen noch lange weitergehen wird.

Larman's Law (I)

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Erste von ihnen gehen. Es lautet:

Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

Zu Deutsch: Organisationen sind implizit darauf optimiert, den Ist-Zustand der bestehenden Management-, Spezialisten- und Machtpositionen zu erhalten. Jedem, der schon einmal an Versuchen beteiligt war, bestehende Zustände in Unternehmen oder Behörden zu verändern, wird das bekannt vorkommen. Was man bei Larmans erstem Gesetz aber bedenken sollte - man muss es nicht nur negativ sehen, es stecken sowohl gute als auch schlechte Aspekte dahinter.¹

Um mit den Guten zu beginnen: eine Organisation, die ihre zentralen Kommunikationsflüsse und Entscheidungsstrukturen schützt, ist erst einmal resilient, also widerstandsfähig gegen Krisen und Disruptionen. Das ist im Grundsatz etwas Positives. Auch dass dabei die Position des Managements geschützt wird ist erstmal nicht schlecht, schliesslich hält es traditionell geführte Firmen durch Zielsetzungen und Koordination am Laufen und sichert so ihr Fortbestehen.

Selbst in Organisationen, die sich in Richtung Agile oder Lean entwickelt haben, kann es noch wichtig sein, die Position der Manager und Spezialisten zu schützen oder sogar zu fördern. Ein Beispiel für derartige Konstellationen sind die Unternehmen des Silicon Valley mit ihrer in Europa eher unbekannten Rolle des Tech Lead Manager, ein anderes die Lean-Unternehmen aus Japan, über die Ikujiro Nonaka, einer der "Urväter von Scrum" einmal sagte:

In Japan, the middle management is going to be the key to innovation. Not top-down or bottom-up, but middle-up-down is the power of Japanese organizations.

Auf der anderen Seite gibt es natürlich auch die Fälle, die kritisch zu sehen sind. Sie liegen dann vor, wenn notwendige oder aus Unternehmenssicht wichtige Dezentralisierungs- oder Delegations-Initiativen von den bisherigen Managern oder Spezialisten unterlaufen oder behindert werden. Selbst dann macht es aber noch Sinn zu differenzieren: das (scheinbare) Beharren auf alten Mustern muss nicht auf Destruktivität beruhen, es können auch gut gemeinte Reparaturversuche sein.

Diese treten vor allem dann auf, wenn Teams oder Organisationen in die Autonomie-Falle getappt sind, indem sie Selbstorganisation ausrufen, ohne zu bedenken, dass für deren wirksame Ausübung Wissen notwendig sein kann, das zuerst vermittelt werden müsste. Um zu verhindern, dass Manager oder Spezialisten "rettend eingreifen müssen", macht es Sinn, eine solche Transition mit unterstützender Begleitung durchzuführen.

Erst in einer letzten Kontstellation geht Larmans erstes Gesetz auf wirklich problematische Verhaltensweisen zurück: dann, wenn von Spezialisten oder Managern versucht wird, Veränderungen zu unterlaufen, um den eigenen Einfluss, Status oder Budget-Topf zu sichern. Ist das der Fall, sitzen die genannten Positionen durch ihren Wissens- und Macht-Vorsprung meistens am längeren Hebel als die Veränderungs-Befürworter. Das ist dann ein Problem.

Selbst darin kann man aber noch ein letztes bisschen Positives finden: Am Umgang der obersten Hierarchie-Ebene mit diesen Verhaltensweisen kann man erkennen, wie ernst sie es mit den Veränderungen meint. Lässt sie sie zu, trägt sie zu den von Craig Larman beschriebenen Mechanismen bei. Das ist dann zwar schade, zumindest weiss man aber, woran man ist. Das ist immerhin etwas.

¹Alles ab hier ist meine Meinung, nicht mehr die von Larman

Explore, Expand, Extract, Exploit

Zu den Konzepten auf denen ich mittlerweile schon einige Zeit herumdenke, gehört Explore, Expand, Extract vom Extreme Programming-Erfinder Kent Beck (siehe hier und hier). Ähnlich wie bei der Idee des Methodenwechsels im Projektlebenszyklus geht er davon aus, dass unterschiedlichen Rahmenbedingungen nicht mit einem immer gleichen methodischen Ansatz begegnet werden sollte, sondern dass auch das Vorgehen an die jeweiligen Bedürfnisse angepasst werden sollte.

Was mich an dieser Idee beschäftigt hat ist, dass die Situation vieler Produkte (bzw. Produkt-Teams) bei unseren Kunden in keine der drei Kategorien so richtig hineingepasst hat, vermutlich weil deutsche Konzerne sich nun mal deutlich vom Silicon Valley unterscheiden (Beck entwickelte sein Konzept während seiner Zeit bei Facebook). Um es auch hier anwenden zu können habe ich es daher erweitert, so dass es jetzt vier statt Kategorien hat: Explore, Expand, Extract und Exploit.

Explore

Exploration ist etwas, was in deutschen Konzernen selten stattfindet, in Startups aber ständig. Wieder und wieder werden neue Features entworfen, als MVP mit möglichst geringem Aufwand umgesetzt und an die Kunden/Benutzer ausgeliefert. Werden die Neuerungen von denen ignoriert oder abgelehnt werden sie schnell entsorgt, werden sie gut angenommen bleiben sie im Produkt und durchlaufen dann idealerweise ein Refactoring, um besser betreibbar und erweiterbar zu werden.

Expand

Während die meisten der so implementierten Features ein solides aber beherrschbares Wachstum hinlegen, gibt es einige, deren Nutzung für eine kurze Zeit explosionsartig zunimmt. In dieser so genannten Expansion-Phase müssen unter Hochdruck Infrastruktur und Verarbeitungskapazität erweitert werden, um zu verhindern, dass Performance-Probleme und Ausfälle die gerade herbeiströmenden Kunden/Benutzer wieder vertreiben. Für Beck die einzige Phase in der Überstunden Sinn machen.

Extract

Sobald dieses explosionsartige Wachstum vorbei ist, folgt die Extraction-Phase. Nachdem in Expansion-Phasen zur schnellen Erweiterung von Infrastruktur und Verarbeitungskapazität ggf. auch redundante oder überdimensionierte Lösungen bewusst in Kauf genommen werden können, können diese während der Extraction durch Vereinheitlichung oder Ressourcen-Optimierung zurückgebaut oder billiger gemacht werden (ich kenne dafür aus meinen Kunden-Einsätzen auch den Begriff "Cost Down").

Exploit

Apropos Kunden-Einsätze: in ihnen habe ich die erwähnte vierte Dimension erlebt, die ich in Fortführung der mit "Ex-" beginnenden Namen die Exploitation-Phase nenne. In ihr sind Explore, Expand und Extract bereits abgeschlossen (z.T. bereits seit langem) und die Features befinden sich im Cash Cow-Modus. Das heisst, dass sie bereits etabliert und kostenoptimiert sind und jetzt mit möglichst geringen Investitionen erhalten und betrieben werden, um möglichst lange profitabel sein zu können.

Selbst wenn man sich im Organisations- und Prozessdesign grundsätzlich vor Patentrezepten hüten sollte, kann man diese vier Kategorien jetzt nutzen, um ihnen naheliegende Methodiken und Erfolgskriterien zuzuordnen. In Expand könnte das Lean Startup mit der Metrik MVPs pro Monat sein, In Expand ein Task Force-Modus mit dem Ziel möglichst geringer Down-Times oder kurzer Mean Time to Recovery, in Extract kann in Iterationen gearbeitet werden, die Einspareffekte zum Ziel haben, und in Exploit können Kanban-Systeme Sinn machen, die auf die Optimierung von Ressourcen-Effizienz ausgelegt sind.

Unabhängig davon, ob am Ende diese oder andere Ausgestaltungen entstehen, der zentrale Punkt im Explore, Expand, Extract, Exploit-Modell ist der, dass in jeder der vier Kategorien andere Ansätze Sinn machen und daher nicht versucht werden sollte, in allen mit dem immer gleichen Vorgehen zu arbeiten. Und wenn dann auch noch erkannt wird, dass viele Vorhaben sich zwischen den Kategorien hin- und herbewegen, ist die Chance gross, für fast jede Herausforderung das passende Organisationsmodell finden zu können.

Ein Bild sagt mehr als 1000 Worte (XXXIX)

Grafik: monkeyuser.com - License

Seit dem Durchbruch von ChatGPT träumen einige Menschen davon, Software-Entwickler durch künstliche Intelligenz ersetzen zu können. Der Grund dafür, dass das nur eingeschränkt passieren wird: mit einer Software zu arbeiten, deren innere Abläufe niemand versteht, wäre in einem beruflichen Kontext fahrlässig (und Gleiches gilt für die Übernahme von Management-Tätigkeiten).