Kommentierte Links (LXX)

Grafik: Pixabay / The Digital Artist - 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" 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.
  

Kommentierte Links (LXIX)

Bild: Unsplash / Dayne Topkin - Lizenz

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.

I can see a better time

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.

The agile Bookshelf: No Rules Rules

Bild: Unsplash / Thibault Penin - Lizenz

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 Netflix¹ 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.

¹Die Firma, nicht das Video-Portal

Red Queen-Hypothese

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.

Minimum Viable Products (MVPs)

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.

Das Problem mit SAFe (II)

Bild: Pixabay / Geralt - Lizenz

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 Ownern¹, 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.

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

Principles that work with any methodology

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.

Selbstorganisation (V)

Bild: Pixabay / Schoggimousse - Lizenz

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.

Kommentierte Links (LXVIII)

Bild: Unsplash / Dayne Topkin - Lizenz

[Edit: Der erste verlinkte Artikel war ursprünglich ein anderer, der aber mittlerweile gelöscht wurde]

• Anthony Mersino: Stop Snowplowing in Agile

  Am Anfang von Beratungs- und Projekteinsätzen gibt es immer wieder Momente in denen sich Probleme kondensiert zu erkennen geben. Anthony Mersino hat einen solchen erlebt als er bei einem Kunden erfuhr, dass die Sprintumfänge dort nach dem "Schneepflugsystem" festgelegt werden, was sich vielleicht als "Bugwellensystem" ins Deutsche übersetzen lässt. Dabei wird die nicht geschaffte Arbeit der Vergangenheit einfach zu den nächsten Sprints dazuaddiert, wodurch der "Schneehaufen" den die Teams vor sich herschieben immer grösser wird, bis sie darin stecken bleiben. Im Artikel werden das Phänomen und seine negativen Auswirkungen noch mit mehr Details beschrieben, alleine die Metapher ist aber gut genug um sie sich zur zukünftigen Verwendung zu merken.
  

• Maarten Dalmijn: A pretty burn down chart usually means ugly Scrum

  Ein Artikel bei dem die Überschrift eigentlich schon alles aussagt, zumindest für den der sich mit dem Thema beschäftigt hat. Der häufigste  Grund dafür, dass Burn Down-Charts sich entlang der Ideallinie bewegen ist, dass alles wie geplant abgearbeitet wird. Der Grund dafür, dass nach Scrum gearbeitet wird ist aber, dass sich in einem komplexen Umfeld nicht alles wie geplant umsetzen lässt. Dass sich das beisst ist offensichtlich, und doch gibt es immer wieder Teams die auf ihre schönen Burndowns stolz sind. Maarten Dalmijn nennt vier wahrscheinliche Gründe dafür: Methodismus, kein Streben nach neuen Erkenntnissen, fehlende Lernbereitschaft, Risikoaversität. Nichts worauf man stolz sein sollte.
  

• Avi Siegel: How to Choose a Product Prioritization Framework
  

  Ein hilfreicher Text für Product Owner oder Teams die sich mit dem Priorisieren schwertun. Avi Siegel erklärt in ihm zuerst einige der verbreitetsten Priorisierungsmethoden: Aufwand/Ertrag-Matrix, RICE Score (Reach, Impact, Confidence, Effort), ICE Score (Impact, Confidence, Ease), Weigted Scoring (relative Gewichtung), Kano-Modell (Notwendigkeits/Begeisterungs-Matrix) und MoSCoW-Methode (Must have/Should have/Could have/Won’t have). Als nächstes versucht er alle genannten Ansätze in dem Zusammenzubringen was er sein "Meta-Framework" nennt. In der Anwendung stelle ich mir dieses Meta-Framework kompliziert vor, es sich anzuschauen hilft aber auf jeden Fall dabei die verschiedenen Dimensionen von Priorisierung besser zu verstehen.
  

• Lisa Crispin: Shifting left & right in our continuous world

  Wie Lisa Crispin es hier selbst sagt: die Begriffe "Shift Left" und "Shift Right" sind zu unklar definiert und werden daher zu oft falsch verstanden. In ihrer Definition beziehen beide sich darauf, dass die Qualitätssicherung aus ihrem Organisations- und Prozessphasen-Silo ausbricht und sich gemeinsam mit den (im klassischen Aufbau) vor- und nachgelagerten Einheiten zu crossfunktionalen Teams vereinigt. Vorgelagert sind dabei Design und Entwicklung, nachgelagert Release und Betrieb. Interessant ist dabei ihre Art das im DevOps/ContinuousX-Loop zu visualisieren. Etwas das man für Workshops mitnehmen kann.
  

• Erich Bühler: Dealing with Psychopaths and Narcissists during Agile Change

  Zu den Missverständnissen denen Gegner (und Befürworter) der agilen Frameworks regelmässig erliegen gehört, dass Veränderungen in Richtung Agilität zumindest auf den unteren Hierarchieebenen immer mit Offenheit (wenn nicht sogar Begeisterung) aufgenommen werden, da den Teams schliesslich mehr Freiheiten und weniger unbegründete Anweisungen gegeben werden. Die Realität ist leider häufig eine andere, immer wieder gibt es die sprichwörtlichen toxischen Personen an denen sich alles aufreibt. Erich Bühler nimmt sich dankenswerterweise dieses oft verschämt verschwiegenen Themas an.
  

Produktziel und Produktvision

Bild: Pixabay / Larisa K. - Lizenz

Seit November 2020 muss die agile Community mit einer Begriffsverwirrung leben. Das in diesem Monat veröffentlichte Update des Scrum Guide führte einen neuen, bis dahin kaum bekannten Begriff ein: das Produktziel (Product Goal). Verwirrend ist das deshalb, weil es (ausserhalb von Scrum) einen sehr ähnlichen und bereits etablierten Begriff gibt, die Produktvision (Product Vision). Ist das jetzt das Gleiche? Gibt es Unterschiede? Wenn ja welche? Schauen wir uns die Begriffe an.

Die Ursprünge der Produktvision verlieren sich irgendwo im Dunkel der Geschichte, bereits in rückwirkend digitalisierten Fachartikeln findet man sie aber wieder, z.B. 1984 im Harvard Business Review als "Vision for the Product". Konkretisiert wurde sie später in verschiedenen Formen, unter anderem 1991 von Geoffrey Moore in Crossing the Chasm (als "Product Elevator Pitch") und 1995 von Michael McGrath in Product Strategy for High Technology Companies (als "Strategic Vision").

Die Gemeinsamkeit dieser Ansätze ist, dass sie die Produktvision im Sinn eines Leitsterns, Fernziels oder Idealtypus definieren, also als etwas was in der Realität kaum zu erreichen ist. Der damit verbundene Zweck ist, dass durch eine Ausrichtung an dieser Vision kontinuierlich in eine gleichbleibende Richtung gearbeitet werden kann, was sowohl durch Abarbeiten eines langfristigen Plans möglich ist (im Wasserfall-Vorgehen) als auch durch kurzfristiges Optimieren der jeweils nächsten Schritte in Richtung des Langfristziels (agiles Vorgehen).

Im Unterschied dazu kann das im Scrum Guide beschriebene Produktziel explizit erreicht werden. Der in diesem Zusammenhang entscheidende Absatz lautet "The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.", wodurch klar wird, dass eine Beendigung der Arbeit am Produktziel möglich ist. Eine Zwangsläufigkeit dass das in absehbarer Zeit geschieht ist das zwar nicht (theoretisch sind Produktziele möglich die erst in Jahrzehnten erreichbar sein werden) grundsätzliche Abschliessbarkeit sollte aber gegeben sein.

Der Differenzierung sollte damit klar sein: die Produktvision ist der führende, aber letztendlich unerreichbare Leitstern, das Produktziel der ferne aber (theoretisch) erreichbare Abschluss aller Arbeiten die für ein Produkt nötig sein werden.

Absehbar ist aber auch: So hilfreich diese begriffliche Unterscheidung für das Verständnis auch sein mag, in der Realität dürfte sie nur selten vorgenommen werden. Es werden wohl nur die methodenbegeisterten Teams sein die in ihrem Backlog eine Differenzierung zwischen Produktvision und Produktziel vornehmen, die meisten werden nur einen der Begriffe verwenden oder sie synonym gebrauchen - was angesichts der grossen Schnittmengen auch unproblematisch sein sollte. Wichtig ist nur, die Unterscheidung zu kennen, um bei Bedarf beides einsetzen (oder den Unterschied erklären) zu können.

Evil User Stories

Bild: Unsplash / Lukas Eggers - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind in der Regel aus der Sicht des Nutzers formuliert (so genannte User Stories), und die fertigen Ergebnisse werden zusammen mit ihm getestet und besprochen. Was bei all dem aber zu bedenken ist -  manchmal lassen Benutzer sich zu Aktionen hinreissen die sie besser unterlassen hätten, und von denen das System sie abhalten sollte. Lassen sich auch derartige "verhindernde Funktionen" als User Story formulieren?

Bevor wir darauf eingehen eine kurze Sinnfrage: wenn ein Nutzer eine bestimmte Aktion nunmal durchführen will, warum sollte man ihn davon abhalten? Weiss er nicht am besten was richtig für ihn ist? Die Antwort darauf: leider nicht immer, und ein wie es der Zufall will gibt es auch ein aktuelles Beispiel dafür. Um zu zeigen wie produktiv sie im Home Office war veröffentlichte eine niederländische Ministerin auf Twitter einen Screenshot von einer EU-Ministerrunde an der sie gerade teilnahm. Da dieser in seiner URL den Konferenzdienst und den Zugangscode anzeigte war es für jeden ihrer Twitter-Follower möglich ebenfalls an dem Meeting teilzunehmen. Und ein Journalist gönnte sich den Spass und machte genau das.

Dit was de oorspronkelijke foto die vanaf het account van minister Bijleveld werd gedeeld, met daarin de meeting-ID en vijf cijfers van de pincode.

Het was een zescijferige pincode. Ik joinde met de naam 'admin'. pic.twitter.com/Fztrbqm5FR

— Daniël Verlaan (@danielverlaan) November 20, 2020

Zurück zur Ausgangsfrage. Lassen sich User Story formulieren die zwar aus Nutzerperspektive geschrieben sind aber ein fahrlässiges Verhalten wie das der niederländischen Ministerin verhindern sollen? Natürlich geht das, es fühlt sich aber künstlich an. "Ich als Videokonferenz-Teilnehmer möchte daran gehindert werden Zugangsdaten zu veröffentlichen, damit kein Unbefugter teilnehmen kann" ist kein Satz oder Wunsch den ein echter Mensch jemals äussern würde.

Ein besserer Ansatz wäre es sich den Benutzer/User aus einer anderen Perspektive vorzustellen. In UX-Design und Software-Test gibt es den Typus des "Evil User", der sich dadurch auszeichnet, dass er Funktionen immer wieder so benutzt wie sie nicht gedacht sind und dadurch Fehlfunktionen und falsche Ergebnisse erzeugt. Wichtig ist dabei, dass er das (meistens) nicht aus bösem Willen tut sondern aus Unkenntnis und ohne zu wissen was er anrichtet - wie im Fall der oben genannten Ministerin.

Vom Evil User zur User Story ist es jetzt nur noch ein kurzer Sprung. "Ich als Videokonferenz-Teilnehmer möchte Screenshots mit allen sichtbaren Informationen veröffentlichen, damit jeder sehen kann was ich mache". Mit solchen Anforderungen in ein Refinement zu gehen kann wertvolle Diskussionen ermöglichen. Für den Fall dass jemand etwas Derartiges tut (verhindern kann man es nicht) welche Informationen sind dann öffentlich sichtbar? Welche davon sind sicherheitsrelevant? Und wie könnte man sie unkenntlich machen?

Aus derartigen Diskussionen können sich dann die Akzeptanzkriterien der Evil User Story ergeben, die in diesem Fall negativ formuliert sind, da sie ja das "bösartige" Nutzerverhalten eindämmen sollen. Angelehnt an den oben genannten Fall könnte etwa eines sein, dass weder auf der Website des Video-Calls noch in der URL Zugangsdaten sichtbar sein dürfen.

Als letztes noch ein Tip aus der Praxis: es macht Sinn die Evil User Stories im Backlog mit einer besonderen Kennzeichnung zu versehen. Wenn das nicht passiert besteht das Risiko, dass das Team vergessen hat, dass es sich bei einer älteren Story um eine zu verhindernde Aktion handelt und diese dann in der Weiterentwicklung nicht verhindert sondern erleichtert oder sogar erst ermöglicht. In solchen Fällen steckt eine feine Ironie: das Team ist dann der Evil User seines eigenen Prozesses.

Update des Scrum Guide 2020

Grafik: Wikimedia Commons / Huluvu424242 - CC BY-SA 4.0

Nach drei Jahren ist es wieder soweit, der Scrum Guide hat ein Update erhalten. Nachdem im Vorfeld lediglich bekannt war, dass die neue Version kürzer werden würde als die alte, gab es gespannte Neugier auf das was wegfallen würde und das was dazukommt. Das Warten hat ein Ende, schauen wir uns an wie es gekommen ist.

Die offensichtlichste Neuerung dürfte das Produktziel sein, dass jetzt Teil des Product Backlogs ist. Im weitesten Sinn vergleichbar mit der Produktvision beschreibt es das langfristige Ziel auf das das Scrum Team hinarbeitet und auf das sich das gesamte restliche Product Backlog ausrichten soll. Es wird auch klar herausgestellt, dass es nur ein einziges Produktziel geben soll, womit auch die Hauptmotivation seiner Einführung klar sein dürfte - zusammengewürfelte Sammelsurium-Backlogs sollen unmöglich gemacht werden.

Bei den Rollen gibt es keine wirklichen inhaltlichen Änderungen, allerdings wurden vor allem beim Scrum Master Formulierungen so geändert, dass bestimmte (Fehl-)Interpretationen nicht mehr möglich sind. Es ist jetzt noch deutlicher, dass er nicht nur für das Team zuständig ist sondern für die gesamte Organisation und deren Weiterentwicklung in Richtung Agilität. Zum ersten mal ist er nicht mehr dafür zuständig Impediments selbst zu beseitigen, er muss nur noch dafür sorgen, dass irgendjemand es tut. Und seine Rolle in der Retrospektive ist jetzt deutlich weniger dominant formuliert. Angepasst wurde auch ein Grenzwert: statt 11 soll ein Scrum Team nur noch bis zu 10 Mitglieder haben.

Bei den Meetings hat sich vor allem das Planning in seinem Ablauf verändert. Neben die Phasen in denen der Umfang und die Art der Umsetzung diskutiert werden (früher Planning I und Planning II) tritt eine vorgelagerte dritte (bzw. der neuen Reihenfolge nach erste) Phase in der die Sinnfrage nach dem Zweck des Sprints gestellt und mit dem Sprintziel beantwortet wird. Ebenfalls erwähnenswert: die seit 2017 ohnehin nicht mehr verpflichtenden drei Fragen sind jetzt endgültig aus der Beschreibung des Daily Scrum verschwunden.

Eher für den englischen Sprachraum von Bedeutung dürfte das Ersetzen des Begriffs Self-Organizing durch Self-Managing sein. Die Intention einer klareren Betonung der Selbstbestimmung ist klar, im Deutschen dürfte diese Differenzierung aber kaum einen Unterschied machen¹. Auch die Unterscheidung zwischen Role (aus dem Scrum Guide entfernt), Responsibility und Accountability dürfte in Deutschland nur von akademischem Interesse sein.

Zuletzt kommen noch verschiedene redaktionelle Änderungen dazu, zum Teil in Form von klareren Formulierungen, etwa bei den Artefakten Product Backlog, Sprint Backlog und Increment, von dem z.B. jetzt klarer ist, dass es (zum Teil) auch vor Sprintende geliefert werden kann, etwa im Rahmen von Continuous Delivery. Gleichzeitig wurden an einigen Stellen unnötig detaillierte Beschreibungen entfernt, der offensichtlichste Fall dafür dürfte der Sprint-Abbruch sein, der von einem Absatz auf eine Zeile zusammengeschrumpft ist.

Fazit: mit dem Produktziel gibt es eine grosse Änderung die Scrum noch einmal in die richtige Richtung schieben kann, alleine dafür hat sich das Update gelohnt. Der Rest ist gut aber nice to have. Mal sehen wie lange es bis zum nächsten Update dauert.

¹Nachtrag: nach einigen Diskussionen zu dem Thema - ja, der 2017er Scrum Guide sagte "Self-organizing teams choose how best to accomplish their work" während der 2020er Scrum Guide sagt "Scrum Teams are [...] self-managing, meaning they internally decide who does what, when, and how." Wie oben gesagt, die Intention einer klareren Betonung der Selbstbestimmung ist klar, einen Paradigmenwechsel erkennt man hier aber vor allem dann wenn man unbedingt einen erkennen will. Auch in der 2017er Version war die Erstellung der (Sprint-)Ziele schon etwas was das Scrum Team selbst gemacht hat.

Woran man erkennt, ob ein Unternehmen wirklich nutzerzentriert ist

Bild: Pexels / Fauxel - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind aus der Sicht des Nutzers formuliert (🡒 User Stories), die schnelle Fertigstellung und Auslieferung neuer Features soll diese möglichst schnell zu ihm bringen, die Durchführung von Sprint Reviews. A/B-Tests, etc. soll sein Feedback möglichst schnell einsammeln. Was bei all dem aber zu bedenken ist - Anforderungstypen, Lieferzyklen und Meetingtypen sind nur Formalien, für das wirkliche Vorhandensein von Nutzerzentrierung können sie lediglich als Indikator dienen. Um festzustellen, ob die wirklich gegebem ist, gibt es aber einen anderen, bemerkenswert einfachen Weg: man muss sich nur ansehen, mit welcher Software eine Firma ihre eigenen Mitarbeiter arbeiten lässt.

Um zu verstehen warum das so ist, ein bisschen Kontext: es gibt heute keine Firma mehr, in der ohne Software gearbeitet werden kann. Oft findet die Arbeit direkt am Computer statt (z.B. in Banken und Verlagen), selbst wenn das nicht der Fall ist, finden aber begleitende Prozesse digital statt, von der Arbeitszeiterfassung über die Buchung von Dienstreisen und Fortbildungen bis hin zur Suche von Informationen im Intranet. Dafür ist zum Teil intern entwickelte Software im Einsatz, zum Teil auch solche, die eingekauft wurde.

Noch ein bisschen mehr Kontext: Nutzerzentrierung ist eine Haltung, die sämtliche Prozesse immer von eben dem Nutzer aus denkt. Er und seine Bedürfnisse stehen im Mittelpunkt, und zwar auch dann, wenn derjenige, der die Anwendung für ihn entwickelt, ein Monopolist ist, der Aussehen und Verhalten neuer Funktionen aufzwingen kann. Das heisst natürlich nicht, dass es nicht immer wieder Gründe geben kann, sich im Anwendungsdesign gegen die Wünsche des Nutzers zu entscheiden - nur sollte man dann so ehrlich sein und nicht mehr von Nutzerzentrierung sprechen.

In vielen Organisationen, die sich nach aussen nutzerzentriert geben, ist aber genau das der Normalfall. Da sich die eigenen Mitarbeiter nicht zur Wehr setzen können, indem sie zu anderen Produkten wechseln, wird ihnen zugemutet mit Software zu arbeiten, für die sich bei freier Auswahl niemand entscheiden würde. Umständlich und unintuitiv in der Bedienung, mit langsamen Lade- und Verarbeitungszeiten und hoffnungslos veraltetem Look & Feel ist sie in solchen Fällen ein laut und häufig verfluchtes Hassobjekt, das handfeste negative Folgen mit sich bringt. Zunächst sinkende Effizienz und Effektivität, aber auch sinkende Wertschätzung und Loyalität der Angestellten zum eigenen Unternehmen.

Umgekehrt kann moderne, einfach bedienbare, die Arbeit erleichternde und auf Basis von Feedback weiterentwickelte Software wesentlich dazu beitragen, dass das Verhältnis zwischen einem Unternehmen und seinen Angestellten ein gutes ist. Zum Einen weil die Mitarbeiter das Gefühl haben, dass ihnen für ihre Arbeit die richtigen Werkzeuge gegeben werden (und dass auch in diese investiert wird), zum Anderen weil sie sehen, dass ihre Rückmeldungen ernst- und angenommen werden.

Zuletzt kommt noch ein weiterer, nicht zu unterschätzender Aspekt dazu, der uns wieder zum Anfang dieses Artikels zurückbringt: die Mitarbeiter sehen, wie ernst ihre Firma die öffentlich propagierte Nutzerzentrierung wirklich meint. Wenn sie das Gefühl haben, dass diese auch tatsächlich im Unternehmen gelebt wird, ist die Wahrscheinlichkeit gross, dass sie sich auch selbst entsprechend verhalten. Wenn sie umgekehrt den Eindruck bekommen, dass Nutzerzentrierung nur ein Selbstdarstellungs-Buzzword ist, wird auch das sich im eigenen Verhalten niederschlagen.

Am Ende ist es ein von vielen Unternehmen verkannter Zusammenhang - wer glaubt Nutzerzentrierung nur nach aussen leben, nach innen aber unterlassen zu können, riskiert, dass er sie in beiden Dimensionen verliert.

Visualized Continuous Delivery

Schon ein paar Jahre alt, aber noch immer bemerkenswert. In diesen kleinen Kunstwerken stecken genug Details und Informationen um sich erstaunlich lange darin zu vertiefen. Man kann der Urheberin nur dankbar sein, dass sie es der Allgemeinheit zur Verfügung gestellt hat.

Grafiken: Nhan Ngo - CC BY SA 3.0

Before Chaos, during Chaos, after Chaos

Eigentlich bin ich kein Fan davon in einem Arbeitskontext den Begriff  "Chaos" zu verwenden, da er in meinem Verständnis einen Zustand beschreibt in dem Arbeiten eigentlich nicht mehr möglich ist. "Chaos Engineering" hat sich allerdings mittlerweile als Name für ein bestimmtes Vorgehen durchgesetzt, auf das sich ein näherer Blick lohnt. Gut, dass Nora Jones, eine der Verfasserinnen des gleich benannten Buchs, regelmässig Vorträge zu diesem Thema hält.

Sehenswert ist dieser Vortrag aber nicht nur weil Jones erklärt was Chaos Engineering ist, er ist auch deshalb wichtig weil sie in ihm unterstreicht, dass der ganze Ansatz nur wenig bringt wenn er nur von wenigen Experten und Enthusiasten angewandt wird. Erst wenn sich die gesamte Produktentwicklung an den "Chaos-Experimenten" beteiligt entfaltet sich die ganze Wirkung.

Crossfunktionale Teams (III)

Bild: Pexels / Tom Fisk - Lizenz

Wenn man sich in Firmen umhört die sich dem agilen Arbeiten verschrieben haben dann gehört das Bekenntnis zu den crossfunktionalen Teams mittlerweile zum Standard. Es ist weitgehend anerkannt, dass nur eine Einheit die alle zur Produktherstellung nötigen Skills enthält schnell auf Änderungen reagieren kann ohne auf Zulieferungen warten zu müssen, und dass solche Einheiten auch wesentlich besser darin sind die dabei entstehenden Aufwände zu schätzen kommt noch dazu. Es ist also alles gut. Oder?

Zugegeben, die Frage war rhetorisch. Tatsächlich ist in den meisten Fällen noch nicht alles gut, ein näherer Blick zeigt warum. In agilen Teams wird die Crossfunktionalität (ohne bösen Willen, bzw. durch fehlendes Verständnis) meistens auf Entwickler-Spezialisierungen reduziert.¹ Ein so verstandenes Team besteht dann etwa aus zwei Frontend-Entwickler, zwei Backend-Entwicklern und zwei Testern. Crossfunktional? Ja, aber nur innerhalb eines Silos. Das reicht nicht.

Was in solchen Konstellationen zur Crossfunktionalität im eigentlichen Sinn fehlt ist die Einbeziehung derjenigen Organisationsbereiche die man als "Upstream" und "Downstream" bezeichnet. Gemeint sind damit die Menschen (oder Kompetenzen) mit denen auch die der Entwicklung vor- und nachgelagerten Tätigkeiten entlang der Bearbeitungskette durchgeführt werden können.

Upstream (stromaufwärts) befindet sich zum Beispiel das Anforderungsmanagement, also vereinfacht gesagt die Menschengruppe die den Kontakt zu Auftraggebern und Nutzern hat. Da dieser Kontakt nötig ist um regelmässiges Anwender-Feedback zu erhalten gehört diese Kompetenz genauso in die Teams wie der nächste Schritt, die Konzeption, in dem Business Analysten, Architekten, UX-Designer und ähnlichr Rollen bereits für die Entwicklung wichtige Entscheidungen treffen.

Anders strukturiert aber genauso wichtig ist der Bereich Downstream (stromabwärts). In ihm befinden sich Kompetenzen wie Integrationsmanagement, Testmanagement, Releasemanagement und Rolloutmanagement, ohne die neue Features nicht auf Produktions- oder Abnahmeumgebungen gelangen können. Da aber erst dort der Anwenderkontakt stattfindet (der die zwingende Voraussetzung für das folgende Feedback ist) gehört auch das ins Team.

Wichtig zum richtigen Verständnis ist dabei: es sind die Kompetenzen die in die Teams gehören und nicht notwendigerweise die Rollen. Architektur, UX-Design und Testmanagement können in den meisten Fällen auch vom Entwicklungsteam verantwortet werden (was übrigens Architekten, UX-Designer und Testmanager nicht überflüssig macht sondern deren Rolle in Richtung Coaching und Servant Leadership verändert).

Und um auf eine an dieser Stelle häufig geäusserte Sorge einzugehen: ja, auch aus Governance- und Compliance-Sicht ist ein derartig crossfunktionales Team in der Regel zulässig und arbeitsfähig. Man muss sich nur darauf einlassen wollen.

¹Wobei derartige Teams bei genauerer Betrachtung meistens nicht wirklich agil agieren

Das Problem mit SAFe (I)

Bild: Piqsels - Lizenz

Kommentierte Links (LXVII)

Bild: Unsplash / Dayne Topkin - Lizenz

• Jez Humble: OK, apparently this still needs saying

  Es gibt ja für alles ein erstes Mal, so auch hier: erstmalig verlinke ich in den kommentierten Links nicht zu einem Artikel sondern zu einem Twitter-Thread. Was Jez Humble hier schon leicht genervt ankündigt ist eine in acht Teilen ausgeführte Widerlegung des verbreiteten Vorurteils, dass DevOps und agile Produktentwicklung nicht mit staatlichen Regulierungen wie PCI DSS, FISMA und SOX vereinbar wären. Twitter-typisch sind die im Text selbst enthaltenen Informationen eher komprimiert, der wahre Mehrwert ergibt sich aus verschiedenen weiterführenden Fallstudien und Artikeln die im Thread verlinkt sind. Ein eher trockenes Thema aber ein wichtiges für jeden der im Geltungsbereich dieser und ähnlicher Vorschriften agil arbeiten will.
  

• Barry O'Reilly: Systemic Effects - the Overlooked Key to Effective Strategic Planning

  Ein weiterer Beweis dafür, dass einem die neu zu lernenden Themen nie ausgehen werden. Seit 1971 gibt es die Futures Wheel-Methode, mit der man direkte und indirekte Konsequenzen von Entscheidungs- und Umgebungsfaktoren visualisieren kann - und erst jetzt erfahre ich davon, durch diesen Artikel von Barry O'Reilly. Letzten Endes ein mit der Mind Map verwandtes Konzept, mit dem grossen Unterschied, dass die Themen sich nach aussen nicht nur weiter ausdetaillieren sondern sich dort auch gegenseitig beeinflussen und voneinander abhängen können. Vom ersten Eindruck her würde ich sagen, dass verschiedene Einsatzgebiete möglich sind, z.B. neben der von O'Reilly genannten nichtlinearen strategischen Planung auch Ist-Analysen. Spannend.
  

• András Juhász: Technical Debt Is Overhyped. Let’s Talk about Product Debt
  

  Mir fällt gerade auf, dass ich eigentlich schon seit Jahren etwas zum Thema technische Schulden schreiben will aber nie dazu gekommen bin. [Edit: mittlerweile doch] Dann eben zuerst zu den "Produkt-Schulden". Laut András Juhász sind das voreilig eingebaute (oder nach Erkennung nicht entfernte) Features die nicht (mehr) zur Produktvision passen - was nochmal unterstreicht, dass man natürlich eine haben sollte. Eine ähnliche Definition kommt von Luke Gallimore: auch für ihn entstehen Produkt-Schulden durch die fehlende Ausrichtung auf ein übergeordnetes Ziel (statt Produktvision spricht er von Produktstrategie), er fügt aber noch eine weitere Dimension hinzu - auch die fehlende Validierung von Annahmen über die Akzeptanz und Nutzung neuer Features führt für ihn zu Produkt-Schulden. Beides sehr bedenkenswerte Überlegungen.
  

• Ron Jeffries: Working Software

  Das hier ist sehr Oldschool. Ron Jeffries, einer der Verfasser des Manifests für agile Softwareentwicklung, geht auf einen von dessen zentralen Sätzen ein: "Working software is the primary measure of progress." Nach einem kurzen Exkurs zur Frage was eigentlich "working Software" ist (Antwort: es kommt darauf an) liefert er eine sehr schön differenzierte Antwort warum sie das Hauptkriterium für Fortschrittsmessungen sein sollte, und zwar sowohl für einzelne Entwickler, als auch für Entwicklungsteams, als auch für Manager. Ein Artikel den man ausdrucken und in vielen Entwicklungsabteilungen dieser Welt an die Wand hängen sollte.
  

• Ken Schwaber: SCRUM Development Process

  Apropos Oldschool. Vor fast genau 25 Jahren (also sogar deutlich vor dem Manifest für agile Softwareentwicklung) stellten Jeff Sutherland und Ken Schwaber auf der OOPSLA-Konferenz ihre Version von Scrum vor, und obwohl es damals bereits noch ältere gab hat sich ihre durchgesetzt und nach langer Evolution zu dem entwickelt was wir heute unter diesem Namen kennen. Das bedeutet, dass heute Software-Entwicker nach Scrum arbeiten die noch nicht geboren gewesen sind als dieses Paper veröffentlicht wurde. Um so bemerkenswerter, dass dieses Framework in manchen Firmen noch immer als neumodisch gilt.
  

Die Testautomatisierungs-Falle (und wie man ihr entkommt)

Bild: Flickr / Karen Rustad Tölva - CC BY 2.0

In den Diskussionen um Psychologische Sicherheit, Kultur, "Agile Mindset" und Change Management geht es manchmal unter, aber zumindest im IT-Kontext hat Agilität auch immer eine sehr technische Seite, ohne die schnelle Reaktions- und Lieferfähigkeit weder denkbar noch umsetzbar ist. Einer der wichtigsten Aspekte ist dabei die Automatisierung der Software-Tests, also der Qualitätssicherung der neu erstellten Funktionalitäten. Und wie so oft gilt auch hier - es reicht nicht es zu machen, man muss es auch richtig machen.

Zur Erinnerung: während die Abnahme-Tests im Sprint noch irgendwie mit manueller Arbeit zu stemmen sein können ist das bei den Regressionstests nicht mehr der Fall. Unter denen versteht man das regelmässige Überprüfen aller (!) älteren Funktionen, womit sichergestellt wird, dass diese nicht versehentlich durch neuere Entwicklungen beschädigt wurden. Bei grösseren IT-Systemen kann das eine fünfstellige Anzahl an Tests erfordern, was bei manuellem Durchklicken Wochen und Monate dauern kann.

Die einzige Lösung wenn man schnell sein will ist das Automatisieren möglichst aller Regressionstests. Erst wenn diese von einem Computerprogramm ausführbar sind können die erforderlichen Mengen und Geschwindigkeiten erreicht werden die nötig sind um Fehler schnell entdecken und beheben zu können. Ohne Testautomatisierung kommen bei grösseren Systemen die Jahres- und Quartals-Releases zurück. Aber (Ironie der Geschichte): auch eine falsch durchgeführte Testautomatisierung kann den selben Effekt haben.

Um aussagekräftig zu sein müssen die automatisierten Testsuiten immer dem aktuellen Stand der jeweiligen Anwendungsentwicklung entsprechen, sonst geben sie Fehlermeldungen aus sobald ein Feature verändert wurde, die Aktualisierung der Tests aber noch nicht stattgefunden hat. Das Risiko ist schnell erkennbar: wenn bei grösseren Änderungen hunderte von Tests aktualisiert werden müssen kann das einen Pflegeaufwand bedeuten, der wieder Wochen und Monate dauert - damit ist man wieder bei den Zeiträumen die man vorher hatte.

Um diesem Phänomen (der so genannten "Testautomatisierungs-Falle") zu entgehen müssen Erstellung und Struktur der automatisierten Tests an die agilen Entwicklungsprozesse angepasst werden. Wie das im Einzelfall aussieht kann von Fall zu Fall anders aussehen, folgende Grundsätze sind aber sehr häufig: Zusammenlegung von Test- und Entwicklungsteam, Modularisierung und Parametrisierung.

Die Zusammenlegung von Test- und Entwicklungsteam ist die einfachste, weil eher organisatorische Massnahme. Statt zwischen Entwicklung und Test einen kleinen Wasserfall aufzubauen werden die Tests jetzt gleich vom Entwicklungsteam erstellt, wodurch sie schneller fertig und aktueller sind. Ein unterschätzer Nebeneffekt kommt dazu: die "Tester" können in diesem Vorgehen selbst programmieren, was die Voraussetzung für Automatisierung ist.

Die Modularisierung sorgt dafür, dass der Instandhaltungsaufwand sinkt. Wenn z.B. nicht mehr in jedem von 100 Tests die Login-Schritte separat ausgeführt werden, sondern diese Schritte nur noch aus einem einzigen zentral gepflegten Modul abgerufen werden, muss ein geänderter Login-Vorgang nur noch einmal geändert werden statt 100 mal. Der Instandhaltungsaufwand sinkt damit auf 1% seines Umfangs (!).

Ähnliche Auswirkungen hat eine Parametrisierung. Bei ihr werden veränderbare Variablen (Testumgebungen, Browser, Testdaten, etc.) nicht mehr hart in den Test gecodet sondern ebenfalls zentral gepflegt. Bei der Test-Suite einer Web-Anwendung reicht es dann eine einzige zentrale Einstellung zu ändern und hunderte Tests laufen auf Firefox statt auf Chrome. Auch hier sinkt der Instandhaltungsaufwand immens.

Es ist offensichtlich, dass (und warum) die Testautomatisierungs-Falle und die dazugehörenden Gegenmassnahmen von zentraler Bedeutung für agile Software-Entwicklung sind. Und ganz nebenbei ergibt sich aus ihnen übrigens auch ein brauchbarer Lackmustest für Agile Coaches und Scrum Master. Die müssen nicht selbst Tests automatisieren können, sie sollten die Testautomatisierungs-Falle aber beschreiben können. Wenn das nicht geht sind sie (noch) zu technikfern.

Der Product Owner als Key Account Manager

Bild: Pexels / Christina Morillo - Lizenz

Eine der zentralen Vorraussetzungen von agiler Produktentwicklung ist die Etablierung von so genannter Product Ownership. Um für den eigenen Fortschritt nicht auf andere angewiesen zu sein wird eine möglichst starke Focussierung angestrebt. Ein einziges crossfunktionales Team exklusiv für ein Produkt, mit allen Berechtigungen es verändern und modifizieren zu dürfen. Nur so ist das schnelle Inspect & Adapt möglich, das den Kern aller agilen Vorgehensweisen bildet.

Der de facto Standard dieser Umsetzungen ist mittlerweile Scrum, das in seinen Teams sogar eine explizite Rolle für Product Ownership hat, sinnigerweise Product Owner genannt. Richtig umgesetzt ist der nicht nur ein einfacher Business Analyst oder Anforderungsmanager sondern er entwickelt sein Produkt langfristig und strategisch weiter, hat den Überblick über vergangene Entscheidungen und hält Kontakt zu dessen Anwendern und Stakeholdern.

Soweit die Theorie. In den meisten Fällen ist sie anwendbar, in einigen allerdings nicht. Im Agentur-Umfeld kommt es beispielsweise vor, dass Teams für einzelne Sprints an Kunden verkauft werden um an dessen Systemen zu arbeiten, in Konzernen kann es sein, dass die Zuordnung eines Teams zu einem Produkt nur so lange anhält wie die dahinterstehende Fachabteilung Projektbudget hat. In diesen und vergleichbaren Fällen springen Teams und Product Owner regelmässig von Produkt zu Produkt.

Um die negativen Effekte dieser ständigen Wechsel zumindest in Grenzen zu halten findet man in manchen Unternehmen eine Ausgestaltung der Product Owner-Rolle die in Teilen einem Key Account Manager entspricht, also dem Hauptbetreuer eines wichtigen Kunden oder Auftraggebers. Für diesen ist der jeweilige Product Owner dann der primäre Ansprechpartner in der Anwendungsentwicklung, selbst dann wenn es um verschiedene (weiter)zu entwickelnde Produkte geht.

Was in einer solchen Konstellation weiterhin möglich ist, ist eine dauerhafte Beziehung zu wichtigen Anwender- und Stakeholdergruppen. Andere Auswirkungen können zumindest abgeschwächt werden: die Kontextwechsel werden tendenziell weniger, da die Wahrscheinlichkeit steigt auch zukünftig wieder mit den Produkten zu tun haben, und vergangene Erfahrungswerte können in diesen Fällen wiederverwertet werden.

Ganz ersetzen kann eine solche Konstellation echte Product Ownership nicht (alleine deshalb nicht weil zwischendurch andere Teams daran arbeiten können), in den oben genannten Konstellationen ist sie aber eine gute Möglichkeit dem zumindest so nah zu kommen wie möglich.