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).

Kommentierte Links (CVII)

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.

Patrick McKenzie: Seeing like a Bank

Ein Logread, und dabei einer der es in sich hat. Am Beispiel der Banken-Branche beschreibt Patrick McKenzie wie es dazu kommt, dass in grossen Organisationen Prozesse und IT-Systeme immer wieder dysfunktional wuchernd ausser Kontrolle geraten. Anders als häufig unterstellt stehen normalerweise weder Inkompetenz noch sinistre Absichten dahinter, sondern vor allem Sachzwänge betriebswirtschaftlicher oder juristischer Natur, die jeweils für sich betrachtet auch vollkommen rational und nachvollziehbar sind. Erst die unbeabsichtigten Effekte ihres Zusammenwirkens führen zu den teils bürokratischen und teils chaotischen Zuständen, die in der Aussenwahrnehmung zu Fassungslosigkeit führen können (mit der Postbank gibt es ein anschauliches aktuelles Beispiel).

Karl Scotland: A Simple Resolution to the Agile Transformation Conundrum

Begriffe sorgfältig auszuwählen ist wichtig, denn häufig formen sie unsere Wahrnehmung des jeweiligen Sachverhalts viel tiefer als man denken sollte. Vor diesem Hintergrund sind die Überlegungen von Karl Scotland zu verstehen, der sich entschlossen hat, den Begriff "Agile Transformation" bei sich durch "Strategic Agility" zu ersetzen. Die Benennung Agile Transformation hält er aus zwei Gründen für problematisch: zum einen weil sie den Eindruck von Linearität und Abschliessbarkeit vermitteln kann, zum anderen weil der Eindruck entstehen kann, Agilität wäre das Ziel der Transformation und damit ein Selbstzweck. Dass es gelingen wird, den Begriff der Agilen Transformation auch in der allgemeinen Verwendung abzulösen, kann man bezweifeln (dafür ist er zu etabliert), ein wertvoller Impuls für die eigene Sprachverwendung ist es aber auf jeden Fall.

Roman Pichler: Decoding Product Leadership

Leadership ist immer ein schönes Thema, vor allem im Umfeld selbstorganisierter Teams, in denen eine direkte Weisungsbefugnis nicht mehr oder nur eingeschränkt gegeben ist. Roman Pichler beleuchtet das Konzept von verschiedenen Seiten und beschreibt unter anderem charismatische Führung (allerdings ohne diesen Begriff zu verwenden), informelle Führung und emergente Führung. Interessant sind auch seine verschiedenen Dimensionen von Product Leadership: Trust-building, Empathising, Communication, Goal Setting, Collaborative Decision-Making, Conflict Resolution und Self-Leadership. Was das im Anwendungsfall bedeutet, wird zwar jeder für sich erarbeiten müssen, es ist aber eine gute Übersicht über die Felder, in denen man Führungsqualitäten entwicklen kann.

Chris Alderson: Beyond Scaled Agile Frameworks

Nochmal zum Thema der sorgfältigen Begriffsverwendung und zu der Schwierigkeit, bereits etablierte Begriffe abzulösen. Chris Alderson schlägt vor, anstelle von agilen Skalierungsframeworks von "massgeschneiderten Betriebsmodellen" zu sprechen. Sicherlich vom Ansatz her richtig (eine Umsetzung "by the Book" ist auf Skalierungebene nochmal schwieriger und seltener als auf Teamebene) aber eben auch ein Kampf gegen Windmühlen. Wichtiger als die Benennung ist allerdings die Grund-Idee: sich aus den "Bausteinen" der verschiedenen Skalierungsframeworks ein eigenes Vorgehensmodell zusammenzubauen (z.B. Lean Portfolio Management aus SAFe, Scrum of Scrums aus Scrum@Scale, etc) dürfte den jeweiligen Bedürfnissen in der Regel eher entsprechen als das Ausrollen einer "One Size fits All"-Lösung.

John Cutler: How to Troubleshoot Status Updates and Syncs

Als letztes eine nützliche Liste von Praxistipps zu einem Thema, das in jeder grösseren Organisation immer wieder hochkommt: zu viele und zu ineffektive Meetings. John Cutler teilt eine ganze Reihe möglicher Probleme, bietet zu jedem eine Analyse häufiger Ursachen und eine Idee, wie man zu Verbesserungen kommen kann. Da sollte für jeden etwas dabei sein, das sich im eigenen Unternehmen ausprobieren lässt.

Podcasting (III)

Bild: Unsplash / Will Francis - Lizenz

Vor kurzem bin ich halb im Scherz als "Podcaster ohne Podcast" bezeichnet worden, da ich mittlerweile in mehreren zu Gast gewesen bin. Ganz soweit würde ich zwar nicht gehen (es sind bisher gerade einmal sechs solche Gastauftritte zusammengekommen), aber wer weiss was noch kommt. Hier sind erstmal die beiden neuesten.

Der hier ist schon einige Wochen her, und er dürfte das vielleicht kontroverseste Thema haben, mit dem ich bisher an die Öffentlichkeit gegangen bin. In André Claassens OKR-Podcast habe ich mit ihm darüber gesprochen, warum ein Scrum Master kein Coach sein kann (u.a. wegen keiner Auswahl durch die Coachees und keiner eigenen Agenda-Freiheit). Da viele Inhaber dieser Rolle sich aber explizit als (Agile) Coaches sehen habe ich in Folge einige lebhafte Feedbacks erhalten.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Die neueste Aufnahme ist wieder eine zu einem meiner Lieblingsthemen, zu dem ich auch schon Konferenzvorträge und eine andere Podcast-Aufnahme gehabt habe: Transformations-Metriken, an denen das Management auch die Ergebnisse der eigenen Arbeit messen kann, und nicht nur die der Ausführungsebene. Mit Miriam Sasse und Ellen Duwe vom Agile World News-Podcast hatte ich diesesmal gleich zwei Gesprächspartnerinnen um mich darüber auszutauschen.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Continuous Integration: That’s Not What They Meant

Das schönste Missverständnis zum Begriff CI habe ich einmal mit einer UX-Designerin erlebt, die der festen Meinung war, die Entwickler in ihrem Team würden über Corporate Identity sprechen. Clare Sudbery dürfte über dieses Level an Verständnis weit, weit hinausgekommen sein. Richtigerweise ist es bei ihr Continuous Integration, oder wie es ihrer Meinung nach heissen müsste "Continuous Trunk Based Development" (CTBD).

Wer CI kennt, wird vor allem nickend vor dem Bildschirm sitzen, einige kleine Erkenntnisse sind aber sicherlich für jeden dabei. Mir war zum Beispiel nicht klar, dass Kent Beck bereits im Rahmen von Extreme Programming CI (noch unter einem anderen Namen) beschrieben hat.

Tech Lead Manager

Bild: Pexels / Ketut Subiyanto - Lizenz

Zu den Überraschungen, die man in grossen Firmen aus dem Silicon Valley erleben kann, gehört die fast vollständige Abwesenheit von Scrum Mastern, Agile Coaches, People Managern und vergleichbaren Rollen. Das erscheint zunächst merkwürdig, schliesslich gelten Google, Facebook, Netflix & Co doch als Vorzeige-Beispiele gelungener Agilität. Und es wirft die Frage auf, welche Führungsrollen es dort stattdessen gibt. Eine auf die man dabei immer wieder stösst, ist die des "Tech Lead Managers" (TLM).

Um diese Rolle einordnen zu können: die klassische Silicon Valley-Rollenteilung ist die in Engineering Manager und Tech Lead.¹ Den Engineering Manager kann man sich dabei wie eine Mischung aus Abteilungs-Leiter und Product Owner vorstellen, mit der Besonderheit, dass er selbst einmal Softwareentwickler gewesen sein muss.² Der Tech Lead oder Lead Developer ist ein teaminterner oder -externer Experte, der den Entwicklern Entwicklungsprozesse und -standards vorgibt.

Beide Rollen haben im Vergleich zu einem Scrum Master, Product Ower, Agile Coach oder People Manager eine relativ hohe Weisungsbefugnis gegenüber ihren Teammitgliedern. Der Grund dafür sind zwei weitere Besonderheiten: die Entwickler sind im Durchschnitt eher jung, und sie wechseln verhältnismässig häufig (mitunter jährlich) den Job. Beides liegt daran, dass für viele das stressige Silicon Valley nur ein "Karriere-Sprungbrett" ist, mit dem sie sich für andere Firmen empfehlen.³

Bedingt dadurch sind viele Teams eher unerfahren und befinden sich in einer permanenten Storming-Phase, was durch die eher anleitende Ausgestaltung der Rollen kompensiert werden soll. Das kann auch funktionieren, bringt aber das Risiko mit sich, dass die beiden leitenden Rollen sich aufgrund ihrer unterschiedlichen Interessen gegenseitig blockieren. Dort wo Geschwindigkeit wichtig ist, werden sie daher oft zum Tech Lead Manager zusammengefasst, der alle Entscheidungen alleine treffen kann.

Im Vergleich zu den aus dem Osten der USA stammenden Ansätzen Scrum und Extreme Programming mag das auf den ersten Blick wenig agil wirken, da diese Rolle die Selbstorganisation der Teams stark einschränken kann. Wird Agilität aber einfach als schnelle Reaktions- und Lieferfähigkeit verstanden, kann dieser eher hierarchische Ansatz in derartig volatilen Teams der zielführendere sein (was übrigens nicht bedeutet, dass hier Micro-Managing stattfindet, das wäre nochmal etwas Anderes).

Zu bedenken ist dabei allerdings, dass diese Doppelrolle für ihren Inhaber sehr fordernd und belastend sein kann, was auf Dauer zu neuen Problemen führt. Aufgrunddessen ist es z.B. bei Google so, dass sie vor allem in kleinen, neu zusammengestellten, oder in instabilen Umgebungen arbeitenden Teams geschaffen wird, während stabiliere oder erfahrenere Teams eher wieder die klassische Doppelspitze aus Engineering Manager und Tech Lead haben (siehe hier).

Was erkennbar wird: die Rolle des Tech Lead Manager kann durchaus entscheidend für einen agilen Arbeitsmodus sein, sie ist aber so spezifisch für das Silicon Valley, dass sie nur schwer übertragbar ist. Man kann sie zwar auch in Europa oder an der US-Ostküste einführen, hier würde aber das starke Risiko bestehen, dass sie zu einem Flaschenhals wird und das in den Teams vorhandene Wissen nicht ausreichend nutzt, und infolgedessen eine eher anti-agile Wirkung hätte.

¹Natürlich gibt es von diesen Rollen zahllose Benennungs- und Ausgestaltungs-Varianten
²Wodurch verhindert werden soll, dass er fachlich richtige aber technisch fragwürdige Entscheidungen trifft
³Für eine bessere Vorstellung von dieser Arbeitswelt empfehle ich das Buch Chaos Monkeys von Antonio García Martínez

Wie man nichts lernt

Bild: Pexels / Anna Tarazevich - Lizenz

Eigentlich sind Learning & Development-Angebote grossartig: Firmen wollen die Aus- und Weiterbildung ihrer Mitarbeiter fördern und stellen ihnen darum kontinuierlich neue Lerninhalte zur Verfügung. Gerade in grösseren Organisationen kippt dieser eigentlich gute Ansatz aber immer wieder ins Dysfunktionale. Ein aktueller Fall, den man den Medien entnehmen kann, ist der von Slack, bzw. Salesforce. Das Drama, das hier wohl stattgefunden hat, ist leider exemplarisch für vieles was häufig schiefläuft, und verdient daher eine nähere Betrachtung.

Ausgangspunkt ist anscheinend die Digitalisierung und Automatisierung von Lern-Angeboten, die Salesforce irgendwann durchgeführt hat, vermutlich um die Einheitlichkeit der vermittelten Inhalte sicherzustellen, um sich von der Verfügbarkeit von Trainern und Schulungsleitern unabhängig zu machen, um Reiseaufwände zu den Schulungszentren zu sparen und um durch die beliebig häufige Wiederholbarkeit des einmal erstellten Materials Kosten einzusparen. So weit, so gut.

Ebenfalls betriebswirtschaftlich getrieben dürfte eine zweite Entscheidung gewesen sein: als interne Lernplattform wurde Trailhead gewählt, ein bereits vorhandenes Tool, das eigentlich dafür gedacht ist, Anwendern beizubringen, wie die Salesforce-Anwendungen funktionieren. Ein wesentliches Element dieses Tools sind Gamification-Elemente, das heisst, Lern-Punkte, die man für das Bewerten von Kursen und das Abschliessen von Wissenstests sammeln kann. Ebenfalls erstmal ok.

Eher humanistisch motiviert war vermutlich die dritte Entscheidung: Im Sinn eines Studium Generale wurden auch Inhalte in die "Lehrpläne" einbezogen, die keinen unmittelbaren Bezug zur täglichen Arbeit haben, etwa Eräuterungen der "vierten Industriellen Revolution" (Industrie 4.0) oder zur gesunden Ernährung. Auch daran kann man für sich genommen nur Gutes finden, ein Blick über den Tellerrand schadet nie und beugt dem Entstehen von Fach-Idiotie vor.

Was anscheinend nicht bedacht wurde, war der durch diese Art der Wissensvermittlung entstehende Zeitaufwand. Die verschiedenen Inhalte erreichten in Summe einen bemerkenswerten Umfang, und durch die Gamification-Elemente liessen sie sich nicht mehr im Hintergrund abspielen, sondern erforderten ständige Interaktion. Um die vorgegebenen Lernziele zu erreichen musste daher Zeit im Umfang von mindestens 40 Stunden investiert werden.

Man kann jetzt versuchen, sich in die Mitarbeiter der Salesforce-Tochtergesellschaft Slack hineinzuversetzen. In ihrem Learning & Development-Portal fanden sie Inhalte, die zum Teil generisch und zum Teil beruflich irrelevant waren, nur mit hohem Zeitaufwand konsumierbar waren, in einem Tool angeboten wurden, das eigentlich erkennbar einem anderen Zweck dienen sollte, ohne die Möglichkeit Verständnis- oder Vertiefungsfragen zu stellen. Kaum einer nahm diese Lern-Angebote an.

Peinlich wurde das aus Sicht des Unternehmens dadurch, dass es für jeden offensichtlich war. Die Gamification Elemente sorgten nicht nur dafür, dass die einzelnen Mitarbeiter Lern-Punkte sammeln konnten, dadurch dass die Ranglisten intern öffentlich waren, wurde klar, dass kaum jemand Punkte sammelte, was im Umkehrschluss bedeutete, dass kaum jemand die Learning & Development-Angebote wahrnahm. Ein offensichtliches und verheerendes Feedback.

Ebenfalls verheerend war die Reaktion des Unternehmens: das Lernen wurde erzwungen, indem angeordnet wurde, dass alle anderen Tätigkeiten eingestellt werden mussten, bis vorgegebene Mindest-Punktzahlen im Lern-Tool erreicht waren. Und das am Ende des Jahres, mitten in der Phase, in der viele damit voll ausgelastet gewesen sein dürften, an der Erreichung ihrer (gehaltsrelevanten) Jahresziele zu arbeiten. Die Nicht-Begeisterung angesichts dieses "Lern-Zwangs" kann man sich vorstellen.

Aber wo Frustration entsteht, da wird nach Auswegen gesucht. Und da Software-Entwickler das Lösen technischer Probleme als Beruf haben, kam es bald zur absehbaren Pointe der Geschichte: die Mitarbeiter programmierten sich ihre eigenen Tools, die automatisiert die Gamification-Elemente in Trailhead durchklickten. So konnten die geforderten Lern-Punkte erzeugt werden, ohne dass man sich mit den aufgezwungenen Themen beschäftigen musste. Formalismus erfüllt, Lerneffekt gleich null.

Man kann sich jetzt überlegen, an welcher Stelle der eigentlich gute Learning & Development-Ansatz entgleist ist. Vielleicht bei der Idee, generische Inhalte für alle Mitarbeiter festzulegen, vielleicht beim Versuch, durch die Wiederverwendung eines für einen anderen Zweck konzipierten Tools Geld zu sparen, vielleicht bei der Erstellung einer Punkte-basierten "Lern-Planwirtschaft", vielleicht beim Versuch, den Erfolg des Vorgehens zu erzwingen. Vermutlich war es eine Kombination von allem.

Selbst wenn dieser Fall vermutlich ein extremer ist, die verschiedenen Entgleisungs-Ursachen finden sich in unterschiedlicher Ausprägung in sehr vielen grossen Organisationen wieder, was auch erklärt, dass die internen Lernangebote einen nicht besonders guten Ruf haben. Und ich kann es aus eigener Erfahrung sagen: selbstgebaute Tools, mit denen Entwickler lästige Pflichtkurse "wegautomatisieren", gibt es nicht nur bei Salesforce, sondern auch in anderen Firmen.

Wie immer bleibt zum Schluss die Frage, wie es besser ginge. Die verblüffend einfache Antwort: man kann die Mitarbeiter fragen, wie ihnen Lern-Angebot und Lern-Tools gefallen und beides basierend auf diesem Feedback so anpassen, dass es den Bedürfnissen entspricht. Das ist nicht immer die billigste Lösung, aber dafür eine, die wirklich für Learning & Development sorgt. Und ganz nebenbei ist es auch ein schöner Test dafür, wie ernst die propagierte Nutzer-Zentrierung wirklich gemeint ist.

Velocity (II)

Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).

WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.

Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.

Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.

Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche  Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.

Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.

The Agile Bookshelf: Work, Sleep, Repeat

Bild: Pexels / Yan Krukau - Lizenz

Seit einigen Jahren werde ich regelmässig auf mein Buch angesprochen und darauf, dass ich es erstaunlich selten erwähne. Der Grund dafür ist einfach - es ist gar nicht von mir. Wie es der Zufall will gibt es einen zweiten Felix Stein, der eine Zeit lang als Unternehmensberater gearbeitet und ein Buch darüber geschrieben hat. Um zumindest zu wissen worum es geht, habe ich es gekauft und muss sagen, es gefällt mir wirklich gut.

Der Name des Buches ist Work, Sleep, Repeat: The Abstract Labour of German Management Consultants, und anders als man angesichts der Einleitung denken könnte ist es weniger ein subjektiver Erfahrungsbericht und mehr eine wissenschaftliche Arbeit geworden, die man in die Disziplinen der Antropologie, Soziologie oder Sozialpsychologie einordnen könnte. Neben eigenen Erfahrungen basiert es auch auf empirischen Erhebungen unter deutschen Management-Beratern.

Inhaltlich beginnt es mit einem kurzen geschichtlichen Überblick über die Entstehung des Berufs des Unternehmensberaters, der aber nicht bloss Daten und Ereignisse aufzählt, sondern bereits Zusammenhänge herstellt, etwa den, dass im frühen 20. Jahrundert die Entkoppelung leitender und ausführender Arbeiten dafür gesorgt hat, dass nicht nur das Management als Berufsgruppe entstanden ist, sondern durch seine Entfremdung von der Ausführungsebene mit ihm der Beratungsbedarf.

Aufbauend darauf konzentriert es sich auf die bereits im Titel prominent genannte "abstrakte Arbeit", die den wesentlichen Teil von Management-Beratung ausmacht. Herausgearbeitet wird, dass es sich bei den "Liefergegenständen" um Dinge wie Organisiertheit, Legitimität und Wissen handelt, deren Wert zwar unbestreitbar ist, die aber schwer zu fassen und zu beschreiben sind, so dass Gegenstand, Ausmass und Wert der damit verbundenen Tätigkeiten von Aussen mitunter schwer nachvollziehbar sind.

In einem parallelen "Erzählstrang" ziehen sich Beobachtungen der Auswirkung dieser Art der Arbeit und des Arbeitens auf die jeweiligen Berater durch das Buch. Effekte wie Gruppen-Identität, -Konformität und -Abgrenzung gehören dazu, aber auch negative Folgen wie Entfremdung von der Arbeit und anderen Menschen, Stress, Krankheiten und Verlust des Privatlebens. Ein ganzes Kapitel widmet sich dann der naheliegenden Frage, warum so viele Menschen trotzdem diesen Beruf ergreifen.

Als jemand der selbst bereits als Management-Berater tätig war, kann ich das was der andere Felix Stein in seinem Buch schreibt verstehen und bestätigen. In vielen der Beispiele und Zitate erkenne ich eigene Erlebnisse wieder. Als Geisteswissenschaftler kann ich ausserdem nur anerkennen, dass er ein Kunststück auf der Meta-Ebene vollbringt: abstrakte Arbeit wird hier aus einer nochmals höheren Abstraktionsebene betrachtet, beschrieben und eingeordnet.

Auch allen die keinen derartigen Hintergrund haben kann ich Work, Sleep, Repeat empfehlen. Wie in ihm beschrieben wird, kann die Arbeit von Management-Beratern massive Auswirkungen auf alle Menschen in einer Organisation haben, ist für die meisten aber unsichtbar oder unverständlich. Vor allem wenn man in grösseren Organisationen arbeitet (wo es nur eine Frage der Zeit ist, bis externe Berater auftauchen), kann es ein wesentlicher Beitrag zu einem verbesserten Systemverständnis sein.

Ein Bild sagt mehr als 1000 Worte (XXXVIII)

Quelle: Twitter

Agile in a Nutshell, von Alistair Cockburn, einem der Unterzeichner des Manifest für agile Softwareentwicklung.

The Paradox of Stasis

Bild: Wikimedia Commons / Andrea Westmoreland - CC BY-SA 2.0

Wer hier häufiger mitliest weiss es: zu meinen Angewohnheiten gehört es, Erkenntnisse aus den verschiedensten Wissensgebieten zu nehmen und auf mein berufliches Umfeld zu übertragen. Heute geht es dabei um eine Studie von James Stroud, einem amerikanischen Evolutionsbiologen. Sie trägt den schönen Namen "Fluctuating selection maintains distinct species phenotypes in an ecological community in the wild" und handelt von der Untersuchung von Anolis-Echsen.

Ausgangspunkt der Studie ist das Phänomen, dass diese Eidechsen-Art seit 20 Millionen Jahren existiert, ohne sich in dieser Zeit verändert zu haben (!). Dieser lange Zeitraum stellt scheinbar die Evolutionstheorie in Frage, schliesslich müssten Lebewesen sich ihr zufolge immer wieder an die sich ändernde Umgebungsbedingungen anpassen und dadurch ihre Erscheinung verändern. Dass das bei Tierarten wie den Anolis-Echsen nicht passiert, ist daher wissenschaftlich hochinteressant.

Strouds Langzeit-Beobachtungen führten zu einer überraschenden Erkenntnis: evolutionäre Veränderungen (z.B. der Beine) kommen bei Anolis-Echsen nicht nur vor, sondern sogar extrem häufig, zum Teil finden sie sogar im Jahresrhythmus statt. Da die Umgebungsbedingungen (z.B. das Nahrungs-Angebot) sich allerdings ständig innerhalb eines bestimmten Spektrums hin- und herverändern, entwickeln die Echsen sich immer wieder zur Ursprungsform zurück und von da wieder auseinander.

Dieses Phänomen einer permanenten Anpassung bei gleichzeitiger langfristiger Beibehaltung der grundlegenden Erscheinugsform wird in der Studie The Paradox of Stasis genannt, also das widersprüchlich erscheinende Konzept, gerade durch langfristige Unveränderbarkeit besonders anpassungsfähig zu sein. So viel zur Eidechsen-Forschung, weiter zur Übertragung: gibt es das Paradox of Stasis auch in menschlichen Organisationen?

Die Antwort: ja, man findet es. Die Beispiele reichen von grossen Industriekonzernen wie Toyota, die trotz sich massiv ändernder Märkte und Technologien seit Jahrzehnten eine ähnliche Organisations-Struktur haben, bis hin zu den Feuerwehren, die trotz ständiger Modernisierung noch immer in Feuerwachen, Löschzüge und Löschgruppen unterteilt sind. Da es aber auch zahlreiche Gegenbeispiele gibt, stellt sich die Frage, in welchen Zusammenhängen diese Stabilität möglich ist (und wann nicht).

Die erste grundlegende Bedingung dürfte sein, dass veränderte Umgebungsbedingungen zwar möglich, aber nicht zu weitreichend sein sollten. Genau wie das komplette Abholzen ihrer Heimat-Wälder die Anpassungsfähigkeit von Anolis-Echsen an ihre Grenzen bringt, würde z.B. die Verdrängung der Autos durch andere Verkehrsmittel mit Sicherheit auch an Toyota nicht ohne grössere und dauerhafte Veränderungen vorbeigehen. Eine zumindest rudimentäre Stabilität braucht es also.

Die zweite grundlegende Bedingung dürfte darin bestehen, dass die "Grundform" eine gewisse Flexibilität hat, die wechselnde Ausgestaltungen ermöglicht. So wie Anolis-Echsen auch bei stark unterschiedlichen Bein-Längen noch der selben Gattung zugerechnet werden, gelten Löschzüge und Löschgruppen auch dann noch als solche, wenn ihre Kommunikationswege und -techniken sich ständig ändern (z.B. von Glocken über Signalhörner, Lautsprecher und Telefone hin zu Funkgeräten).

Aus unternehmerischer Sicht ist es hochgradig attraktiv, eine Organisation zu sein, in der das Paradox of Stasis ausgeprägt ist, nicht nur wegen der kurzfristigen Anpassungsfähigkeit, sondern auch weil sinnvolle Kontinuitäten einfacher gewahrt werden können und die grossen und teuren regelmässigen Reorganisationen unnötig werden. Ein rudimentär stabiles Geschäftsfeld zu finden, dürfte dabei die einfachere Herausforderung sein, mit der Flexibilität der Ausgestaltung dürften sich viele schwerer tun.

Auch da gilt (wie so oft): wenn es einfach wäre, würde es jeder machen. Überspitzt gesagt: nicht jedes Unternehmen kann wie eine Anolis-Echse sein. Auch als Dinosaurier kann man ein ziemlich gutes Dasein fristen. Man ist dann gross, berühmt und beeindruckend - nur muss man sich irgendwann radikal verändern um weiterbestehen zu können.

Kommentierte Links (CVI)

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.

Christiaan Verwijs: On Stakeholders, And How To Discover Them

Eine Frage mit der sich viele Teams schwer tun ist die, wer eigentlich die Stakeholder ihres Produkts oder Services sind. Die klassische Definition "Jeder, der ein Interesse daran hat oder von ihm betroffen ist" ist zwar richtig, hilft aber aufgrund ihrer hohen Abstraktionsebene nur eingeschränkt weiter. Christiaan Verwijs bietet mit diesem Artikel nicht nur einige etwas konkretere Definitionen und Ratschläge an, sondern auch ein sehr nützliches Werkzeug: 10 Fragen anhand derer ein Team feststellen kann, mit welchen Stakeholdern es zu tun hat und was deren Interessen und Betroffenheiten sind.

Marty Cagan und Joakim Sundén: The Product Model at Spotify

Eines vorweg, um Missverständnisse zu vermeiden: das was Marty Cagan und Joakim Sundén hier beschreiben, ist nicht das berühmt-berüchtigte organisatorische Spotify Model mit seinen Tribes, Chaptern, Gilden und Squads, sondern der grundlegende Ansatz, wie bei Spotify mit Produktentwicklung, Produktstrategie und Product Discovery umgegangen wird. Verkürzt gesagt baut es auf möglichst autonome (Teil-)Produkt-Teams auf, die Erkenntnisse aus dem beobachteten Benutzerverhalten verwenden, um durch kleine, schnell validierbare Veränderungen die Nutzungsintensität hochzutreiben. Wer ähnlich erfolgreich wie Spotify werden will sollte sich eher an diesem Product Model orientieren als an der Organisationsstruktur.

Steve Denning: Escaping From The Prison Of ‘Processes’ (Part I, Part II)

Was Steve Denning von praktisch allen anderen Vordenkern der agilen Bewegung unterscheidet, ist seine Zielgruppe. In seinen Kolumnen auf Forbes.com richtet er sich explizit an CEOs und andere Top-Manager, was dazu führt, dass er auch seine Analysen und Lösungs-Ideen auf diese Gruppen ausrichtet. Seine Zusammenfassung des Weges, der grosse Unternehmen in das "Gefängnis obsoleter Prozesse" geführt hat und seine Anleitung zum "Ausbruch" aus diesem Gefängnis sind vor diesem Hintergrund zu lesen. Mit seinen dazugehörenden Ausführungen zu Aktienkursen, ISO-Standards und Management-Rekrutierung ist er entfernt von der sonst dominierenden Team- und Produktzentrierung, und genau deshalb eine wertvolle Ergänzung.

Thorsten Ball: Why We Don’t Ship Software as Fast as We Used To

Von älteren Entwicklern und Managern hört man es immer wieder: "früher" wurde Software schneller entwickelt und zum Kunden gebracht als "heute". Das Bemerkenswerte daran - selbst wenn man Vergangenheitsverklärung und Fortschrittspessimismus mit in Betracht zieht, ist diese Aussage (scheinbar) richtig, wie Thorsten Ball anhand der aus heutiger Sicht atemberaubend schnellen Entwicklung der Computerspiel-Klassikers Doom aufzeigt. Die Erklärung, die er für die (scheinbare) Verlangsamung mitliefert ist die, dass die heutigen Software-Produkte um ein vielfaches komplexer sind als die früheren, diese Komplexität (unterschiedliche Endgeräte, grössere Betriebssysteme, permanente Internet-Verbindung, mehr Nutzer, etc.) aber nicht auf den ersten Blick erkennbar ist. Sicher ein wichtiger Faktor für die häufigen Missverständnisse zwischen "Business" und "Development".

Benji Weber: One does not simply deliver software

Sprache formt unsere Wirklichkeit, oder zumindest deren Wahrnehmung durch uns. Aufbauend auf diese Erkenntnis erklärt Benji Weber, warum es keine gute Idee ist, das zur Verfügung stellen neuer Software-Funktionen als Delivery (Auslieferung) zu bezeichnen. Verkürzt gesagt: es erweckt den Eindruck, dass alles einfacher, aber auch fragiler wäre als es eigentlich ist, und sorgt dadurch für unrealistische Erwartungshaltungen und unnötige Befürchtungen, die früher oder später zu Konflikten führen müssen.

Cost of Delay

Wenn der Mehrwert von schneller Auslieferung und schneller Reaktion auf Veränderungen beschrieben wird, gehört die Vermeidung von Verspätungskosten oder "Cost of Delay" zu den am häufigsten genannten Vorteilen. Don Reinertsen, der Erfinder des Begriffs, beschreibt ihn als die Summe, die pro Zeiteinheit (Monat, Jahr, etc.) nicht eingenommen wird, weil Produkte zu spät fertig werden. Das ist auch richtig, wie er selbst sagt aber nur verkürzt dargestellt.

Will man kalkulieren, mit welchen Verzögerungskosten man im Fall einer verspäteten Fertigstellung konfrontiert werden wird, sollte man das Konzept auffächern: gibt es unterschiedliche Arten von Kosten, und von welchen würde man betroffen sein? Die Antwort auf diese Frage wird je nach Einzelfall anders ausfallen, die folgenden Typen sind aber diejenigen, mit denen am häufigsten zu rechnen ist und die man daher in die Überlegungen einbeziehen sollte.

1. Vepasster Absatz/Gewinn pro Zeit-Einheit

Der einfachste, und von Reinertsen am häufigsten genannte Fall. Bei einem angenommenen Gewinn von zwölf Millionen pro Jahr betragen die Verspätungskosten etwa eine Million pro Monat. Dieser Schätzwert macht Abwägungen möglich. Z.B. wenn man in diesem Fall durch Investitionen von sechs Millionen ein halbes Jahr schneller am Markt wäre - wäre das den Aufwand wert (nein, eher nicht).

2. Verpasstes Saison-Geschäft

Ein etwas komplizierterer Fall. Oft ist der voraussichtliche Gewinn nicht gleich über einen längeren Zeitraum verteilt, sondern konzentriert sich auf saisonale Phasen (z.B. Weihnachten) oder nach wichtigen Veranstaltungen (z.B. Messen). Eine Verspätung zu diesen Zeiträumen hätte eine hohe Cost of Delay, eine Verspätung mit restlichen Jahr eine geringe oder gar keine.

3. Strafzahlungen wegen Verspätung

Vor allem in regulierten Branchen können auch Strafzahlungen Teil der Verspätungskosten sein. Wenn beispielsweise eine Bank ihren Compliance-Bericht nicht rechtzeitig fertigstellt, kann die Bafin eine Geldstrafe verhängen (hier ein Beispiel). Da die Höhe dieser Strafen sich ungefähr abschätzen lässt, sind auch sie als Cost of Delay bezifferbar.

4. Verpasster Abbau technischer Schulden

Die technischen Schulden sind ein ähnliches Konzept wie die Verspätungskosten. Wenn man in der IT bestimmte effizienzsteigernde Faktoren (modulare Architektur, Testabdeckung, etc.), vernachlässigt, wird man dauerhaft langsamer. Sinkt beispielsweise das Arbeitstempo durch zu viele manuelle Testprozesse um 10 Prozent, lässt sich das in Zeit und damit in Geld umrechnen.

5. Verlorenes Feature-Wettrennen

Eine Variante der ersten, einfachsten Art von Cost of Delay. Wenn ein Wettbewerber ein ähnliches Produkt entwickelt, bedeutet eine Verzögerung nicht nur, dass man später mit dem Geld verdienen beginnt, sondern, dass das auch signifikant geringer ausfällt, da ein Teil der potentiellen Kunden sich dann bereits für das Angebot der früher fertig gewordenen Konkurrenz entschieden hat.

6. Verpasste Besetzung eines neuen Marktes

Gewissermassen die Steigerung eines Feature-Wettrennens. Sowohl bezogen auf neue Käufergruppen als auch bezogen auf neuartige Produkte kann es von grossem Vorteil sein, der Erste zu sein, der diesen Markt besetzt. Alle die später in Konkurrenz zu diesen Pionieren treten, müssen mit einem deutlich höheren Aufwand für Marketing und Vertrieb rechnen, so dass auch hier Zeit gleich Geld ist.

Was bei dieser Übersicht über die verschiedenen Arten von Cost of Delay, bzw. Verzögerungskosten auffällt, ist, dass ihre Grösse nach unten immer weniger abschätzbar wird. Das liegt daran, dass auch der sich verspätende Liefergegenstand nach unten immer grösser und unkonkreter wird. Das bedeutet natürlich nicht, dass man in diesen Fällen nicht über eine Cost of Delay nachdenken sollte, man sollte aber diese Ungenauigkeit in den Schätzungen abbilden.

Feature Factory

Bild: Wikimedia Commons / Alien Property Custodian - Public Domain

Ein Begriff an dem man immer wieder vorbeikommt, wenn es darum geht, ein (negatives) Gegenstück zur agilen Produktentwicklung zu finden, ist die so genannte Feature Factory. Genauer erklärt wird er allerdings nur selten, und wenn, dann meistens nur mit Assoziationen zu Akkordarbeit und starren Kontrollstrukturen. Dabei steckt durchaus mehr dahinter, wenn man es sich näher anschaut. Starten wir damit in einer weit zurückliegenden Vergangenheit.

Im frühen 20. Jahrhundert sind die meisten industriellen Betriebe noch wie Manufakturen organisiert. Es gibt zwar bereits erste berufliche Spezialisierungen und Befehlsketten, die eigentliche Arbeit wird aber noch von Hand durchgeführt, in der Regel von mittelgrossen, crossfunktionalen Teams, die ihre Produkte (Kameras, Autos, Plattenspieler, etc.) Stück für Stück vollständig erstellen, was oft eher den Charakter von Einzelanfertigungen als von Serienfertigung hat.

Diese Serienfertigung kommt erst zu dieser Zeit auf, ihre Erfindung wird vor allem mit den Industriellen Frederick Winslow Taylor und Henry Ford verbunden. Sie sorgen dafür, dass die Arbeit auf hoch-spezialisierte Teams übergeht, die jeweils nur noch wenige, immer gleiche Handgriffe an nur einer Station einer motorisierten Fertigungskette (dem Fliessband) vornehmen. Dass daraus am Ende ein Produkt entsteht, wird durch das Management sichergestellt, das die Fertigungskette entwirft und überwacht.

Erst durch diese hochspezialisierte und teilautomatisierte Serien-, bzw. Fliessband-Fertigung werden Produkte so billig, dass sie mit Erfolg auf dem Massenmarkt verkauft werden können, was dazu führt, dass diese Methoden nach und nach von allen Firmen übernommen werden (bzw. dass die, die sich nicht darauf umstellen, vom Markt verdrängt werden). Zuerst geschieht das in den Fabriken, später aber auch in anderen Bereichen, z.B. in Grossküchen, grossen Büros oder in Call Centern.

Besonders die letzte Entwicklung ist dabei von Bedeutung: nach und nach werden im zwanzigsten Jahrhundert fast alle Wirtschaftszweige nach den Ideen von Winslow und Ford umgeformt, bis irgendwann der Eindruck entsteht, dass sie überall anwendbar und zielführend sind. Dass das dann irgendwann auf Fälle treffen muss, in denen das eben nicht der Fall ist, ist naheliegend. Und damit kommen wir zu einer dieser Ausnahmen, der Softwareentwicklung.

Auf den ersten Blick kann man auch in der Softwareentwicklung eine Art Fertigungskette für neue Funktionen (eben die Feature Factory) aufbauen. Am Anfang steht das Anforderungsmanagement, dann das Anwendungsdesign, dann das Schreiben des Code, die Integration der einzelnen Komponenten, die Qualitätssicherung und schliesslich die Auslieferung. Es scheint nahezuliegen, dafür sequenziell angeordnete Spezialistenteams aufzubauen. Das Problem bei diesem Vorgehen: man bekommt am Ende zwar Ergebnisse, aber leider nicht die, die man gebraucht hätte.

Bedingt dadurch, dass man Software per Copy & Paste vervielfältigen kann, kommt es bei ihrer Erstellung nie zu einer wirklichen Serienfertigung, stattdessen wird lediglich ein Einzelstück nach dem anderen erstellt und das dann gleichzeitig an alle Nutzer ausgeliefert. Da diese Einzelstücke aber jeweils individuell anders sind, müsste die "Software-Fertigungsstrasse" eigentlich jedes mal neu konzipiert werden, da sonst die spezialisierten Einzeltätigkeiten nicht sauber ineinandergreifen.

Das allerdings ist kaum realisierbar, alleine wegen des damit verbundenen Umgewöhnungs-Aufwands der jeweiligen Spezialisten. Die sinnvolle Lösung wäre daher eine Rückkehr zum Manufaktur-Prinzip. Crossfunktionale Teams mit relativ geringer Spezialisierung erstellen ein Software-Produkt nach dem anderen und passen ihre Abläufe dabei jedes einzelne mal so an, dass sie für die in diesem Fall vorhabdenen Erfordernisse passend sind. So weit, so (scheinbar) einfach.

In der Realität wird die eigentlich gut nachvollziehbare Tatsache, dass Softwareentwicklung sich nicht wie eine Fabrik organisieren lässt, von vielen Managern und Unternehmensberatern bis heute bestritten. Sei es wegen fehlendem IT-Bezug, aus Methodismus (das klappt doch überall, also auch hier) oder aus welchem Grund auch immer - wieder und wieder trifft man vor allem in grösseren Firmen auf Fälle, in denen Entwicklungsabteilungen oder -ressorts als Feature Factories organisiert sind.

Praktisch immer führt das zu einer von zwei Dysfunktionen: entweder ist die "Fertigungsstrasse" nicht so optimiert, wie es im jeweiligen Einzelfall nötig wäre, was zu Ineffizienz und Fehleranfälligkeit des Prozesses führt, oder das Design der neu zu bauenden Funktionen wird an den vorhandenen Erstellungsprozess angepasst - im Zweifel auf Kosten der Marktbedürfnisse, was geringere Akzeptanz beim Kunden und geringeren wirtschaftlichen Erfolg zur Folge hat.

Diese Entwicklungen sind der tatsächliche Grund dafür, dass in der Softwareentwicklung Feature Factories hoch problematisch und anti-agil (im Sinne von einschränkend für Geschwindigkeit und Flexibilität) sind. Und selbst wenn man es nie schaffen wird, jeden zu überzeugen - ein besseres Argument als die Ablehnung von gefühlter Akkordarbeit und starren Kontrollstrukturen sind sie auch.