Freitag, 30. August 2019

Kommentierte Links (LII)

Bild: Unsplash / Compare Fibre - Lizenz
  • Mark Lambertz - Warum der Begriff VUCA nicht taugt

  • Für jeden der sich im Umfeld der agilen Frameworks und Vorgehensmodelle bewegt ist das Konzept der Komplexität dauerpräsent. Komplexität wird regelmässig als Ursache, Gegenspieler oder Rahmenbedingung von Agilität genannt, bleibt aber angesichts dieser zentralen Bedeutung erstaunlich unkonkret in der Beschreibung. Mark Lambertz macht sich die Mühe und beleuchtet den Begriff ausführlich von verschiedenen Seiten - und wer mich kennt wird wissen, dass es die Exkurse in die Geisteswissenschaften sind die mir gefallen. Was ich an der Stelle ausserdem interessant finde ist seine Einordnung der über-trivialisierenden Begriffsverwendung in die Kategorie "Beratersprech". Ich selber habe das eher bei autodidaktischen und voreilig selbstsicher gewordenen Kunden erlebt, deren gestrandete agile Pilotprojekte ich aus dem Jammertal herausbegleiten durfte. Letzten Endes ist wohl beides subjektiv.

  • Marcus Raitner: Der Hofnarr an der Seitenlinie

    Der Begriff des Hofnarrs reizt mich zwar immer noch zum diskutieren, abgesehen davon hat Marcus Raitner aber recht. Wenn der Scrum Master seine Rolle als Servant Leader so missversteht, dass er im Team und/oder im Unternehmen die unangenehmen Aufgaben übernimmt, ist irgendetwas ordentlich schiefgelaufen. Egal ob als Mini-PMO, als "Teamsekretärin" oder als Dev-Support, das alles sind Varianten einer schlechten Rollen-Interpretation die es so nicht geben sollte. Dass es doch immer wieder dazu kommt hat so viele Gründe wie Varianten, gültig ist aber hier der unsterbliche Satz von Franz-Josef Strauss: Everybody's darling is everybody's Depp.

  • John Cutler: So You Want to Fix Something?

    Service-Durchsage: John Cutler hat einen neuen Blog mit der skurrilen URL https://cutle.fish. In einem seiner ersten Einträge geht er gleich wieder in die Tiefe und reflektiert was er besser schon früher gewusst hätte um erfolgreiches Change- und Innovationsmanagement zu betreiben. Im Grossen und Ganzen ist es das was der gesunde Menschenverstand nahelegt (zumindest der in agilen Projekten sozialisierte gesunde Menschenverstand). Überschaubare Experimente, Begrenzung paralleler Arbeit, iteratives Vorgehen, nicht alles auf eine Karte setzen. Was aus Sicht eines Agile Coaches ungewöhnlich ist, ist der Ratschlag nicht mit einem speziellen Ansatz identifizierbar zu sein. Der Gegenentwurf zur Fokussierung auf SAFe, Kanban, Scrum, etc.

  • Willem-Jan Ageling: How Managers slowly got removed from Scrum

    Das ist interessant - der Anti-Management-Touch den Scrum heute hat war nicht von Anfang an gegeben. Dass es in der Anfangszeit noch eine Übergangsphase mit deutlich erkennbaren Management-Rollen gegeben haben muss ist zwar naheliegend, in welchem Ausmass das der Fall war ist aber im Rückblick bemerkenswert. Ein Satz wie "[The] Management deals with backlog, risk, and release content” würde heute als schweres Antipattern gelten. Auch dass die letzten Spuren der Management-Rollen erst 2011 aus dem Scrum Guide entfernt wurden überrascht, gefühlt hätte das früher der Fall sein müssen. Vor allem sticht aber die Gegenläufigkeit zweier Tendenzen ins Auge: je mehr das Management aus seinen Regeln verschwunden ist, desto erfolgreicher ist Scrum geworden.
    (siehe auch: Ist der Scrum Master ein Manager?)

  • Katharin Tai: So geht Widerstand

    Mal wieder ein Blick über den Tellerrand. Wie geht man damit um in einem technologisch hochgerüsteten Überwachungsstaat von der Regierung verfolgt zu werden? Mit einer bis ins extrem getriebenen dezentralen Organisationsform. Dieser Artikel aus der Zeit bietet einen faszinierenden Einblick in die Strukturen der demokratischen Proteste in Hong Kong, die so un-hierarchisch sind, dass es nicht mehr gelingt sie durch die Verhaftung von Führungsfiguren zu schwächen.

Montag, 26. August 2019

Epics

Bild: Wikimedia Commons / Sarah Welch - CC BY-SA 4.0
Zu den Begriffen aus dem agilen Umfeld die immer wieder kontrovers diskutiert werden gehört das Epic. Es gibt zwar in den meisten Fällen die Übereinstimmung, dass es sich dabei um eine grössere Anforderungs- oder Planungseinheit handelt, alles was darüber hinausgeht wird aber sehr unterschiedlich verstanden. Zeit um Klarheit zu schaffen.

Ein Epic ist zunächst nichts anderes als eine User Story die zu gross ist um umgesetzt zu werden ohne vorher aufgeteilt worden zu sein. Wann, wo und in welchem Kontext diese Verwendung entstanden ist lässt sich vermutlich nicht mehr genau klären, bereits 2004 wird diese Verwendung vom Scrum-Pionier Mike Cohn in seinem Buch User Stories Applied aber schon mit grosser Selbstverständlichkeit vorgetragen1. Aber was ergibt sich aus dieser Bedeutung?

Zunächst, dass Epics genau wie normale User Stories verschiedene Voraussetzungen erfüllen müssen. Sie sollten einen End-to-End-Ansatz verfolgen2, in einfacher, verständlicher Sprache geschrieben sein, einen Anwender nennen3, den gewünschten Use Case, bzw. das zu lösende Problem beschreiben und auch nachvollziehbar darstellen welcher Mehrwert neu geschaffen werden soll. Die Gleichartigkeit von User Story und Epic lässt sich bereits daran erkennen, dass die Begriffe sich alleine durch eine Neuschätzung des Aufwandes vertauschen können.

Genau wie im Fall von User Stories ist es auch bei Epics möglich sie durch Zusatzinformationen anzureichern. Das können Akzeptanzkriterien sein, Personas oder Kundenfeedbacks, es gibt aber auch eine Form der Zusatzinformation die Epic-spezifisch ist: die Benennung der an der Umsetzung beteiligten Teams. Wenn das mehrere sind (wofür es verschiedene Gründe geben kann) erleichtert das die Nachverfolgung und Koordination des Arbeitsfortschritts.

Zuletzt ist es noch wichtig, dass Epics in überschaubarer Zeit abschliessbar sein müssen. Ohne die Begrenzung des Scrum-Sprints oder der XP-Iteration ist es ein verlockender Fehler den Rahmen so weit zu ziehen, dass am Ende eher ein Anforderungs-Kategorie als eine Anforderung steht (z.B. "Benutzerverwaltung" oder "Shop". Das ist nicht im Sinn der Idee und sollte vermieden werden.


1Danke für die Hinweise auf Mike Cohns Buch, allerdings wurde der Begriff dort nicht erfunden oder eingeführt. Auf Seite 6 heisst es "When a story is too large it is sometimes referred to as an epic." Die Verwendung gab es also auch schon früher.
2D.h. es sollte keine ausgelagerten Konzeptions-, Umsetzungs-, (Regressions)Test-, Dokumentations- oder Release-Epics geben
3Anwender ≠ Auftraggeber

Donnerstag, 22. August 2019

Andon

Bild: Pxhere - CC0 1.0
Zu den grossen Inspirationsquellen für jeden der seinen agilen Prozess verbessern will gehört zweifellos das Toyota Production System (TPS). Selbst wenn es ursprünglich für die Industrieproduktion von Autos vorgesehen war enthält es zahlreiche Elemente, die auch in der Software-Programmierung oder Wissensarbeit von Nutzen sein können. Eines dieser Elemente ist das so genannte Andon (行灯, übersetzt rote Laterne, bzw. Papierlaterne).

Unter diesem Begriff versteht man Systeme oder Prozesse mit denen ganze Produktionsketten (in der Regel Fliessbänder, aber auch alles andere) schlagartig zum Stillstand gebracht werden können sobald ein Fehler auftritt. In den meisten Fällen erfolgt das durch Zugschnüre oder grosse Druckknöpfe (auch bekannt als Toyota-Buttons) die überall entlang der Fertigungsstrassen zu finden sind. Im weiteren Sinn gehören auch Signaltöne und Datenerfassungssysteme zu den Andon-Installationen dazu.

Bemerkenswert sind an diesem Konzept vor allem zwei Aspekte. Zum einen wird das Wesen eines Fehlers hier anders verstanden als üblich. Der Fehler ist nicht mehr die Beschädigung oder Minderwertigkeit des "fehlerhaften" Produkts sondern die Dysfunktion des vorhergegangenen Herstellungsprozesses. Dementsprechend folgt auf das Anhalten der Produktionskette auch eine Neukonfiguration des Prozesses und nicht eine Reparatur des Produkts (die soll überflüssig werden).

Zum anderen sind die Zugschnüre oder Druckknöpfe nicht nur überall angebracht sondern auch für jeden zugänglich - und es hat auch jeder die Berechtigung sie zu benutzen. Darüber hinaus ist ihre Benutzung auch prinzipiell nicht mit negativen Folgen verbunden, auch dann nicht wenn der Produktionsausfall auch Gewinnrückgänge nach sich zieht. Es soll alles vermieden werden was von ihrer Benutzung abhält, damit nichts der Idee einer möglichst fehlerfreien Auslieferung im Weg steht. Die Idee dahinter: der langfristige Nutzen ist weit grösser als ein kurzfristiger Verlust.

Übertragen auf die Softwareentwicklung wären vor allem die Tolerierung "unkritischer Bugs" oder die dauerhafte Durchführung zu vieler (potentiell fehlerhafter) manueller Prozesse Gründe für das Auslösen eines Andon-Systems. Da derartige Verhaltensmuster fast immer die Durchführung von langen, nachgelagerten Regressionstest- und Bugfixing-Phasen zur Folge haben verhindern sie die kontinuierliche Auslieferung von Geschäftswert und sind damit kritisch genug für einen Produktionsstop.

Das Gegenargument ist an dieser Stelle das selbe wie in der Fabrik: "Aber damit verhindert man doch das Einhalten der Produktionsquote, bzw. der Deadline!" Allerdings ist das nur bedingt richtig. Wenn zwar die Menge und das Zieldatum stimmen, die Arbeitsergebnisse aber defekt sind, dann ist der Erfolg nur ein scheinbarer. In Wirklichkeit sind Kosten und dauer sogar höher, sie werden nur in späteren Phasen versteckt.

Um das nicht geschehen zu lassen macht ein roter Knopf an jedem Arbeitsplatz absolut Sinn.

Montag, 19. August 2019

Rebound-Effekt

Grafik: Public Domain Pictures / Witali Smoligin - CC0 1.0
In Change-Vorhaben (egal ob agil oder klassisch) gibt es Phänomen das gleichermassen häufig wie ärgerlich ist: ineffektive Prozesse haben in der Vergangenheit dazu geführt, dass sich vor den umsetzenden Einheiten (Fertigung, IT, etc) ein Rückstau gebildet hat, dessen Sichtung und Verwaltung Ressourccen bindet und zu Bürokratie führt. Prozessverbesserungen sollen helfen diesen Stau durch schnellere Bearbeitung abzubauen, und tatsächlich wird der Durchsatz erheblich gesteigert. Und trotzdem: die Menge an wartender, unerledigter Arbeit bleibt gleich.

Die dahinter stehende Ursache ist der so genannte Rebound-Effekt. Ursprünglich aus der Energiewirtschaft kommend lässt er sich folgendermassen beschreiben: ein Verbraucher konsumiert eine bestimmte Ressource. Eine Effizienzsteigerung des Ressourcenverbrauchs sorgt dann dafür, dass der Verbraucher weniger konsumieren muss als bisher. Da sein Budget aber unverändert bleibt benutzt er die frei gewordenen Mittel um zusätzliche Ressourcen zu konsumieren, wodurch der Gesamtverbrauch gleich bleibt.

Dieses Phänomen lässt sich auf Fertigungsprozesse übertragen. In der alten, ineffizienten Prozesswelt hatten der Produktion vorgelagerte Einheiten (Vertrieb, Innovation, etc.) einen doppelten Aufwand: sie mussten zum einen neue Anforderungen erstellen und zum anderen den sich anstauenden Berg der fertigen, aber auf die Umsetzung wartenden Anforderungen dokumentieren, aktuell halten und umpriorisieren. Wenn dieser Berg jetzt durch effizientere Produktionsprozesse verschwindet haben die vorgelagerten Einheiten plötzlich mehr Zeit, die sie nutzen können um noch mehr Anforderungen ins System zu geben, durch die sich trotz der schnelleren Abarbeitung ein neuer Stau bildet, der neue Bürokratie generiert.

Da eine solche Entwicklung sämtliche effizienz- und effektivitätssteigernden Massnahmen wirkungslos machen kann ist ein Gegensteuern dringend nötig. Die zunächst einfach klingende Massnahme: die Menge der neuen Anforderungen darf nur so stark steigen, dass kein neuer Rückstau entsteht. Der Fachbegriff dafür ist das Work in Progress Limit. Das umzusetzen kann aber zu einer Herausforderung werden, da die freigewordenen Kapazitäten ja auch nicht ungenutzt bleiben sollen. Die Konsequenzen (Versetzungen, Umschulungen, Personalabbau in den vorgelagerten Einheiten  oder Personalaufbau in den nachgelagerten Einheiten) sind schwerwiegend, zur Vermeidung des Rebound-Effekts aber nötig.

Donnerstag, 15. August 2019

Denn sie wissen nicht, wen sie rekrutieren (IV)

Bild: Flickr / Amtec - CC BY-SA 2.0
Angeregt vom neuesten Artikel des geschätzten Marcus Raitner wird es Zeit die etwas eingeschlafene Reihe "Denn sie wissen nicht, wen sie rekrutieren" wieder fortzuführen. Im Artikel geht es um die (autobiografische?) Geschichte eines Menschen der sich zum ersten mal im Leben bei einem Konzern bewirbt, und von seinem Befremden angesichts der ihm dort begegnenden Formalismen und Bürokratien. Obwohl er natürlich nur einen Einzelfall beschreibt ist er symptomatisch für ein grundlegendes Phänomen.

Seit auch die grossen Organisationen die Agilität für sich entdeckt haben (und umgekehrt) prallen bei den Ausschreibungs- und Einstellungsprozessen zwei Welten aufeinander. Auf der einen Seite die Personalabteilungen, die mit grösster Selbstverständlichkeit davon ausgehen, dass das "seit langem bewährte" Vorgehen auch weiterhin das Richtige ist, auf der anderen Seite die in der agilen Bewegung sozialisierten Fachkräfte, die diesen von ihnen als anachronistisch empfundenen Routinen mit Fassungslosigkeit gegenüberstehen.

Beide Sichtweisen lassen sich nachvollziehen. Die Personalstellen sind jahrzehntelang durch Taylorismus und (Pseudo-)Lean Management so optimiert worden, dass sie die eingehenden Bewerbungen in möglichst einheitlichem Format erwarten. Das ist schliesslich die Voraussetzung dafür, dass sie alle möglichst schnell den selben Bearbeitungsvorgang durchlaufen können. Branchenerfahrung? Check. Führungserfahrung? Check. Budgetverantwortung? Check. Ab in die zweite Auswahlstufe. Um sich jeden Kandidaten genau anzusehen fehlt einfach die Zeit.

Darüber hinaus sind sie (oft unbewusst) in einen beruflichen Standesdünkel hineinsozialisiert worden. Bei einem Automobilbauer zu schaffen, Banker zu werden oder bei einem Verlag zu arbeiten ist Errungenschaft und Ehre, dafür soll sich der Bewerber ruhig anstrengen, und zwar so, dass man es sieht. Mit makellosem Lebenslauf und überzeugenden Argumenten warum man denn gerade ihn nehmen sollte. Flüssig formuliert, ansprechend formatiert und auf hochwertigem Papier eingereicht bitteschön.

Auf der anderen Seite die vom Fachkräftemangel selbstbewusst gemachten Bewerber. Im eigenen Projektportfolio steht doch übersichtlich und nachvollziehbar drin was man gemacht hat, welchen Wert soll es haben das chronologisch anzuordnen? Und dann die Kategorien. Budget- und Führungsverantwortung sind doch für Lead Developer und Scrum Master irrelevant. Und warum gibt es trotz so vieler geforderter Pflichtangaben keine in die die Mob Programming Skills und der Link zum eigenen Open Source-Projekt passen würden?

Auch der Standesdünkel ist da, allerdings umgekehrt. Konzern? Allein der Begriff klingt schon nach Cobol. Da kann man gespannt sein ob die auch nur annähernd den gleichen Techstack bieten können wie das Fintech in der Innenstadt. Und hoffentlich halten die nicht an solchen Relikten des 19. Jahrhunderts fest wie Krawatten und festen Arbeitsplätzen. Zumindest kann man ja wohl erwarten, dass für Bewerbungen auch eine 40 Jahre alte Technologie wie die Email akzeptiert wird.

Sollte es dann trotz all dieser Hindernisse doch zu einem Job-Interview kommen, werden die Differenzen häufig erst richtig sichtbar. Während die Konzern-Seite davon ausgeht, dass der Bewerber hier nach seiner Lebensstellung sucht will dieser nur "ein paar spannende Jahre" erleben, und während die Personalerin stolz von der Betriebsrente und der Betriebssportgemeinschaft erzählt will ihr Gegenüber über Homeoffice und Slacktime reden. Das alles gerinnt in Wortwechseln wie diesem hier: "Wo sehen sie sich in drei Jahren?" "Keine Ahnung, so lange will ich hier nicht bleiben."1

Bis vor nicht allzulanger Zeit hätten diese Differenzen dazu geführt, dass diese "unpassenden" Bewerber einfach aussortiert wurden. Aber das ist vorbei, die zunehmende Agilisierung, Digitalisierung, Automatisierung und Cloudifizierung sorgt dafür, dass grosse Firmen froh sein können wenn sie ihren Bedarf überhaupt gedeckt bekommen. Und jetzt stehen die Personalabteilungen vor einem Problem: nicht nur können sie die Ansprüche der begehrten Fachkräfte kaum befriedigen ohne die eigenen, "seit langem bewährten" Vorgehensweisen in Frage zu stellen, oft wissen sie gar nicht welche Ansprüche das sind. Und dann das Schlimmste: sobald diese ermittelt wurden ändern sie sich.

Um die in der agilen Bewegung sozialisierten Arbeitnehmer verstehen zu können und um auf ihre Ansprüche eingehen zu können bleibt den Personalern letztendlich nur ein Weg übrig: selbst agil werden. Das ist nicht immer einfach und nicht immer angenehm, wenn es nicht stattfindet drohen aber immer mehr Geschichten wie die von Marcus Raitner. Und dann mit der Pointe dort nicht angeheuert zu haben.


1Der Verfasser dieser Zeilen war amüsierter Zeuge.

Montag, 12. August 2019

You need to stop implementing someone elses model

Ein mitreissend vorgetragener Vortrag mit einigen bedenkenswerten Ideen, aber auch einer bei dem Sander Hoogendoorn es sich sehr einfach macht. Irgendwo zwischendrin sagt er, dass er nicht für grosse Firmen arbeitet - damit braucht er sich folgerichtig auch nicht damit beschäftigen, dass vieles von dem was er vorstellt (kurz gesagt: Strukturen abschaffen) dort nicht funktionieren würde. Trotzdem ein sehenswerter Auftritt. Und er sagt es selbst: man sollte ohnehin nicht einfach die Ideen anderer Leute zu sich übernehmen sondern vorher überprüfen ob sie in der aktuellen Situation passen.


Donnerstag, 8. August 2019

The Agile Bookshelf: FLEAT

Bild: Wikimedia Commons / U.S. Department of Defense Current Photos - CC0 1.0
Viel Neues tut sich in den letzten Jahren nicht mehr im Bereich der Agilität. Seit der Vorstellung von Nexus im Jahr 2015 hat es keine nennenswerten Versuche mehr gegeben ein neues Vorgehensmodell zu entwickeln, weshalb im letzten Monat die Einladung zum Kölner PO-Meetup sofort Aufsehen erregt hat.
Dieses Mal geht es um "FLEAT", ein neues agiles Enterprise Framework: Das Enterprise-Unternehmen als Flottenverband ... eine vielversprechende Metapher. Das Buch von Thorsten Schaar und Uwe Habicher dazu kommt gerade in den Handel. Praktiziert wird FLEAT bei haufe schon. Aber was steckt dahinter?
Freundlicherweise hat Uwe mir im Anschluss auch ein Exemplar seines Buches zukommen lassen, das ich in letzter Zeit durchgelesen habe und jetzt besprechen kann.

Was ist FLEAT?

Ein bei Haufe-Lexware erfundenes agiles Framework, dessen Name unabgekürzt "Fluid Enterprise Agility Transformation" lautet. Was es interessant macht: es konzentriert sich auf einen Bereich der von den gängigen Ansätzen noch nicht besetzt ist. Während es in Scrum, SAFe, Nexus und LeSS um Lieferzyklen, Rollen und Meetings geht, in Design Thinking um Kreativität, in Kanban um die Optimierung von Arbeitsflüssen und in XP um technische Praktiken steht bei FLEAT etwas anderes im Vordergrund: Investitionsentscheidungen.

Die verschiedenen "Schiffstypen"

Je nach Fortschrittsgrad wird unterschieden zwischen der Startbahn, dem Floss, dem Ruderboot, dem Dampfschiff und dem Kreuzfahrtschiff. Ideen für ein neues Fahrzeug darf dabei jeder im Unternehmen haben, ob darin investiert wird ist aber eine Management-Entscheidung. Die Investition in die Startbahnphase besteht noch aus der Arbeitszeit die den Mitarbeitern für die Ausarbeitung von Ideen zur Verfügung steht, das Floss enthält eine Frühfinanzierung (die ggf. klein genug für eine schmerzfreie Abschreibung ist), das Ruderboot erhält bereits in nennenswertem Ausmass Ressourcen, das Dampfschiff ist schon eines der wichtigen Investments, das Kreuzfahrtschiff ist gross genug um Kern einer eigenen, neuen Flotte zu werden.

Wer ist die Zielgruppe?

Auf den ersten Blick "Leute mit Budget". Ob das die Geschäftsführung ist, der Chief Innovation Officer oder sonst jemand - er muss die Investitionen tätigen (und ggf. die Verluste verantworten) können auf denen der Ansatz beruht. Hier liegt eine Stärke von FLEAT, da sich diese Gruppe in den anderen, eher operativen Frameworks nicht immer wiederfindet. Auf den zweiten Blick stehen aber auch die Mitarbeiter im Mittelpunkt, denen es durch das Einbringen und Verwirklichen von ihren Ideen ermöglicht wird zu Intrapreneuren zu werden.

Ist das denn agil?

Ja, ist es. Es mag eine andere Art der Agilität sein als die die man mit Scrum, Kanban, XP und den Skalierungsframeworks verbindet, es hat aber das entscheidende Element: Reaktionsgeschwindigkeit. Neue Ideen sollen schnell aufgegriffen werden, schnell validiert werden und schnell (und früh) scheitern können - überwiegend schon in den frühen Phasen. Um das zu erreichen sollen die "Schiffe" an den aus anderen Frameworks bekannten Prinzipien ausgerichtet sein: kundenzentriert, End-to-End-verantwortlich, autonom, sich kontinuierlich verbessernd, etc.

Ist es wirklich neu?

Nur eingeschränkt. Die Idee durch die Investition in kleine, innovative Einheiten das Risiko von grösseren Verlusten zu minimieren ist aus Ansätzen wie der Effectuation schon länger bekannt, Konzepte wie Intrapreneurship und Minimum Viable Products (möglichst früh validierbare Produktumfänge) kommen auch im Lean Startup vor, autonome und crossfunktionale Teams gibt es auch in Scrum, bzw. seinen Skalierungsframeworks. Was man FLEAT lassen kann ist, dass diese Elemente zu einem in sich konsistenten Ganzen paketiert wurden. Und was ist schon wirklich neu?

Gibt es Probleme?

Wo gibt es die nicht? Ins Auge springt vor allem, dass die Mitarbeiter in den frühen Evolutionsstufen (Startbahn, Floss, Ruderboot) nur in Teilzeit für das Vorhaben arbeiten und in der restlichen Zeit in ihren bisherigen Jobs. Die damit verbundenen Effizienzverluste (durch Kontextwechsel, Terminüberschneidungen, Priorisierungskonflikte, etc.) haben dazu geführt, dass derartige Arbeitsmodelle in der agilen Bewegung eigentlich verpöhnt sind. Auch die geringe Kompatibilität mit den typischen Organisationsprinzipen von Konzernen (organisatorische Silos, "mittelfristige" Finanzplanung, funktionale Querschnittsorganisationen) dürfte eine Herausforderung werden. Und die angestrebte Kommerzialisierung (siehe hier) dürfte bei weiten Teilen der anti-komerziell entstandenen agilen Community zu Abstossungsreaktionen führen.

Wie gross/erfolgreich wird FLEAT werden?

Eine spannende Frage. Sicherlich würde vielen Firmen dieser Ansatz mehr als nur gut tun (und das Ansetzen an der Finanzierung hätte eine gewaltige Hebelwirkung), die zuvor genannten Probleme dürften aber in den meisten Fällen beachtliche Hindernisse für eine öffentlichkeitswirksame Umsetzung sein. Sollte trotzdem eine gelingen wäre das ein Verkaufsargument auf dem sich aufbauen liesse. Eine "Massenbewegung" wie Scrum oder Kanban dürfte aufgrund der oben genannten anti-komerziellen Reflexe zwar auch dann nicht entstehen, aber vielleicht muss es das auch gar nicht. Und selbst wenn es nur dazu kommen sollte, dass FLEAT als weitere verfügbare Alternative dafür sorgt, dass "Enterprise Agility" nicht mehr automatisch mit SAFe gleichgesetzt wird - allein das wäre ein grosser Fortschritt.

Montag, 5. August 2019

Ein Bild sagt mehr als 1000 Worte (XXVI)