Donnerstag, 31. Dezember 2020

Kommentierte Links (LXX)

FS
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" Texte aus dem letzten Jahr.

  • Mirco Hering: Segregation of Duties in a DevOps world

    Die Segregation of Duties (auch Separation of Duties) kann bei einer agilen Transformation einer der grossen Stolpersteine sein. Wie soll es möglich sein in schneller Taktung benutzbare Ergebnisse zu liefern wenn interne oder externe Vorschriften festlegen, dass bestimmte zusammengehörende Schritte nicht von den selben Personen durchgeführt werden dürfen? Mirco Hering gibt einige Denkanstösse um zu zeigen wie in solchen Situationen vorgegangen werden kann (und noch mehr dazu gibt es von Jez Humble in den kommentierten Links des Oktobers).

  • Elaine Pulakos: Organizational Agility – It’s Not What You Think

    Die "es ist alles anders als Du denkst"-Artikel sollte man immer mit einer gewissen Vorsicht lesen, aber das was Elaine Pulakos hier schreibt scheint Substanz zu haben. Basierend auf 300 untersuchten Unternehmen identifiziert ihr Team drei Voraussetzungen von organisationsweiter Agilität: Stability before Change (stabiler Ausgangszustand vor Beginn der Veränderungsmassnahmen), Rightsized Teamwork (ständige Evaluierung wo funktionsübergreifende Arbeit nötig ist und wo nicht) und Relentless Course Correction (beinhaltet neben schneller Entscheidungsfähigkeit auch Fehlerkultur und Delegation). Schade ist, dass die geplanten Fortsetzungen im Sand verlaufen zu scheinen. Von den drei weiteren angekündigten Artikeln ist in mehreren Monaten nur einer erschienen.

  • Len Lagestee: How Organizational Silos Form

  • Eines der zentralen Ziele einer agilen Organisation ist die Auflösung organisatorischer Silos, bzw. das Verhindern ihrer Entstehung. Vor diesem Hintergrund macht es Sinn sich damit zu beschäftigen was diese Silos sind und wie sie entstehen. Len Lagestee hat sich diesem Thema von verschiedenen Seiten genähert, angefangen mit der Frage was unter diesem Begriff eigentlich zu verstehen ist über die Indikatoren durch die man erkennt, dass sie da sind, bis zu den Faktoren die zu ihrem Entstehen beitragen. Passend zum Namen seines Blogs (Illustrated Agile) enthält sein Beitrag auch eine Visualisierung der zuletzt genannten Faktoren. Gerade für die Vermittlung derartig komplexer Sachverhalte ist so etwas immer gut zu gebrauchen.

  • Jasmine Chia & Samuel Hagen: The Org Chart as Political Map-Making

    Es gibt Management-Werkzeuge die mittlerweile so selbstverständlich geworden sind, dass kam noch jemand darüber nachdenkt wo sie herkommen und in welcher Form sie von ihrer Organisation beeinflusst werden (und sie beeinflussen). Der Organizational Chart, auch Organigramm genannt, ist eines davon. Jasmine Chia und Samuel Hagen haben einen näheren Blick darauf geworfen, und das aus einer ungewöhnlichen Perspektive: analog zur Annahme, dass moderne Staaten erst durch die Entwicklung der Kartografie (der Erstellung von Landkarten) möglich wurden, gehen sie davon aus, dass moderne Organisationen und ihre Organigramme eine ähnlich verbundene Entstehungsgeschichte haben und sich auch in der Gegenwart noch gegenseitig beeinflussen.

  • Akio Toyoda: What is Toyota Production System?

    Dass das Lean Management (und die daraus entstandene agile Produktentwicklung) aus dem Toyota Production System (TPS) entstanden sind dürfte für die agilen Methodiker zum Standardwissen gehören, was sich genau hinter diesem verbirgt ist dann aber für viele schon deutlich unklarer. Dieser Artikel der firmeneigenen Toyota Times hilft hier weiter, da er seine Zusammenfassung direkt von der "höchsten Stelle" erhalten hat: Quelle ist eine Ansprache von Aiko Toyoda, Präsident der Toyota Motor Corporation und Nachfahre des Firmengründers, vor Nachwuchsmanagern. Gut herausgearbeitet wird dabei, dass es im Lean Management/TPS trotz aller Klischees nicht um Effizienzsteigerung um jeden Preis geht, sondern dass der eigene Mitarbeiter im Mittelpunkt steht, dem die eigene Arbeit möglichst leicht gemacht werden soll.

  • Kai-Marian Pukall: OKR: eine kritische Betrachtung

    Ein Artikel der aus mehreren Gründen lesenswert ist. Zum einen liefert Kai-Marian Pukall einen guten Überblick darüber um was es sich bei "Objectives and Key Results" (OKR) und ihrem Vorgänger "Management by Objectives and Self-Control" (MBO) überhaupt handelt, zum anderen zeigt er auf welche Schwachstellen dieser in den letzten Jahren stark gehypete Ansatz hat. Vor allem sind das für ihn die nur scheinbare unternehmensweite Transparenz (niemand wird sich ständig über die OKRs aller Teams informieren), die schlechte Messbarkeit vieler Ziele, das regelmässige obsolet Werden von OKRs durch geänderte Realitäten und das parallele Existieren verschiedener Ziele in jeder grösseren Organisation. Ein guter Kontrapunkt zum in den letzten Jahren etwas überhandnehmenden Hochjubeln .

  • Gary Hamel, Michele Zanini: Harnessing Everyday Genius

    Was Gary Hamel und Michele Zanini hier abliefern ist eine Fallstudie für eine grundlegende Veränderung einer Organisation. Am Beispiel des französischen Reifenherstellers Michelin und seinem "Responsabilisation"-Programm zeigen sie auf wie ein Wechsel weg von traditionellem Command & Control und hin zu Delegation und Subsidiarität ein Unternehmen wirtschaftlich erfolgreicher machen kann. Das Bemerkenswerte dabei - wenn man dem Artikel glauben kann wurde hier keines der üblichen Frameworks eingeführt und nicht einmal die üblichen Schlagworte Lean und Agile wurden benutzt. Wer sie kennt wird trotzdem einiges von ihnen wiederfinden, was ein starkes Zeichen dafür ist, dass es sich um grundlegende Prinzipien handelt.

  • Robert N. Charette: Inside the Hidden World of Legacy IT Systems

    Vor allem in grossen und älteren Firmen (im IT-Kontext alle Firmen die älter als 40 Jahre sind) gehören der Betrieb und die Weiterentwicklung von so genannter Legacy-Software zu den grössten Zeit- und Kostentreibern, aber auch viele jüngere Unternehmen haben bereits in erstaunlich kurzer Zeit erschütternd grosse Probleme mit veralteten Systemen. Robert Charette fasst gut zusammen was Legacy Software ist, welche Auswirkungen es hat sobald sie da ist aber auch wie man damit umgeht. In seinen Worten: "The first step in fixing a massive problem is to admit you have one." und "The best way to deal with legacy IT is to never let IT become legacy." Zuletzt findet sich am Ende des Artikels eine schöne Argumentationshilfe für die nächste Diskussion warum Ablösungsprogramme wichtig sind: eine Liste von Kostenexpolisionen und Systemausfällen die durch veraltete Software entstanden sind.

  • Cal Newport: The Rise and Fall of Getting Things Done

    Der finale Longread. Die Methoden "Getting Things Done" und "Inbox Zero" galten lange als das Nonplusultra der persönlichen Produktivität, sind aber mittlerweile weitgehend in Vergessenheit geraten. Cal Newport erzählt wie es zu Aufstieg und Fall dieser Methoden kam, von den Rahmenbedingungen in denen sie entstanden sind (mit Exkurs zum bereits weiter oben erwähnten Management by Objectives) über den grossen Hype bis hin zu Auswirkungen auf spätere Ansätze wie den in modernen Softwareentwicklungsteams üblichen WIP-Limits.

Montag, 28. Dezember 2020

Kommentierte Links (LXIX)

FS
Leicht verfrüht: die Kommentierten Links des Dezembers. Am letzten Tag dieses Monats folgt eine weitere Ausgabe, dann mit den Artikeln die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.
  • Barry O'Reilly: The Obstacles to Unlearning

    Eine oft unterschätzte Herausforderungen beim Navigieren in einer sich ständig verändernden Welt besteht darin, erlernte Glaubenssätze und Verhaltensmuster regelmässig darauf zu überprüfen ob sie noch immer genau so sinnvoll sind wie zum Zeitpunkt zu dem man sie sich angeeignet hat. Ist das nicht mehr der Fall muss das eigene Verhalten geändert werden, was schwerer ist als man denken möchte - Vieles von dem was wir regelmässig tun wird alleine aufgrund der Routine (und natürlich auch aufgrund der vergangenen Erfolge) als so intuitiv richtig wahrgenommen, dass jede Abweichung davon sich wie ein Fehler anfühlt. Die Trennung von diesen scheinbaren Gewissheiten hat Barry O'Reilly unter dem Label "Unlearning" zu seinem Thema gemacht. In diesem Artikel gibt er eine gute Übersicht, es geht also nicht nur um die im Titel genannten Hindernisse sondern auch darum was er überhaupt unter Unlearning versteht und was gute Beispiele für seine Umsetzung sind.

  • Jens Bergmann / Siegbert Warwitz: "Wenn ein Mensch von einem Bären angefallen wird, dann hat er etwas falsch gemacht"

    In diesem Interview geht es um Wagnisse und Risiken, beziehungsweise um den Umgang damit. Siegbert Warwitz ist Psychologe mit dem Schwerpunkt der Wagnisforschung, die er vor allem an Sportlern und Kindern betreibt, deren Erkenntnisse sich aber auch auf das Berufsleben übertragen lassen. Eine seiner zentralen Erkenntnisse ist dabei, dass das regelmässige Umgehen mit Wagnissen und Risiken zur Sicherheit im Umgang mit ihnen führt, wärend der Versuch sie zu vermeiden Ängste und Unsicherheiten verursacht, welche die Wahrscheinlichkeit von Unfällen sogar erhöhen. Interessant ist dabei auch die Abgrenzungen zwischen den ähnlichen Persönlichkeitstypen des "Wagenden", des (unverantwortlich handelnden) Hasardeurs und des das Wagnis nur simulierenden Teilnehmers an Pseudo-Risiko-Events (wie Bungee Jumping).

  • Stefan Kühl: Agilität – Und täglich grüßt das Murmeltier

    Stefan Kühl hat sich einen Namen gemacht als Kritiker des Hypes der mittlerweile um das Konzept der Agilität gemacht wird, und auch dieser Beitrag von ihm geht in diese Richtung. Im Gegensatz zu vielen anderen die sich an diesem Thema abarbeiten verfällt er allerdings nicht in undifferenziertes Bashing sondern arbeitet reale Probleme heraus, etwa die den Kontext ignorierende Übertragung aus der IT auf alle anderen Bereiche. Seine eigentlich bemerkenswerte These ist aber die, dass es seit den 60ern bereits eine Reihe von Management-Moden gegeben hat die er für weitgehend deckungsgleich mit der Agilität hält. An dieser Stelle hat er vermutlich Recht im Unrecht: ohne den IT-Bezug ist das Ganze tatsächlich nur noch einer von vielen Entbürokratisierungs- und Dezentralisierungs-Ansätzen - aber der IT-Bezug ist für die Agilität zentral und unterscheidet sie von ihren Vorläufern. Und in einer Zeit in der Prozesse und Systeme immer mehr verschmelzen ergibt sich daraus auch wieder eine übergreifende Bedeutung.

  • Jason Yip: Worse is better, also for organisational design

    Das hier passt irgendwie zu den weiter oben verlinkten Überlegungen zu Unlearning und Wagnis: Jason Yip geht davon aus, dass es gerade die Unvollständigkeit und Unausgereiftheit eines Ansatzes ist die zu einem Erfolgsfaktor werden kann. Die scheinbare Einfachheit sorgt dafür, dass zu Beginn wenig Ablehnungen und Widerstände auftreten und es schnell zu einer grossen Verbreitung kommt, gleichzeitig führt die eingeschränkte Praxistauglichkeit dazu, dass ein ständiger Verbesserungsprozess in Gang kommt der nicht nur das Vorgehen kontinuierlich optimiert sondern auch dafür sorgt, dass die Beteiligten Zeit und Energie investieren müssen, weshalb sie sich dem Ergebnis stärker verbunden fühlen. Mit einer gewissen Ironie verbunden ist seine Ansicht, dass ausgerechnet SAFe ein Paradebeispiel für Unvollständigkeit und Unausgereiftheit ist - die Wahrnehmung durch seine Beführworter ist schliesslich die genau umgekehrte.

  • Rob Lambert: How to find levers of change in your company

    Die zentrale These dieses Artikels von Rob Lambert ist, dass es in den meisten Organisationen nur wenige zentrale Hebel gibt die man bedienen muss um zu mehr Agilität zu kommen. Bewusst und richtigerweise behauptet er nicht im Besitz absoluter Wahrheiten zu sein, als Ausgangspunkt für eine Entwicklung einer Transitionsstrategie sind seine Überlegungen aber gut zu verwenden. Und obwohl es am Ende wieder auf sehr globale Phänomene wie Arbeitsfluss, Transparenz, Zielklarheit und Empowerment zurückkommt gibt er auch einige konkrete Hilfestellungen mit indem er erwähnt wo man nach ihnen suchen kann und wie man sie erkennt.

Donnerstag, 24. Dezember 2020

I can see a better time

FS

Passend zu diesem tragischen und verrückten Jahr ist dieses Weihnachtslied ein schwermütiges, das den Geist der erzwungenen Remote-Arbeit einfängt, dabei aber gleichzeitig auch einen trotzigen Optimismus verströmt. Vermutlich die Haltung die wir jetzt alle brauchen können.



Übrigens: wer möchte findet auf der Youtube-Seite des Videos eine Möglichkeit für einen guten Zweck zu spenden. Auch das passt ja zu Weihnachten.

Montag, 21. Dezember 2020

The agile Bookshelf: No Rules Rules

FS
Bild: Pexels / Fabio Lange - CC0 1.0

Wer gerade nach einem Geschenk für irgendeinen im Dunstkreis der Agilität arbeitenden Menschen sucht kann dieses Buch ins Auge fassen: No Rules Rules: Netflix and the Culture of Reinvention von Reed Hastings und Erin Meyer ragt aus der "agilen Fachliteratur" heraus, da es nicht der gefühlt hundertste Erklärband der Prinzipien und Frameworks ist, sondern ein Praxisbericht aus einem der grossen agilen Vorzeigeunternehmen.


In ihm findet man bereits auf den ersten Seiten das was Netflix1 je nach Sichtweise berühmt oder berüchtigt gemacht hat: das Herunterfahren von Prozessen und Vorschriften auf ein Minimum, grösstmögliche Offenheit und Ehrlichkeit im Umgang untereinander und Streben nach hoher Talentdichte, das letzte verbundem mit dem kontroversen so genannten "Keeper Test", bei dem jeder Manager sich regelmässig zu jedem seiner Untergebenen die Frage stellen soll ob er dafür kämpfen würde ihn zu behalten - um jeden bei dem das mit Nein beantwortet wird sofort zu entlassen.


Der Grossteil des Buches dreht sich dann darum wie diese drei Ziele (wenig Prozesse, grosse Ehrlichkeit, hohe Talentdichte) über die Zeit weiterentwickelt wurden, was sich damit zusammenfassen lässt, dass sie jeweils durch drei Phasen geführt werden: Einführung, Stabilisierung und Maximierung. Aus diesen jeweils drei Phasen für jeden der drei Prozesse ergeben sich die neun Hauptkapitel des Buches, in die die beiden Autoren ihre jeweils eigenen Blickwinkel einbringen.


Bei Hastings ist das die des Firmengründers, bzw. CEOs. Er beschreibt zahlreiche Entwicklungen und Ereignisse aus seiner Firma (und anderen Stationen seines Lebens), führt aus wofür sie beispielhaft stehen, was er daraus gelernt hat und welche Massnahmen er daraus abgeleitet hat. Seine Sicht ist damit subjektiv und authentisch, z.T. mit tiefen Einblicken in sein Leben (so erfährt man zum Beispiel, dass er und seine Frau eine Eheberatung hatten, weil sein Beruf zeitweise zu wenig Platz für sein Privatleben liess).


Ergänzend dazu liefert Erin Meyer (Wissenschaftlerin und Autorin des Buches The Culture Map) die Perspektive des externen Experten. Sie referenziert verschiedene Studien und Forschungsergebnisse, hat aber auch für das Buch selbst Forschungsarbeit geleistet und 200 Interviews mit Netflix-Angestellten aller Hierarchiestufen geführt. Auch ihre Anteile am Buch haben viele anekdotische Passagen, insgesamt wirken sie aber stärker erklärend und einordnend als die von Hastings.


Die Stärke des Buches ergibt sich daraus, dass die beiden Sichtweisen zwar erkennbar sind, gleichzeitig aber fliessend ineinander übergehen, so dass an keiner Stelle das Gefühl stilistischer oder inhaltlicher Sprünge oder Brüche aufkommt. Als Ergebnis liest es sich flüssig und eingängig, man hat nicht das Gefühl, dass es sich um sozialwissenschaftliche oder betriebwirtschaftliche Literatur handelt (selbst wenn es das in gewisser Weise ist).


Aus ausser-amerikanischer Sicht von besonderem Interesse ist darüber hinaus das zehnte Kapitel, in dem die Varianten der Netflix-Unternehmenskultur in anderen Landesgesellschaften beschrieben werden. Eine schöne Fallstudie wie man Inpect & Adapt betreiben und trotzdem an zentralen Prinzipien festhalten kann.


1Die Firma, nicht das Video-Portal

Freitag, 18. Dezember 2020

Red Queen-Hypothese

FS
Bild: Wikimedia Commons / Marcjanna999 - CC BY-SA 4.0

Immer wieder kommt es vor, dass bei Menschen und Organisationen die Veränderungsmüdigkeit so gross wird, dass das vorübergehende Aussetzen aller Change-Vorhaben zu einer verlockenden Option wird. Der Grundgedanke: man kann doch zwischendurch für wenige Jahre alles so lassen wie es ist. Dadurch wird zwar nichts besser aber auch nichts schlechter, und danach kann die nächste Veränderungsmassnahme ausgeruht angegangen werden. Wäre das nicht ein gangbarer Weg?


Zumidest in komplexen Umfeldern kann die Antwort darauf nur "Leider nein" lauten. Natürlich kann man alle Veränderungsbemühungen zeitweise aussetzen, aber die Annahme, dass sich dadurch nichts verschlechtern würde ist eine Illusion. Die technischen, sozialen und wirtschaftlichen Veränderungen werden weitergehen, egal ob einzelne Personen und Organisationen sich daran beteiligen wollen oder nicht. Und wer eine Auszeit nehmen will wird zwangsläufig in einen Rückstand geraten.


Eine Benennung für dieses Phänomen besteht bereits in einem anderen Fachgebiet, der Evolutionsbiologie. Entwickelt vom amerikanischen Biologen Leigh Van Valen besagt sie, dass Tierarten die sich nicht durch permanente Evolution weiterentwickeln mit grosser Wahrscheinlichkeit irgendwann aussterben, da ihre Umgebung durch deren ständige Veränderung irgendwann lebensfeindlich für sie werden wird.


Van Valen wählte für seine These den Namen Red Queen-Hypothese, angelehnt an die gleich beannte Figur aus Lewis Carrolls Alice Through the Looking-Glass, in deren Wettrennen nicht Fortbewegung das Ziel war sondern das Verbleiben am selben Platz. Genau wie Saul Rosenzweig in einem ähnlichen Fall ging er vermutlich davon aus, dass die Bekanntheit der Alice-Bücher dazu beitragen würde, dass die Leser seiner Veröffentlichungen seine Idee so besser im Gedächtnis behalten würden.


“Now, here, you see, it takes all the running you can do, to keep in the same place.“

Alice Through the Looking-Glass,The Red Queen during the Red Queen's race


Selbst wenn mittlerweile andere literarische Werke bekannter sind als die von Carroll könnte es trotzdem eine gute Idee sein an der Bekanntheit der Red Queen-Hypothese zu arbeiten. Sie macht einen komplexen Sachverhalt mit einer einfachen Analogie erklärbar und schlägt ausserdem den Bogen zwischen verschiedenen Wissensgebieten, wordurch erkennbar wird, dass es sich um ein übergreifendes Muster handelt. Und letztendlich sollte jedes Mittel willkommen sein mit dem man erklären kann, dass "für wenige Jahre alles so lassen wie es ist" keine sinnvolle Option ist.

Dienstag, 15. Dezember 2020

Minimum Viable Products (MVPs)

FS
Grafik: Wikimedia Commons / Teemu Leinonen - CC BY-SA 4.0

Es ist einer der grossen Klassiker: verschiedene Menschen unterhalten sich über einen Begriff, jeder geht davon aus, dass alle das Selbe darunter verstehen aber in Wirklichkeit hat jeder sein eigenes Verständnis, so dass alle aneinander vorbeireden. Das habe ich schon an verschiedenen Beispielen aufgezeigt, und heute kommt ein weiteres dazu: das Minimum Viable Product (MVP). Auch hinter dem können sich sehr unterschiedliche Ansätze verbergen, und zwar die Folgenden:


I. Der Proof of Concept (PoC)

Rein formal kein MVP im eigentlichen Sinn, da hier noch kein benutzbares (→ viable) Ergebnis entsteht. Der in den 60er Jahren bei der NASA geprägte Begriff lässt sich als "Machbarkeitstest" ins Deutsche übersetzen. Ein erfolgreicher PoC beweist "nur", dass ein Vorhaben technisch machbar ist, validiert aber nicht ob es für das geplante Produkt auch einen Bedarf gibt. Ein Proof of Concept kann rudimentärster Art sein, z.B. indem er beweist, dass ein Material einer bestimmten Belastung standhält oder dass eine Datenauswertung gegen kein Persönlichkeitsrecht verstösst.


II. Der Riskiest Assumption Test (RAT)

Der erste Ansatz der auf Eric Ries zurückgeht, der Ende der 2000er Jahren mit seinem Lean Startup-Framework den Begriff des MVP bekannt gemacht hat. Er geht davon aus, dass vor dem ersten eigentlichen MVP grundlegende Annahmen geklärt werden können, z.B. die ob sich überhaupt jemand für die (Produkt)Idee interessiert. Das kann z.B. durch Fokusgruppen-Marktforschung geschehen oder durch Experten-Interviews. Ries bezeichnete diese Grundannahmen als "Leap-of-Faith-Assumptions", durch Rik Higham wurden sie später als "Riskiest Assumptions" popularisiert, die durch Riskiest Assumption Tests validiert werden können.


III. Das Low Fidelity MVP (Low-Fi MVP)

Das erste MVP im eigentlichen Sinn. Eric Ries versteht darunter eine extrem rudimentäre Version eines Produkts, deren einziger Zweck das Validieren von Kunden- oder Nutzer-Interesse ist. Legendär ist das Low-Fi MVP des online-Schuhhändler Zappos, das nur aus einer Website mit Schuh-Fotos und einer Bestelladresse bestand. Auf der Website Robot Mascot gibt es eine schöne Übersicht über weitere Varianten, die dort auch erklärt werden: Customer Interview, Social Media-Auftritt, Aktivität in Online-Foren, Landing Page, Split-Testing, Erklärvideo, Papier-Prototyp, Ad Campaign, "Fake Door", Audience Building und Micro-Survey.


IV. Das High Fidelity MVP (High-Fi MVP)

Ebenfalls eingeführt durch Eric Ries sind die High Fi-MVPs zwar noch immer rudimentär, in der Erstellung aber bereits deutlich anspruchsvoller. Z.B. für Prototypen in der Hardware-Fertigung gedacht wird das Produkt hier digital simuliert oder mit relativ hohem Fertigungsaufwand in geringer Stückzahl erstellt, etwa für öffentliche Vorführungen auf Messen. Aufwändige MVPs für komplexe rein digitale Produkte existieren aber ebenfalls. Auch hier gibt Robot Mascot eine Übersicht und Erklärung für verschiedene Varianten: Digitale Prototypen, 3D-Modelle, “Wizard of Oz” MVPs, “Concierge”-MVPs, The “Piecemeal”-MVPs, Crowdfunding und Single Featured MVPs.


V. Das Minimum Marketable Product (MMP), bzw. Earliest Loveable Product (ELP)

Eine wesentlich fortgeschrittenere (und ironischerweise auch wesentlich ältere) Variante des MVP. Eingeführt 2001 durch Frank Robinson, den Erfinder des Begriffs Minimum Viable Product, beschreibt sie einen Produktumfang der zwar noch klein ist, trotzdem aber bereits gut genug entwickelt ist um an den Markt gebracht werden zu können. Beispiele dafür wären die ersten, noch sehr minimalistischen Versionen von Facebook (ein Studenten-Verzeichnis) und Twitter (eine Chatgruppe). Robinson benutzte seinerzeit noch den MVP-Begriff in diesem Sinn, nachdem der durch Eric Ries umgedeutet wurde gab es Versuche von Neubenennungen 2011 durch Roman Pichler (MMP) und 2015 durch Henrik Kniberg (ELP).


VI. Der Meilenstein-MVP

Gehört am wenigsten in diese Aufzählung, tritt in der Realität aber immer wieder als Missverständnis auf. Wie der Name schon sagt - es ist nicht anderes als der alte Meilenstein, also eine mehr oder weniger sinnvoll geschnittene Kombination aus Arbeitspaket und Deadline, die jetzt nur einen neuen Namen trägt. Ein starker Indikator für Cargo Cult.

Donnerstag, 10. Dezember 2020

Das Problem mit SAFe (II)

FS
Bild: Pixabay / Geralt - CC0 1.0

Es ist nicht so, dass der Einsatz von SAFe grundsätzlich Proble nach sich ziehen würde, sinnvoll eingesetzt kann dieses Framework in vielen Organisationen zu Verbesserungen im Vergleich zum Ist-Zustand führen. Es ist aber leider so, dass bestimmte Probleme doch immer wieder auftreten. Eines davon kann besonders schwerwiegende Folgen haben, und  um das soll es heute gehen: auf viele traditionell sozialisierte Manager wirkt die grosse Prozess- und Rollenübersicht auf (je nach Blickwinkel) verlockende oder fatale Weise bekannt.


Unabhängig davon was die eigentliche Intention des Frameworks ist, in den verschiedenen organisatorischen Ebenen lassen sich die alten Hierarchien wiedererkennen. Ganz unten die (SAFe-)Scrum-Teams mit ihren (SAFe-)Scrum Mastern und (SAFe-)Product Ownern1, ganz oben die Epic Owner und Solution Manager, dazwischen ein Mittelbau aus Release Train Engineers, Business Ownern, System Engineers und Product Managern - das alles weist grosse Ähnlichkeiten zu dem klassischen unteren, oberen und mittleren Management auf.


Alleine dieses Gleichsetzungs-Potential wäre schon problematisch genug, es wird aber noch um eine weitere Dimension erweitert: auf jeder der mittleren und oberen Ebenen ist zwischen den Rollen ein horizontaler Aufgabenschnitt erkennbar. Business Owner, Product Manager, Release Train Engineers und System Engineers können als Entsprechung bekannter tayloristischer Aufteilungen in Anforderungsmanagement, Projektmanagement, Prozessmanagement und technisches Management gesehen werden. Die Gefahr besteht, dass hier wieder die Verteter der alten Silos zusammensitzen und ihre jeweiligen Partikularinteressen vertreten.


Auch auf der Zeitebene kann ein (scheinbarer) Wiedererkennungseffekt eintreten. Programm-Incremente die über Monate hinweg erstellt werden haben ähnliche Zeithorizonte wie die alten Release- oder Quartalspläne, Feature- und Enabler-Epics können so verstanden werden, dass Komponententeams getrennt von einander auf eine späte Integration hinarbeiten und den ganz rechts abgebildete "Release on Demand" kann man auch so verstehen, dass es einen Big Bang-Release ganz zum Schluss gibt, da es ja vorher keinen Bedarf nach halbfertigen Lösungen gibt.


Die Problematik dieser und ähnlicher Gleichsetzungen ist offensichtlich - Wenn sie zu der Ansicht führen, dass man nur die bestehenden Strukturen umbenennen muss um sich erfolgreich in Richtung Agil zu transformieren steht am Ende eine Mischung aus Missverständnis und Etikettenschwindel, aber ganz sicher kein Erfolg. Und um es noch einmal zu betonen: ein derartiges Ergebnis ist sicher nicht im Sinn von SAFe, es ist aber eines das dadurch sehr wahrscheinlich wird, dass traditionell sozialisierte Manager in der grossen Prozess- und Rollenübersicht vieles erkennen werden was ihnen fatale Weise bekannt vorkommt.



1Ganz bewusst mit diesem Präfix, um zu zeigen, dass das nicht die gleich benannten Rollen/Verantwortlichkeiten aus Scrum sind

Montag, 7. Dezember 2020

Principles that work with any methodology

FS

Die Unterlagen die eine Kollegin letzten Monat von einer Schulung zurückbrachte waren im Grossen und Ganzen brauchbar und nachvollziehbar, eine stach aber negativ heraus. Auf ihr wurden verschiedene methodische Ansätze (Design Thinking, Agile Frameworks und Lean/Kanban) verschiedenen organisatorischen Silos zugeordnet. Meine Reaktion war einerseits einer spontaner, ausführlicher Rant, gleichzeitig aber auch ein Erinnerungsfunken - irgendwo hatte ich ein Video gesehen, dass ein derartiges Vorgehen ebenfalls als Unsinn einordnete, danach aber aufzeigte wie es besser geht. Nach kurzer Suche habe ich es gefunden hier ist es.



Und nicht nur der Inhalt ist gut, auch die unterstützende Visualisierung. Jeff Gothelf (aus dessen Vortrag das Video besteht) teilt meine Vorliebe für popkulturelle Referenzen und minimalistische, gleichzeitig aber auch verspielte Slides, die das Gehörte mit Bildern untermalen und dadurch besser erinnerbar machen. Einer der Talks die man sich nicht nur anhören sondern auch ansehen sollte.

Donnerstag, 3. Dezember 2020

Selbstorganisation (IV)

FS
Bild: Pixabay / Schoggimousse - CC0 1.0

Es gibt Begriffe die scheinbar selbsterklärend sind, bei denen eine Diskussion aber hervorbringen kann, dass verschiedene Menschen sehr unterschiedliche Verständnisse von ihnen haben. Selbstorganisation gehört zu diesen Begriffen, vor allem dann wenn dieses Wort im Umfeld der agilen Frameworks benutzt wird. Gerade wegen seiner häufigen Verwendung in diesem Kontext lohnt es aber näher hinzuschauen - was könnte gemeint sein wenn von Selbstorganisation (genauer gesagt von selbstorganisierten Teams) die Rede ist? Folgende Varianten sind möglich:


I. Selbstorganisiertes Abarbeiten vorgeplanter und vorgegebener Tätigkeiten

Die vermutlich häufigste Variante. Anders als bei angeleitetem Arbeiten kann das Team selbst entscheiden wer welche Aufgaben übernimmt, allerdings unter der Voraussetzung, dass alles durchgehend oder zu vorgegebenen Zeitpunkten stattfindet. Ein Beispiel dafür wäre das Personal eines Supermarktes, das jeden Tag selbst entscheidet wer die Kasse besetzt, wer die Regale einräumt und wer den Boden reinigt.


II. Selbstgeplantes Abarbeiten vorgegebener Tätigkeiten

Ähnlich wie Variante I, aber mit einem zentralen Unterschied: selbst für die Planung des Abarbeitens verantwortlich zu sein bedeutet, dass man zwar weiterhin an die Umsetzung der vorgegebenen Themen gebunden ist, dass aber selbst entschieden werden darf wann, bzw. in welcher Geschwindigkeit das stattfinden wird. Ein Beispiel dafür wäre ein Fertigungsteam das nach dem Pull-Prinzip arbeitet.


III. Selbstorganisiertes Planen und Arbeiten in Richtung eines vorgegebenen Ziels

Das hier ist bereits etwas was man in vielen (mehr oder weniger) nach Scrum oder ähnlichen Frameworks arbeitenden Teams findet. Vorgegeben wird nur noch das Sprint- oder Produktziel, wie dieses erreicht wird ist aber nicht vorgegeben, solange es im Rahmen der eigenen Arbeit und des eigenen Budgets geschieht. In gewisser Weise Management by Objectives für Teams.


IV. Selbstorganisiertes Planen und Arbeiten in Richtung eines selbstgegebenen Ziels

In den meisten Organisationen die weitgehendste Form der Selbstorganisation die einem Team gewährt werden kann. Nicht nur über Art und Zeitplan der Arbeit kann selbst entschieden werden sondern auch über das Ziel das damit erreicht werden soll. Ein Beispiel dafür wäre ein Innovation Lab in dem Product Innovation und Product Discovery stattfinden.


V. Selbstorganisierter Zusammenschluss mit selbstgegebenem Ziel und selbstorganisiertem Planen und Arbeiten

Die Extremform. In dieser Variante schliessen sich Menschen aus freien Stücken zusammen um selbstbestimmt an einem selbstgewählten Ziel zu arbeiten. Beispiele hierfür wären ein buddhistisches Kloster oder ein Kibbuz, innerhalb grösserer Organisationen ist dieser Typ praktisch nicht existent.

Powered by Blogger.