Donnerstag, 28. Februar 2019

Kommentierte Links (XLVI)

Bild: Unsplash / Compare Fibre - Lizenz
  • Joe Procopio: How To Deliver Software Without Deadlines

    Ein weiterer dieser nur scheinbar selbsterklärenden Begriffe. Genau wie #NoEstimates mehr ist als der Verzicht auf Aufwandsschätzungen ist Dateless Delivery mehr als arbeiten ohne Zieldatum. Joe Procopio geht sogar soweit und sagt, dass es auch hier ein Lieferdatum gibt, nur eben keines das vom Management unverrückbar festgesetzt ist. Stattdessen gibt es einen dynamischen, sich permanent aktualisierenden Forecast, basierend auf kleinen, schrittweisen Auslieferungen, ständigen Risiko-Neubewertungen, Abstimmungen mit Stakeholdern und darauf basierenden Priorisierungs-Anpassungen. Die Frage die sich stellt: tut man diesem hochgradig vernünftigen Vorgehen einen Gefallen wenn man es mit derart missverständlichen Kampfbegriff benennt, oder hätte es nicht auch eine weniger kontroverse Wortwahl getan?

  • Brett Luckabaugh: The Risk Management Paradox - Enable Your Teams By Giving Up Control

  • Ein grosses Plädoyer für selbstverantwortliche Teams, mit einer einfachen aber oft vergessenen Offensichtlichkeit: wer Selbstorganisation will muss sie zulassen - auch und vor allem dort wo es wichtig und kritisch ist. Das damit verbundene, scheinbar paradoxe Versprechen: ein Manager der sich dazu durchringt wird am Ende nicht weniger Kontrolle haben sondern mehr, da seine von unrealistischen Vorgaben befreiten Mitarbeiter ihm sorgenfrei alle Einsichten bieten können die sie einem drängelnden und gängelnden Vorgesetzten aus reinem Selbstschutz vorenthalten würden. Wenn es darum geht Selbstorganisation im eigenen Unternehmen zu verkaufen dürfte das eine wesentlich überzeugendere Idee sein als die im letzten Abschnitt genannten plakativen Negationen.

  • Ken Schwaber: Look at Capability, not Title

    Möglicherweise die Ankündigung der nächsten Veränderung des Scrum Guide. Gegenstand könnte diesesmal die dritte Scrum-Rolle sein, die des Development Teams, bzw. Entwicklungsteams. Die hier andiskutierte Umbenennung in Delivery Team könnte auf Englisch vielleicht klärend sein, im Deutschen aber zu Verwirrung führen. Wäre "Auslieferungsteam" überhaupt ein Wort, und wenn ja, wäre es eines das erklärbar und verständlich wäre? Gegebenenfalls müsste statt einer Übersetzung der englische Originalbegriff verwendet werden, mit allen damit verbundenen Problemen. Man kann gespannt sein ob (und wenn ja wann) es dazu kommt.

  • Steve Denning: The Irresistible Rise Of Agile - A Paradigm Shift In Management

    Manchmal könnte man das Gefühl bekommen, dass Steve Denning Agilität fast im Alleingang in Richtung Management Attention geschrieben hat, gegen alle Ablehnung und alle Widerstände. Wie immer ist die Welt vermutlich zu komplex für eine solche Leistung von nur einer Person, aber alleine das in diesem Jahr voll werdende Jahrzehnt journalistischer Begleitung ist eine beeindruckende Bilanz. Die spannende Frage ist jetzt, wie es vom mittlerweile erreichten (scheinbaren?) Gipfel weitergeht. Sowohl in Bezug auf die Popularisierung der Agilität als auch in Bezug auf Dennings Berichterstattung scheint es mittlerweile nicht mehr so, dass noch viel Neues kommen könnte. Vielleicht ist diese Wahrnehmung aber noch zu sehr durch die agile Filterblase geprägt. Unterstellend dass er über diese hinaus Leser erreicht könnte er noch einiges an Artikeln vor sich haben.

  • Stefan Kühl: Agile Praktiker

    Apropos Filterblase. Das hier scheint eine Geschichte zu sein die sich in einer zugetragen hat. In irgendwelchen "deutschen Wirtschaftsmedien" soll der amerikanische Systemtheoretiker Talcott Parsons wegen seines AGIL-Schemas (Adaptation - Goal Attainment - Integration - Latency) als "Vorreiter der Agilität" gefeiert worden sein, obwohl sein Werk das gar nicht hergibt. Als im agilen Umfeld gelandeter Geisteswissenschaftler kann ich nur sagen: sollte derartiges irgendwo gestanden haben, dann nur als Orchideenmeldung. Eher könnte es so sein, dass das FAZ-Feuilleton hier genau das versucht was es anderen vorhält - durch simplifiziertes Umdeuten anschlussfähig an Diskurse aus anderen Sachgebieten werden. Agile kommt wirklich im Mainstream an.

Montag, 25. Februar 2019

Die Paradoxie der agilen Skalierung

Bild: MaxPixel - CC0 1.0
Dass die Koordination, bzw. das Alignment agiler Teams eine der grösseren Herausforderungen ist mit denen man als Manager, Scrum Master oder Product Owner konfrontiert werden kann dürfte mittlerweile Common Sense sein. Chief Product Owner, Release Trains, Tribes, Chapter, Gilden, Integration Teams und Scrum of Scrums sind mittlerweile in fast jedem grösseren Unternehmen zu finden das sich an Agilität versucht, in den meisten Fällen aber nur mit durchwachsenem Erfolg. Es entsteht meistens doch wieder Bürokratie, nur eben eine andere Art davon.

Vor allem in eher traditionell aufgestellten Unternehmen hört man vor diesem Hintergrund immer wieder, dass oberhalb der Team- oder Abteilungsebene wieder mit klassischem Management gearbeitet werden müsste. Agile Ansätze hätten "genug Zeit gehabt sich zu beweisen", wären aber den Nachweis schuldig geblieben, dass sie auch für koordinerte Lieferzyklen von 30, 50 oder noch mehr Organisationseinheiten sorgen könnten.

Auf den ersten Blick ist diese Aussage auch nicht falsch, ab einer bestimmten Grössenordnung (ob die jetzt bei 30, 40 oder 50 Teams liegt ist nebensächlich) werden die oben genannten Skalierungswerkzeuge mit sehr grosser Wahrscheinlichkeit zu Verwaltungs-Overhead führen. Gegenbeweise grosser Gruppen alignter Teams gibt es zwar, aber sie sind eher selten. Doch das ist nicht die ganze Wahrheit. Auf den zweiten Blick kommen auch andere Einsichten zum Tragen.

Korrekt eingesetzt führt der Einsatz agiler Frameworks dazu, dass der Koordinationsaufwand zwischen den Teams sinkt. MVPs und Sprintziele machen grosse Releases fachlich und wirtschaftlich unnötig, CI und CD sorgen dafür, dass sie auch technisch überflüssig sind, crossfunktionale E2E-Teams sind weniger abhängig von anderen Einheiten und müssen nicht mehr koordiniert werden. Zusammengenommen führen diese Faktoren dazu, dass es schlicht keinen Bedarf mehr für agile Skalierung gibt.

Letztendlich ist es eine paradoxe Situation: der Erfolg agiler Zusammenarbeit in grossen Organisationen zeigt sich daran, dass es keine agilen Zusammenarbeitsmodelle auf grosser Ebene gibt. Das klingt un-intuitiv und für viele Verantwortliche erst einmal unglaublich. Diesen Unglauben zu überwinden dürfte eine der zentralen Herausforderungen agiler Skalierungsvorhaben sein.

Donnerstag, 21. Februar 2019

Hasenbrot-Syndrom

Bild: Pixabay / kalhh - Lizenz
Vor langer Zeit habe ich für ein paar Monate in einem Krankenhaus gearbeitet. Unter den vielen Dingen die aus dieser Zeit in Erinnerung geblieben sind sticht eines heraus: die Vorliebe mehrerer älterer Patienten für altes, trockenes Brot, so genanntes Hasenbrot (→ eigentlich zum Verfüttern an die Hasen gedacht). Dass dieses Detail hängengeblieben ist liegt an einer weiteren Begebenheit wenige Jahre später, denn in einem Psychologiebuch an der Universität befand sich eine Erklärung dafür.

Dem Verfasser zufolge führte die Lebensmittelknappheit in den späteren Jahren des zweiten Weltkriegs dazu, dass in vielen Gegenden kaum frisches Brot verfügbar war. Man musste sich mit dem alten, hart gewordenen begnügen. Eine schwierige Situation, der das Unterbewusstsein vieler Menschen mit einer Selbsttäuschung begegnete. Hasenbrot sei doch eigentlich köstlich, redeten die Betroffenen sich ein, man könne froh sein es zu haben. So wurde die Situation erträglicher.

Dieses Phänomen (in der Psychologie spricht man von einem Bestätigungsfehler) setzte sich auch nach dem Krieg fort. Obwohl frisches Brot wieder verfügbar gewesen wäre blieben viele Betroffene bei einer Vorliebe für altes, trockenes. Denn: jetzt davon abzulassen wäre einem Eingeständnis gleichgekommen sich selbst jahrelang belogen zu haben. Bewusst oder unbewusst wurde entschieden diese Lüge aufrechtzuhalten, mit der Konsequenz bis zum Lebensende trockenes Brot essen zu müssen.

Ein derartiges Hasenbrot-Syndrom (so wurde es in dem Buch bezeichnet) kann man auch unabhängig von seinem namensgebenen Objekt vorfinden. Überall dort wo jemand mit belastenden Umständen seinen Frieden gemacht hat kann es dazu kommen, dass er sich selbst vormacht sie unproblematisch oder sogar erstrebenswert zu finden. Je nach Kontext kann das zu grotesken Ergebnissen führen, etwa dazu, dass sogar sinnentleerte, repressive und entmündigende soziale Systeme verteidigt und freiwillig beibehalten werden.

Dort wo gut gemeinte Change-Bemühungen auf derartig begründete Widerstände treffen kann ein weiteres Vorgehen schwierig und schmerzhaft werden. Die Neubewertung einer bisher existierenden Gehorsams- oder Angstkultur als falsch, sinnlos oder unmoralisch kann an Lebenslügen rühren, mittels derer sich die Betroffenen mit den herrschenden Umständen arrangiert haben. Die damit verbundenen Abwehrreaktionen können emotional und heftig sein.

Der Umgang mit solchen Hasenbrot-Syndrom-artigen Widerständen ist schwierig und bewegt sich auf einem schmalen Grad zwischen Fürsorge, gerechtfertigten Eigeninteressen und vorschneller Pathologisierung. Wenn möglich sollte das weitere Vorgehen Menschen überlassen werden die dafür ausgebildet sind.

Montag, 18. Februar 2019

Datengetriebene Retrospektiven (II)


Es ist eine der Anekdoten die von nahezu jedem erzählt werden können, der in verschiedenen agil arbeitenden Unternehmen unterwegs gewesen ist. Irgendwann kommt ein Scrum-Team auf die Idee, auf Kanban umsteigen zu wollen. Natürlich geht das, die Teams sind ja selbst organisiert. Und kurz danach geht die Liefergeschwindigkeit drastisch in den Keller. Was ist da passiert und warum passiert das immer und immer wieder?

Der typische Hintergrund einer solchen Verschlechterung ist ein populärer Irrtum: viele Teams (meisten die, die der Meinung sind, dass der Scrum Master der Einzige ist der sich für Methoden interessieren muss) halten Kanban für "Scrum ohne Sprints und ohne Meetings" und setzen es auch so um. Auf der linken Seite wird immer neue Arbeit aufs Board gehängt, wandert nach rechts und wird abgenommen. Natürlich ist das nicht im Sinn der Idee.

Was in diesen Fällen verloren geht sind die Effekte wegen denen Scrum überhaupt erfunden wurde. Ohne Sprints ist es nicht offensichtlich wenn Arbeitspakete zu gross sind, ohne Retrospektiven wird das nicht als Problem adressiert, ohne Plannings findet kein Kleinschneiden der Aufgaben statt. Stauungen und Probleme sind nur dann sichtbar wenn sie auftreten und nicht rückverfolgbar. Es wird einfach irgendwie vor sich hingearbeitet, ohne Gedanken daran ob es vielleicht besser ginge.

Die Ironie dieser Geschichte - wenn Kanban richtig eingesetzt wird gibt es für diese Probleme eine gleich gute Lösung. Sie besteht darin, Metriken zu erheben. Das ist mit einfachen Mitteln möglich, in der Regel reichen zu Beginn sogar die, die das Team ohnehin bereits benutzt: Stift und Papier. Wenn für jeden Tag zwischen Anfang und Ende der Umsetzung ein Punkt auf den Zettel gemacht wird hat man am Ende die wichtigste Zahl parat, die Durchlaufzeit oder Lead Time.

Bei Systemen in denen Arbeit durch mehrere Phasen geht kann auch das einfach dargestellt werden. Während der ersten Phase werden blaue Punkte gemacht, in der zweiten grüne, in der dritten schwarze etc. Und noch weitere Informationen lässt sich durch farbliche Markierungen darstellen: wenn ein Arbeitsvorgang blockiert ist und nicht weitergehen kann, kann der Punkt Rot oder Rot umrandet sein, wenn er in einem Rückstau feststeckt Orange.

Aus diesen Punktzahlen lässt sich auf unkomplizierte Weise Redebedarf ableiten. Sobald eine abgeschlossene Arbeit vom Board abgehängt wird werden die Punkte gezählt. Und ab einer vereinbarten Schwelle (z.B. ab 5 roten Punkten, 8 Punkten in Rot und Orange oder in Summe mehr als 14 Punkten aller Farben) sollte eine Retrospektive stattfinden in der besprochen werden kann was die Ursache für den Rückstau, die Blockade oder die lange Dauer war (für ein alternatives Vorgehen siehe hier).

Erfahrungsgemäss haben viele der von Scrum auf Kanban umgestiegenen Teams Probleme mit diesem Vorgehen, da es dazu führen kann, dass ähnlich viele oder sogar mehr Retrospektiven (und Planungsmeetings für die Umsetzung der dort vereinbarten Massnahmen) nötig sind als in Scrum. Das ist dann ein wunderbarer Anlass für ein Gespräch darüber, dass zu einem selbstorganisierten Team auch dann ein selbstorganisierter Verbesserungsprozess gehört wenn es nach Kanban arbeitet.

Freitag, 15. Februar 2019

Being Agile is our favourite thing

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

Dienstag, 12. Februar 2019

Psychologische Sicherheit

Bild: Pixabay / Jill111 - Lizenz

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.

Donnerstag, 7. Februar 2019

Objektpermanenz

Bild: Pexels / Janko Ferlic - Lizenz
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.

Montag, 4. Februar 2019

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.