Being Agile is our favourite thing

Ich weiss nicht ob ich sprachlos bin, begeistert oder erschüttert. Oder alles gleichzeitig.

Psychologische Sicherheit

Bild: Pixabay / Jill111 - CC0 1.0

Zu den vermutlich am stärksten unterschätzten Voraussetzungen für agile Teams dürfte die Psychologische Sicherheit gehören, also die Gewissheit für Diskussionsbeiträge, Vermutungen und Fehler nicht angegriffen, gedemütigt oder bestraft zu werden. Häufig als "Psycho-Kram" verworfen stellt es einen Schlüsselfaktor für viele Elemente dar die für die Agilität wesentlich sind.

Wer sich wünscht, dass auch neue, innovative und disruptive Produktideen entstehen darf nicht alles Unbekannte von Anfang an abbügeln, wer will, dass die eigenen Mitarbeiter und Kollegen sich weiterentwickeln darf sich nicht über anfängliche Verständnisfragen lustig machen, wer möchte, dass aus Fehlern gelernt wird darf nicht jeden der sie macht an den Pranger stellen. Dort wo es doch geschieht werden die Menschen im Zweifel lieber schweigen als sich angreifbar zu machen. So weit, so klar.

Eine Kultur zuzulassen in der die genannten Verhaltensweisen nicht überhand nehmen ist trotzdem schwer, vor allem in Organisationen in denen über eine längere Zeit eine Fehlervermeidungs- oder sogar Fehlerbestrafungs-Kultur stattgefunden hat. Diese zu überwinden kann harte Arbeit an sich selbst erfordern - für die jeweiligen Vorgesetzten, für die Kollegen, aber auch für diejenigen selbst die eine Kultur der psychologischen Sicherheit für sich und andere einfordern.

Die Kehrseite einer solchen Kultur ist nämlich, dass Fragen, Probleme, Fehler und Herausforderungen deutlich häufiger ausgesprochen werden als vorher - und genau das ist auch der Sinn des Ganzen. Das gesamte Konstrukt der Sorgen-, Angst- und Schamfreiheit hat (aus Unternehmenssicht) den zentralen Zweck, dass Mißstände festgestellt, sachlich diskutiert und beseitigt werden können. Dessen muss man sich bewusst sein.

Dort wo an psychologischer Sicherheit gearbeitet wird kommt es daher mitunter zu ganz eigenen Leidensgemeinschaften: Managern die sich zurücknehmen müssen und Teammitgliedern die sich öffnen müssen. Beides erfordert zu Beginn Überwindung, beides führt hinaus aus der eigenen Komfortzone. Aber (und hier schliesst sich der Kreis) - beides wird um so einfacher je mehr psychologische Sicherheit vorhanden ist.

Objektpermanenz

Bild: Pexels / Janko Ferlic - CC0 1.0

Es ist eine der grossen und immer wiederkehrenden Diskussionen im Umfeld fast aller agilen Teams: sollte der aktuelle Arbeitsstand mit Post Its auf physischen Boards festgehalten werden oder doch eher in digitalen Task-Tools? Zwar ist im Zweifel immer das gute alte "kommt drauf an" die richtige Antwort, es gibt aber große Vorteile, die durch physische Boards ermöglicht werden. Der Gesamtblick auf das "Big Picture" wurde hier bereits erwähnt, er lässt sich aber noch weiter ausführen - er erzeugt etwas, das man Objektpermanenz nennt.

Hinter diesem Begriff verbirgt sich zunächst ein Phänomen der Kognitionspsychologie: sowohl menschliche Kleinkinder als auch die meisten Tiere können ein Objekt welches zeitweise aus dem eigenen Blickfeld verschwindet nicht als das Selbe wiedererkennen wenn es wieder auftaucht. Z.B. wird ein Hund der hinter einen Zaun läuft und auf dessen anderer Seite wieder auftaucht für ein zweites, vom ersten unabhängig existierendes Tier gehalten.

Während dieser einfache Zusammenhang (es ist der selbe Hund) schon von grösseren Kindern problemlos erkannt werden kann stellen abstraktere Zusammenhänge selbst erwachsene Menschen vor Probleme. Arbeits- oder Verarbeitungsprozesse in denen Liefergegenstände ihre Erscheinungsform ändern (z.B. Idee → Konzept → Coding → erratisches Systemverhalten) sind oft nicht mehr als zusammenhängend zu erkennen, wenn einzelne Zwischenstadien (z.B. der Code) sich der Sichtbarkeit oder dem eigenen Verständnis entziehen.

Die Folge dieses Phänomens ist der aus vielen Grossvohaben bekannte Effekt, dass an verschiedenen Stellen Arbeit "aus dem Nichts heraus" zu entstehen scheint, mit all den bekannten Auswirkungen auf Planbarkeit, Berechenbarkeit und Stabilität. Dass diese Arbeit in Wirklichkeit auf frühere Phasen zurückgeht ist durch Abstraktion und Erscheinungsform-Änderung nur noch schwer nachzuvollziehen.

Um alle Zwischenstadien eines Arbeitsvorgangs wieder als zusammengehörig erkennen zu können ist eine visuelle Darstellung hilfreich. In ihr können zusammenhängende Teile durch Farben oder Zeilen (oder beides) hervorgehoben werden, während die Be- oder Verarbeitungsfortschritte durch Phasen, bzw. Spalten dargestellt werden. Das Ergebnis - nichts anderes als ein Kanban-Board:

Auch hier könnte man natürlich überlegen ob digitale Lösungen nicht ähnlich gut darin wären Zusammenhänge aufzuzeigen. Auszuschliessen ist das nicht, es müsste aber ein erstaunlich breiter Bildschirm sein, der dafür eingesetzt würde. Sobald einzelne Phasen durch Scrollen oder durch Ausblenden unsichtbar werden wäre die Objektpermanenz nämlich erneut unterbrochen.

Visual Facilitation

Ich versuche in meinen Workshops so viele Visualisierungen wie möglich unterzubringen. Die Erfahrung ist, dass die Informationen wesentlich besser aufgenommen und verinnerlicht werden wenn sie mit verschiedenen Sinnen aufgenommen werden. Das könnte dann so aussehen wie hier:




Natürlich sieht das bei mir bei weitem noch nicht so professionell aus wie in diesem Video, aber jeder braucht ja Bereiche in denen er noch besser werden kann.

Kommentierte Links (XXXXV)

• Henrik Bork: Toyota feuert die Roboter

  Diese Geschichte ist intensiv durch meine Timeline gegangen und wurde dort als Paradigmenwechsel wahrgenommen - ein Konzern verabschiedet sich von den Maschinen und vertraut wieder auf Menschen, da diese intelligenter, flexibler und präziser sind. Ich bin nicht sicher ob das richtig ist. Zum einen beruht das Toyota Production System schon immer grundlegend auf Autonomation, also darauf, dass Mensch und Maschine zusammenarbeiten. Zum anderen finden sich auch in der Vergangenheit zahlreiche Quellen die hervorheben, dass in dieser Firma menschliche Arbeiter Robotern vorgezogen werden, z.B. von 2017, 2014 oder 2011. Das bedeutet, dass Henrik Bork die Fertigungsstrategie von Toyota zwar richtig beschreibt, die Deutung als Paradigmenwechsel aber falsch ist - eher ist es seit langem gelebte Kontinuität.
  

• Roger L. Martin: The High Price of Efficiency

Ein langer, langer Artikel, der auf eine zentrale Wahrheit eingeht: Effizienz ist nur dann etwas Gutes wenn sie in verträglichem Ausmass und sinnvollem Kontext stattfindet. Dort wo sie zum Fetisch überhöht wird treten früher oder später negative Folgen und Begleiterscheinungen auf. Monopole und Oligopole mit hoher Missbrauchsanfälligkeit entstehen, die so stark auf die bestehenden Bedingungen optimiert sind, dass selbst überschaubare Veränderungen zu existenziellen Krisen führen können. Roger Martin schlägt (unter anderem) eine interessante Lösung vor: einen wettbewerbsrechtlichen Rahmen der bewusst Friktionen einführt um Unternehmen dazu zu zwingen kleiner, beweglicher und anpassungsfähiger zu werden. Mit anderen Worten - agil.

• Larry Larvik: 5 Reasons Why “Company Culture” is Overrated

  Bei dem Artikel bin ich zwiegespalten. Er adressiert zwar reale Probleme, die häufig auftreten und meistens als Teil einer erstrebenswerten Firmenkultur klein- oder schöngeredet werden. Diese Dinge sind allerdings weniger ein Teil tatsächlicher Firmenkulturen sondern eher von deren Perversion. Das was oft unter diesem Label vermarktet wird ist in erster Linie das Ergebnis der Bemühungen von gutmeinenden aber fehlgeleiteten HR- und Change Management-Abteilungen, die den restlichen Mitarbeitern ungefragt neue Verhaltensweisen überstülpen wollen. Denen die Deutungshoheit darüber zu überlassen was die Firmenkultur ist (und Gegenentwürfe dazu aufzubauen) geht am zentralen Punkt vorbei: die Firmenkultur ist das, was von der Mehrheit der Mitarbeiter täglich gelebt wird. Sie kann gar nicht "von oben" bestimmt werden.
  

• Greg Satell: Don’t Teach Your Kid to Code. Teach Them to Communicate.

  Mit leicht anderer Schwerpunktsetzung entspricht das hier dem was Sascha Lobon schon 2017 geschrieben hat: die Fixierung auf das programmieren lernen in der Schule geht am Problem vorbei, da auf diese Weise versucht wird die Lösungen von heute auf die Herausforderungen von morgen zu übertragen, was zwangsläufig scheitern muss. Wesentlich wichtiger sind die Fähigkeiten des Erkennens bisher unbekannter Probleme und des Erlernens genereller Lern- und Anpassungsfähigkeit. Wenn irgendwann das Aneignen einer Programmiertechnik nötig sein wird, wird es mit diesen Fähigkeiten leichter fallen (und mit der heutigen Art zu Programmieren wird es ohnehin nicht mehr viel gemeinsam haben).

• Yanna Vogiazou: Hacking the Design Sprint method to solve a complex problem

  Die Geschichte in Kürze: eine kalifornische Agentur hat die Design Sprints von Google übernommen und für die eigenen Zwecke angepasst. Die grössere Geschichte dahinter: Sprints gibt es nicht nur in Scrum. Jede Gruppe kann sie durchführen, egal ob in enger Folge, gelegentlich oder nur einmal. Auch dann wenn sie sonst nicht agil arbeitet, auch dann wenn ihre Mitglieder bisher noch nicht zusammengearbeitet haben oder später nicht mehr zusammenarbeiten werden. Vielleicht ist das einer der einfachsten Einstiege in die Agilität, einer der Vieles spürbar und erlebbar macht ohne bestehende Strukturen zu verändern. Wenn diese ersten Einzelsprints zu Erfolgen führen und Neugier auf mehr machen kann das ja noch kommen.

Minimum viable Team

Bild: Pexels / Benji Mellish - CC0 1.0

Unbemerkt von den meisten Anwendern stecken in agilen Ansätzen wie Extreme Programming oder Scrum zwei Bestandteile der zumindest herausfordernd und in manchen Zusammenhängen sogar sich gegenseitig blockierend sind. Zum einen sollen die hier beschriebenen Produktentwicklungsteams crossfunktional sein, also alles selbst erstellen können was für eine Funktionserweiterung nötig ist, zum anderen soll ihre grösse unter zehn Mitgliedern liegen. Das beisst sich häufig.

Ein banales Beispiel macht das deutlich: in stark regulierten Branchen wie im Banken- oder Börsenbereich sind zahlreiche Gesetze und Vorschriften einzuhalten. Werden sie missachtet können Aufsichtsbehörden wie die Bafin oder die EZB Strafen verhängen oder sogar Produkte vom Markt nehmen. Es empfiehlt sich also, neue Produktinkremente von Juristen, Verbraucher- und Datenschützern freigeben zu lassen. Diese ins Team zu nehmen würde die Grössenbegrenzung sprengen, sie draussen zu lassen die Crossfunktionalität beeinträchtigen.

Wenn man dem Reflex wiedersteht die Teams einfach grösser zu machen bleibt nur eine Alternative: selten benötigte Aufgaben aus den Randbereichen des eigenen Tätigkeitsbereiches werden an Unterstützer- oder Spezialistenteams ausgelagert. Zurück bleibt eine Gruppe, die für die häufig durchgeführten Kerntätigkeiten verantwortlich ist, gewissermassen ein "Minimum viable Team". Die meisten agilen Teams gehören diesem Typ an, es stellt sich aber die Frage - welche Fähigkeiten sind in einer solchen Einheit unverzichtbar?

Ausgehend davon, dass die meisten agilen Teams Software produzieren ist die naheliegende Antwort die, dass es Software-Entwickler sein müssen. Mit den Worten von Extreme Programming-Begründer Ron Jeffries: "If you want a program, you can't get one without a programmer. All the designers and PMs and all those very important skills are stymied until someone can write the program." Mit anderen Worten: nahezu alles lässt sich in der IT von aussen zuliefern, nur die IT selbst nicht. Scheint offensichtlich - oder?

Wie so häufig gilt auch hier die Antwort: kommt drauf an. In den meisten Fällen liegt Jeffries zwar richtig, in einer frühen Phase der Produktentwicklung kann es aber sein, dass auch in einem Software-Kontext noch kein Entwickler nötig ist. Der initiale Tauglichkeits- oder Marktfähigkeitsbeweis ist oft noch ohne sie zu bewältigen. Ein scheinbarer Widerspruch, aber eben nur ein scheinbarer. Wie er aufzulösen ist kann man im lesenswerten Artikel "How to Build an MVP App Without Writing Code" erfahren.

Natürlich sind die hier genannten Beispiele der Bank-IT und der MVP-Apps Extremfälle, mit denen die meisten Teams nie zu tun haben werden. Der Punkt sind aber auch nicht diese beiden speziellen Konstellationen an sich. Wirklich wichtig ist die Frage die sie verdeutlichen: wenn ein Team nicht alles selbst erzeugen kann, was ist dann in keinem Fall verzichtbar? Sich diese Frage zu stellen (und das mit wirklicher Unvoreingenommenheit und Ergebnisoffenheit) ist das was zu einem wirklichen Minimum viable Team führen kann.

Definition of Ready

Bild: Pixabay / DCG:MAK - CC0 1.0

Scrum wird in Workshops häufig als Schleife (Loop) visualisiert, mit den Rollen in der Mitte, den Meetings und Artefakten am Rand und jeweils einem Quality Gate am Anfang und am Ende. Das am Ende ist hier bereits thematisiert worden, die Definition of Done (DoD), was noch fehlt ist das Gate am Anfang, die so genannte Definition of Ready (DoR).

Unter ihr versteht man üblicherweise eine Liste von Kriterien die erfüllt sein müssen bevor eine Anforderung zur Umsetzung in einen Sprint übernommen wird. Häufig anzutreffen sind z.B. "Alle Teammitglieder müssen die Anforderung verstanden haben", "Es müssen validierbare Akzeptanzkriterien formuliert sein" oder "Die Umsetzung dieser Anforderung muss einen erkennbaren Mehrwert erzeugen".

Der Hintergrund der DoR ist schnell erkennbar. Mit ihr lässt sich verhindern, dass unklare, nicht testbare oder betriebswirtschaftlich unsinnige Ideen in die Umsetzung geraten. Die in diesen Fällen unausweichlichen (und oft unschönen) Diskussionen können so unterbunden werden noch bevor es einen Anlass für sie gibt. Das Team kann sich stattdessen auf seine eigentliche, wertschöpfende Arbeit konzentrieren.

Für viele überraschend: trotz dieser Vorzüge ist die Definition of Ready kein offizieller Teil von Scrum sondern gehört zu den vielen good Practices, die man zwar befolgen, genau so gut aber auch weglassen kann. Da sie weit verbreitet ist kann das nicht an fehlender Bekanntheit liegen sondern ist von Schwaber und Sutherland bewusst beabsichtigt worden. Warum das?

Das mit der DoR verbundene Risiko ist, dass Teams sich dadurch versehentlich Wasserfall-artige Strukturen aufbauen können. Ein zu restriktives Beharren auf von allen Teammitgliedern verstandene Anforderungen wird zwangsläufig einen solchen Beschreibungsumfang zur Folge haben, dass wieder eine vorgelagerte Konzeptionsphase entsteht in der Detailspezifikationen erzeugt werden. Das wäre nicht mehr im ursprünglichen Sinn der Agilität.

Darüber hinaus ist eine zu detaillierte Definition of Ready ein Indikator für gleich zwei Antipattern: für unzureichende Backlog Refinements und für ein Misstrauen eines Entwicklungsteams gegenüber seinem Product Owner. Würden zur Umsetzung vorgesehene Anforderungen ausreichend besprochen (nicht beschrieben!) und würde das Team darauf vertrauen, vom PO nur umsetzbare Aufgaben zu erhalten - ein zusätzliches Quality Gate wäre unnötig.

Eine DoR ist aus diesen Gründen ein zweischneidiges Schwert. Sie kann unerfahrenen Teams bei der Umsetzung von Scrum helfen, kann aber auch versehentlich dazu führen, dass die Methodik sich selber aushebelt. Von vielen Teams wird sie daher gar nicht erst eingeführt oder irgendwann wieder abgeschafft.

Agile Governance (II)

Zum Thema Agile Governance habe ich bereits vor einigen Jahren etwas geschrieben, aber Dan North geht mit einem weitaus grösseren Detailgrad darauf ein. Vieles davon ist "agiler common sense", aber es ist immer wieder interessant alles im Kontext zu sehen. Und die Automatisierungs-Beispiele am Ende können sogar als Vorbild genutzt werden.