Montag, 20. Mai 2019

Story Points entsprechen Zeit (und passen trotzdem auf keinen Zeitstrahl)

FS
Bild: Pixabay / Geralt - CC0 1.0
Zu den am häufigsten missverstandenen Elementen agiler Arbeitsweisen gehören Story Points. Von klassischen Projektmanagern werden sie häufig in Zeiteinheiten umgerechnet, was bei den meisten agil arbeitenden Team zu heftigen Abstossungsreaktionen führt. Auf die Frage was diese Punkte denn dann sein sollen wenn nicht Zeit wird häufig erklärt, dass sie die Komplexität der geschätzten Arbeit anzeigen, was nicht in Stunden oder Tage umrechenbar wäre. Für alle die dieser Meinung sind dürfte die letzte Woche ein unangenehmes Erwachen gewesen sein.
Der Herr der diese (rhetorische) Frage stellt ist Ron Jeffries, und was er andeutet stimmt - er gehörte in den 90ern zu den Erfindern der Story Points. Er weiss also tatsächlich wie sie gemeint sind und was sie bedeuten sollen. Auch zum Thema Komplexität hat er eine Meinung - und es ist keine gute.
Für ihn ist also klar, dass Story Points Zeit bedeuten und nicht Komplexität. Und wie gesagt, er ist der (Mit)Erfinder. Haben die oben genannten Projektmanager demnach recht wenn sie einen Punkt mit einer Stunde gleichsetzen? Nun - nein. Auch nicht. Es ist (Ironie der Geschichte) komplexer als das.

Zunächst ist ein Story Point eine neutrale Schätzgrösse. Die ist nötig, da unterschiedliche Menschen für die selbe Aufgabe unterschiedlich viel Zeit brauchen. Je nachdem wer an ihr arbeitet dauert es also mehr oder weniger lang (siehe hier). Zur Ermittlung der Umsetzungsdauer einzelner Aufgaben sind Story Points demnach unbrauchbar. Genau diese Einzelfallschätzung ist es aber, die häufig verlangt wird - und dass das nicht funktionieren kann ist dann Ursache der oben genannten Abstossungsreaktionen.

Was aber machbar ist, ist die Verwendung von Story Points für die Planung grosser Mengen von User Stories. Bei 50, 100 oder mehr User Stories mitteln sich die verschiedenen Abweichungen, so dass die so genannte Velocity entsteht: der durchschnittliche Durchsatz von Story Points pro Sprint. Basierend darauf kann man Prognosen über die zukünftige Arbeitsgeschwindigkeit eines Teams machen (wichtig an dieser Stelle: grosse Mengen von User Stories sind nicht das Selbe wie einzelne grosse Arbeitspakete).

Aber ist denn damit zumindest langfristig eine Planungssicherheit möglich? Nun - immer noch nicht. Die Durchschnittsleistung eines Teams wird mit grosser Wahrscheinlichkeit sinken wenn einzelne Mitglieder ausgetauscht werden, wenn neue Technologien eingesetzt werden, wenn neue fachliche Herausforderungen anstehen oder wenn mit neuen Schnittstellen oder Kunden umgegangen werden muss. Umgekehrt kann Stabilität in Teamzusammenstellung, Technologie, Aufgabenstellung oder Umgebung auch die Velocity stabilisieren oder sogar steigern.

Hier könnte man letztendlich den Silberstreifen am Horizont vermuten. Es ist also nur nötig Teamzusammenstellung, Technologie, Aufgabenstellung und Umgebung stabil zu halten und schon kann verlässlich und sicher prognostiziert geplant werden? Ja, tatsächlich, das wäre theoretisch möglich. In der Realität dürften derartige Rahmenbedingungen aber selten bis nie auftreten. Und damit kommen wir zum vielleicht grössten der Missverständnisse rund um Story Points.

Story Points haben gar nicht den Zweck berechenbare Arbeit zu planen. Sie sollen helfen Annahmen zur Umsetzungsdauer unberechenbarer (und damit unplanbarer) Arbeit zu machen (mehr dazu hier). Das findet zwar in Zeiteinheiten statt (mit den oben genannten Einschränkungen), da einige der Annahmen sich aber als falsch herausstellen werden wird das Gesamtergebnis immer anders sein als die initiale Annahme. Das Fazit kann daher nur lauten: Story Points entsprechen zwar Zeit - passen aber trotzdem auf keinen Zeitstrahl.

Donnerstag, 16. Mai 2019

Modularisierung

FS

Manchmal sind die Unterschiede zwischen Software und Hardware kleiner als man denken sollte. Bestimmte Situationen können in beiden Fällen so ähnlich sein, dass sie ähnliche Herausforderungen und ähnliche Lösungsansätze mit sich bringen. Ein Glücksfall für alle die diese erklären müssen, schliesslich bieten sich dadurch verständliche Analogien mit denen man arbeiten kann.

Ein derartig eingängiges Fallbeispiel befindet sich zur Zeit zwischen Köln und Bonn, in einem Ort mit dem schönen Namen Wahn. In Wahn befindet sich eine Brücke über die die Autobahn 59 geführt wird, und da diese Autobahn um eine weitere Spur ausgebaut werden soll wird als erster Schritt diese Brücke erneuert. So weit, so banal. Und doch ist dieser Brückenneubau etwas Besonderes.

Wie man den Internetseiten des Landesbetriebs Strassenbau entnehmen kann wurde die Wahner Brücke anders gebaut als üblich. Während es sich bei den meisten Autobahnbrücken um zwei parallele Teilbauwerke handelt (eine pro Richtung) besteht diese hier aus einem einzigen Stück. Um jetzt jeweils die eine Hälfte erneuern zu können während der Verkehr über die andere geführt wird muss die Brücke vorher in zwei Teile zersägt werden.

Natürlich ist das kein einfaches Unterfangen. Die Geräte benötigen Platz, die Statik und Stabilität des Gesamtbauwerks muss gesichert werden, die Arbeit muss von Spezialisten durchgeführt werden die nicht sofort zur Verfügung stehen, sowohl die benötigte Zeit als auch die zu zahlenden Kosten sind höher als sie es bei einer der üblichen zweigeteilten Brücken sein würden. Man kann sich vorstellen was alles dahintersteckt.

Zur Analogie: auch in der Softwareentwicklung können derartige Situationen auftreten. Es sind hier zwar keine Fahrspuren die parallel laufen, es können aber Transportwege für Daten sein, beispielsweise einer für Stammdaten und einer für Metadaten. Und auch hier ist es so, dass ein festes Verbinden dieser Wege zu Problemen führt - soll einer von ihnen erneuert werden muss man entweder beide umbauen (und ggf. sperren) oder sie vorher aufwändig in separate Module zerschneiden.

Sogar die Ursachenforchung dürfte zu ähnlichen Ergebnissen führen. Ob es Zeitnot war, zu wenig Budget, fehlende Erwägungen zukünftig nötiger Arbeiten oder schlicht Gedankenlosigkeit, all das kann sowohl im Fall von Software als auch im Fall von Hardware der Grund für die fehlende Modularisierung sein, in Wahn genau wie in der IT.

Zuletzt bietet der Brückenbau zu Wahn noch ein weiteres "Geschenk" für alle die ihn zu Vergleichszwecken nutzen wollen: neben dem Anlass und der Analogie bietet er auch die Zeit für eine Erklärung. Er sorgt nämlich ein Jahr lang jeden Tag für Stau.

Montag, 13. Mai 2019

Scrum in der Schule

FS
Manchmal muss man in die Ferne blicken um das Naheliegende zu entdecken. Auf der re:publica 2019 wurde eine Schule aus Bonn vorgestellt die Scrum im Unterricht einsetzt. Und ohne es zu wissen bin ich erst vor wenigen Tagen an ihr vorbeigelaufen. Eine kleine Welt.

Donnerstag, 9. Mai 2019

Retrospektiven-Ergebnisse

FS
Bild: Pexels / Elevate Digital - CC0 1.0
Egal ob man sie Retrospektiven nennt oder Lessons Learned-Meetings, Kaizen-Events, Schulterblick oder KVP-Sitzung, es sind derartige Veranstaltungen die den Kern aller ständigen Verbesserungsprozesse bilden und damit auch den Kern der Agilität. In ihnen können Beschlüsse und Massnahmen erarbeitet werden durch die der Inspect & Adapt-Prozess mit Leben gefüllt wird. Um in diesem Zusammenhang zielgerichtet vorgehen zu können empfiehlt sich ein näherer Blick: welche Arten von Ergebnistypen können hier entstehen?

1. Action Items

Der Retrospektiven-Klassiker. Was auch immer vom Team selber erledigt werden kann lässt sich als Massnahme beschliessen und mitnehmen. Wie das im Einzelfall aussieht kann sich von Fall zu Fall unterscheiden, es gibt aber good Practices: die Massnahmen sollten bis zur nächsten Retrospektive abschliessbar sein, es sollte eine Person für die Umsetzung (bzw. deren Koordination) verantwortlich sein und der damit verbundene Aufwand sollte in die Kapazitätsplanung einfliessen. Besonders das letzte klingt zwar selbstverständlich, wird aber häufig vergessen.

2. Anforderungen

Für die einen naheliegend, für die anderen nicht. Gehören Anforderungen nicht eher zur Planung als zum Lessons Learned? Im Prinzip ja, allerdings fallen sie auch im Planning oder Replenishment nicht vom Himmel. Irgendwo befindet sich ein vorgelagerter Schritt in dem sie initial erdacht werden, und der kann auch eine Retrospektive sein. Wenn hier z.B. beschlossen wird, dass ein Refactoring oder Monitoring Sinn macht, kann das in den Planungs- und Priorisierungsprozess einfliessen und auf diese Weise in die Umsetzung gegeben werden.

3. Apelle

Ein eher unschöner Ergebnistyp. Wenn sich ein Missstand ausserhalb der Einflusssphäre eines Teams befindet bleibt manchmal keine andere Möglichkeit übrig als einen Apell an denjenigen zu richten der zur Behebung in der Lage ist. An dieser Stelle liesse sich zwar kontrovers diskutieren ob ein Team das nicht alle Probleme selbst beheben kann an seiner Crossfunktionalität arbeiten müsste, im Moment des unmittelbaren betroffen Seins sind diese Überlegungen aber nicht hilfreich. Ein parallel zum Apell verfasstes Action Item zum Skillaufbau ist dagegen eine gute Idee.

4. Buffer / Slacktime

Frei nach Max Weber: auch das Unterlassen von etwas ist eine Massnahme. Dementsprechend kann es eine gute Idee sein einen Teil der eigenen Zeit bewusst nicht zu verplanen. Ob dieser dann als Reserve für ungeplante Arbeiten verwendet wird, für Überstundenabbau oder für Weiterbildung kann kurzfristig entschieden werden. Vor allem in hoch volatilen Umfeldern kann es sehr sinnvoll sein so vorzugehen, da es das Risiko versehentlicher Überplanung verringert und das Reaktionsvermögen erhöht.

Sicherlich existieren neben diesen vier noch weitere Retrospektiven-Ergebnistypen, die überwiegende Mehrzahl dürfte aber einem von ihnen zuzuordnen sein. Alleine sich über sie bewusst zu werden kann helfen. Sollte sich z.B. herausstellen, dass aus Retrospektiven fast ausschliesslich Apelle entstehen ist das in fast allen Fällen ein Indikator dafür, dass hier ein Problem existiert das angegangen werden sollte.

Montag, 6. Mai 2019

Code Ownership (IV)

FS
Bild: FFCU / Markus Spiske - CC0 1.0
Wie viele andere Begriffe hat auch der der Code Ownership verschiedene Bedeutungsaspekte, je nachdem aus welchem Blickwinkel man ihn betrachtet. Auf der anderen Seite verbirgt sich dahinter eine Art von Besitzanspruch im Sinne von "dieser Code gehört mir" (warum das ein Problem ist kann man hier, hier und hier nachlesen). Es lässt sich aber auch eine zweite Deutung formulieren: sich den Code zu eigen machen. Auch die ist von grosser Wichtigkeit.

Unter dem "sich zu eigen machen" können sich wiederum verschiedene Bedeutungen verbergen, die aber alle einen verwandten Inhalt haben - es geht darum das Objekt (in diesem Fall den Code) zu studieren, zu verstehen, zu erlernen oder zu verinnerlichen, bis zu dem Punkt an dem bei neuen Problemen und Herausforderungen sofort eine Idee entsteht wo und wie diese zu lösen sein könnten. Sie muss noch nicht perfekt sein, aber einen ersten Anhaltspunkt bieten.

Der Nutzen eines solchen Wissens ist offensichtlich: wann immer die genannten Problemen und Herausforderungen auftreten ist es nicht nötig sich zuerst in die Dokumentation einzulesen, Code Reviews zu machen oder Reverse Engineering zu betreiben, stattdessen kann schneller mit der eigentlichen Arbeit begonnen werden. Und bedingt durch die gegebene Vertrautheit dürfte auch deren Ergebnis besser sein.

Um ein Code Ownership in diesem Sinn zu erreichen ist es nicht ausreichend ihn geschrieben oder einmalig verstanden zu haben, schon gar nicht wenn das nur durch eine Person geschieht. Idealerweise ist es eine ganze Gruppe die sich regelmässig mit ihm beschäftigt, um so das Wissen nicht nur zu verteilen sondern durch ständige Kommunikation am Leben zu halten. Am Ende sollte dabei ein kollektives Gedächtnis des gemeinsam verinnerlichten Codes stehen.

An dieser Stelle beginnen in vielen Organisationen die Herausforderungen. Nicht etwa in erster Linie wegen der Herstellung von Collective Code Ownership (obwohl auch das schon ein Problem sein kann) sondern vielmehr weil eine regelmässige Beschäftigung eines Teams mit einem bestimmten Anwendungsteil oft nicht vorgesehen ist. Modifizierungen finden vor allem im Rahmen von Projekten statt zwischen denen Monate oder sogar Jahre liegen können.

Von diesem Muster wegzukommen und sich in Richtung einer "Continuous Code Ownership" zu bewegen kann grössere und aufwändige Umstellungen erfordern, es ist aber eine der Voraussetzungen um im Zweifel schnell lieferfähig zu sein.

Freitag, 3. Mai 2019

Ein Bild sagt mehr als 1000 Worte (XXIV)

FS

Dienstag, 30. April 2019

Kommentierte Links (XXXXVIII)

FS
  • Christiaan Verwijs: Here’s what's wrong with maturity models

  • Die Frage ist erstmal naheliegend: Wie gut bin ich eigentlich in dem was ich mache? Auf diesen Kontext hier übertragen: Wie gut beherrsche ich Agile, Scrum, Lean, Kanban, etc.? Die scheinbar naheliegendste Lösung der Überprüfung und Auszeichnung durch Zertifizierungen läuft sich gerade tot, so dass eine andere gesucht wird. Maturity Modelle scheinen auf den ersten Blick eine naheliegende Alternative, allerdings eine die mit Vorsicht zu betrachten ist. Christiaan Verwijs zeigt die grundlegenden Probleme dieses Konzepts auf - zu generalistisch, zu wenig auf den jeweiligen Fall eingehend, zu linear. Mit anderen Worten: nicht agil.

  • Joshua Kerievsky: Preconditions for Agility

    Mit der Bewegung von agilen Vorgehensweisen in Richtung Mainstream erhöht sich nicht nur die Zahl der Erfolgsgeschichten sondern auch die der Fehlschläge. Ein häufiger Grund dafür ist der Versuch "agile" Vorhaben in einem Kontext durchzuführen in dem sie nur eingeschränkt oder gar nicht funktionieren können. Joshua Kerievsky führt einige Vorbedingungen auf die gegeben sein müssen damit das Ganze Erfolgsaussichten hat: Crossfunktionalität, gemeinsames Verständnis der Ziele, Teamwork, Bereitschaft zu Work in Progress-Limits und Kenntnis der üblichen Praktiken bei allen Beteiligten. Dass das für Agilität elementar ist dürfte offensichtlich sein, umgekehrt stellt sich aber die Frage wie ohne zumindest einige dieser Vorbedingungen überhaupt produktiv gearbeitet werden kann.

  • Jeff Sutherland: Why Less Communication is Better!

    Ein weiterer Beitrag zu den Ursprüngen von Scrum und Agilität im Militär. Nach den römischen, mongolischen und preussischen Armeen diesesmal mit einem Verweis auf die modernen amerikanischen und vor allem deutschen Streitkräfte. Vom Deutschland des 21. Jahrhunderts aus betrachtet nicht ganz unproblematisch. Einen der beiden Scrum-Gründer von Wehrmachts-Begriffen wie "Auftragstaktik" und "Führen mit Auftrag" schwärmen zu sehen ist (gelinde gesagt) befremdlich und führt spätestens dann zu Unwohlsein wenn der Frankreich-Feldzug von 1940 als positives Beispiel herangezogen wird. Selbst wenn man versuchen könnte das militärische Vorgehen von der dahinterliegenden Ideologie zu trennen ist es unwahrscheinlich, dass dieses Thema hier populär wird.

  • Roman Pichler: 10 Scaling Tips for Product People

    Im Grunde auch benutzbar für jede andere Form von Skalierung im agilen Umfeld (und darüber hinaus). Pichlers 10 Skalierungstips sind:
    1. Beziehe die richtigen Leute ein
    2. Skaliere nicht zu früh
    3. Starte mit einem MVP (um noch nicht skalieren zu müssen)
    4. Mache die Entwicklungsteams verantwortlich und selbstständig
    5. Teile Teams und fülle sie auf um zu wachsen
    6. Mache Teams produktorientiert statt komponentenorientiert
    7. Starte mit allen Beteiligten an einem Ort und expandiere schrittweise (und nur wenn nötig)
    8. Erwäge die Abspaltung neuer Teilprodukte oder Varianten
    9. Nutze die Vorteile gemeinsamer Plattformen (z.B. von Frontend-Komponenten oder Security)
    10. Skaliere nie zu einem späten Zeitpunkt
    Interessant an dieser Liste: während das meiste die vorbehaltlose Zustimmung der meisten agilen Practitioner finden dürfte sind mit den Tips 5 und 9 zwei durchaus kontrovers zu betrachtende dabei. Nicht dass sie nicht funktionieren könnten, sie bergen aber Risiken in sich derer man sich bewusst sein sollte.

  • Shaaron A. Alvares: Tuckman Was Wrong! Doc Norton on Reteaming Models

    Zum Abschluss noch ein Link der zusammen mit dem ersten eine thematische Klammer bildet. Auch das legendäre Tuckman-Modell der Teambildungsphasen (Forming, Storming, Norming, Performing, Adjourning) krankt daran, dass es zu generalistisch, zu wenig auf den jeweiligen Fall eingehend und zu linear ist. Interessant ist insbesondere der Link zu einer Studie mit über 300 Teams, derzufolge nur zwei Prozent von ihnen (!) sequentiell durch die fünf Phasen gingen. Ob die beschriebenen Alternativen der "fluiden Teams" oder des "dynamic Reteamings" besser sind könnte man aber auch diskutieren. Wie so oft: es kommt darauf an.

Donnerstag, 25. April 2019

The New Managerial Contract

FS
Nach diesem Video ist man glatt versucht sich bei Hamza Khan um einen Job zu bewerben, so überzeugend ist er in seinem Vortrag. Dazu die Acherbahnfahrt durch die Management-Geschichte, von der Industrialisierung über Peter Drucker bis Jay-Z und einige minimalistische Slides mit prägnanten Aussagen. So sollten Talks sein.


Montag, 22. April 2019

Willkürliche Deadlines

FS
Bild: Wikimedia Commons / Waterced - CC BY-SA - 4.0
Fast jeder der länger in Projekten oder Programmen jeglicher Grösse gearbeitet hat wird sie kennen: willkürliche, unrealistische Deadlines. Nicht zu verwechseln mit den gerechtfertigten Deadlines (z.B. wegen sich ändernder Gesetze), mit denen man irgendwie umgehen muss, handelt es sich bei ihnen um scheinbar ohne Notwendigkeit getroffene Entscheidungen, bei denen allen Beteiligten von Beginn an klar ist, dass man sie mit grosser Wahrscheinlichkeit deutlich verfehlen wird. Warum es trotzdem immer wieder zu ihnen kommt erkennt man an einem aktuellen Beispiel.

Nur wenige Tage nach dem Brand der weltberühmten Kirche Notre Dame de Paris wurde bereits verkündet wann der Wiederaufbau abgeschlossen sein soll: in fünf Jahren, also 2024. Dass diese Zahl realistisch ist kann zu Recht bezweifelt werden. Bereits vor dem Brand war der Bau schwer beschädigt, die zusätzlichen Beschädigungen durch den Brand sind in ihrer Tragweite noch nicht absehbar und um das Ganze noch komplexer zu machen soll in den Wiederaufbau das Ergebnis eines noch durchzuführenden Architekturwettbewerbes einfliessen. Auf dieser Grundlage in so kurzer Zeit fertig zu werden ist illusorisch.

Dass diese Zahl trotzdem im Raum steht hat Gründe. Der naheliegendste: Wunschdenken. Die pariser Bürgermeisterin Anne Hidalgo äusserte ganz offen einen Grund für den engen Zeitplan - zu den in Paris stattfindenden olympischen Spielen 2024 sollten die Schäden beseitigt sein. Ein nachvollziehbares Anliegen, schliesslich werden dann zigtausende Athleten, Touristen und Journalisten nach Frankreich kommen. Dass dieses Wunschdenken aber nicht von Beginn an als das erkannt wird was es ist liegt unter anderem an der Entkoppelung von Auftrag und Umsetzung. Je weniger man über ein Thema weiss, desto stärker kann Realismus von Hoffnung überlagert werden.

Ein zweiter Grund ist der, dass eine derart gewagte Aussage den der sie trifft als tatkräftigen Macher erscheinen lässt. Gerade im Fall des Urhebers dieses "Fünfjahresplans", des französischen Präsidenten Macron, der sich gerade erst von verheerenden Umfragewerten erholt, eine grosse Verlockung - nicht zuletzt weil mit der Europawahl eine wichtige Abstimmung nur wenige Wochen bevorsteht. Mit dem noch frischen Eindruck eines energischen Krisenbewältigers könnte er hier punkten, unabhängig von den langfristigen Erfolgsaussichten. Und sollte er damit erfolgreich sein können sich seine Wähler später an die eigene Nase fassen.

Ein dritter Grund ist, dass das angekündigte Zieldatum in einer Zeit liegt in der Macron keine negativen Folgen für sich selbst mehr befürchten muss. Laut französischer Verfassung kann er nur einmal wiedergewählt werden, und zwar 2022, also Jahre vor dem von ihm selbst gesetzten Zieldatum. Selbst wenn die Wähler es ihm übelnehmen sollten wenn der Wiederaufbau 2024 nicht abgeschlossen ist - die Folgen darf dann ein anderer ausbaden (und selbst der kann sich dann darauf berufen, dass die Ankündigung nicht seine war. Siehe hier). Parallelen zu zeitlich begrenzten Management-Amtszeiten sind offensichtlich.

Faktoren wie diese lassen sich in vielen komplexen Vorhaben finden, ob in Staat oder Wirtschaft, in Bau- oder IT-Projekten. Betrachtet man sie lassen sie die Setzung scheinbar willkürlicher Deadlines in neuem Licht erscheinen. In den meisten Fällen sind sie bedingt durch die Funktionsweise des umgebenden Systems und ergeben im Kontext von dessen Rahmenbedingungen absolut Sinn. Umgekehrt regen diese Erkenntnisse zur Hoffnung an. Wenn ein Systemdesign derartige Phänomene begünstigt, dann kann ein anderes sie unwahrscheinlicher machen. Man kann also daran arbeiten.

Donnerstag, 18. April 2019

Warum Scrum-Zertifikate früher Sinn gemacht haben (und heute nicht mehr)

FS
Bild: Pxhere - CC0 1.0
Zertifizierungen werden im Rahmen des agilen Arbeitens (und hier besonders im Zusammenhang mit Scrum) kontrovers diskutiert. Während viele Recruiter und Personaler noch immer ein Gütesiegel in ihnen sehen herrscht unter Practitionern eher der gegenteilige Eindruck vor. Ein Zertifikat gilt hier lediglich als Beweis dafür, dass man etwas Geld übrig hatte und eine begrenzte Menge Wissen auswendig lernen konnte (und selbst das mit begrenztem Praxisbezug). Was in dieser Debatte untergeht: Scrum-Zertifikate waren mal anders gemeint und haben einen ganz anderen Sinn ergeben als heute.

Ein Blick zurück auf die Anfänge: 2002 wurde mit der Scrum Alliance die erste Zertifizierungs-Organisation gegründet, zuerst nur mit Scrum Master-Zertifizierungen, erst später mit immer weiteren. Zwei bedeutende Dinge waren in dieser Zeit anders als heute - zum einen war Scrum noch relativ unbekannt und wenig verbreitet, zum anderen befand sich das Internet noch in seiner Frühphase, in der viele der heute populären Dienste noch nicht oder nur in einer frühen Form existierten. Beides führte dazu, dass die frühen Anwender des neuen Frameworks noch stark voneinander isoliert waren.

Während heute jeder Interessierte eine immer grösser werdende Auswahl an Meetups und Unkonferenzen in seiner näheren Umgebung finden kann befand sich die Scrum-Community damals noch im Zustand einer Diaspora. Vereinzelt gab es schon erste User Groups (vor allem an der amerikanischen Ost- und Westküste), im grössten Teil der Welt waren die ersten Vorreiter aber noch auf sich gestellt. Der heute fast überall vor Ort mögliche Austausch mit Gleichgesinnten war nur in Verbindung mit Reisen und Konferenzteilnahmen möglich, was nicht für jeden organisierbar und finanzierbar war.

Auch Informationen aus dem Internet gab es spärlicher als heute. Selbst die heutigen sprichwörtlichen ersten Schritte waren noch nicht möglich. Die Wikipedia existierte erst ein Jahr und war noch hochgradig lückenhaft, bis zum ersten Artikel über Scrum (siehe hier) sollten noch Jahre vergehen. Hier war also keine Hilfe zu finden. Und auch das Betrachten eines Einführungsvideos auf Youtube war keine Option, diese Seite ging erst im 2005 online, also ebenfalls Jahre in der Zukunft. Einzelne Websites zu dem Thema gab es zwar, aufgrund der im Vergleich zu heute schlechteren Suchmaschinen waren sie aber nur mit Mühe zu finden.

Die Zertifizierungen (und vor allem die Zertifizierungskurse) haben daher in den ersten Jahren eine wichtige Lücke geschlossen. Durch sie war es erstmals möglich die eigene Scrum-Umsetzung mit der offiziellen Version abzugleichen, Good Practices kennenzulernen und sich mit anderen Anwendern auszutauschen. Dass es dazu noch ein buntes Stück Papier gab war eine schöne Zugabe, von grösserer Bedeutung waren aber die beiden Tage davor, die Einblicke bieten konnten die sonst nur schwer zu haben gewesen wären. So war es damals.

Zurück in die Gegenwart: Heute gibt es all das was es früher nicht gab. Es gibt Meetups und User Groups in der eigenen Umgebung, auf denen man sich mit Menschen jeder Erfahrungsstufe austauschen kann. Es gibt online mehr kostenlose Artikel als man im gesamten Leben lesen könnte und mehr Videos als man in Jahren sehen könnte. Es gibt Inhouse Communities in grossen Firmen, es gibt Podcasts, kollegiale Fallberatungen und vieles mehr. Und wer auch nur einen kleinen Teil seiner Zeit hier investiert kan viel, viel mehr lernen als in jeder Zertifizierung.

Darum zum Fazit: es gab mal eine Zeit in der die Scrum-Zertifikate viel Sinn gemacht haben, aber die ist weitgehend vorbei.

Montag, 15. April 2019

Deine Muda: Overprocessing

FS
Bild: Pixabay / Geisteskerker - CC0 1.0
Siebter Teil der Deine Muda-Serie. Die sechste Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Überregulierung, auf englisch Overprocessing. Diese Muda ist etwas Besonderes: während die ersten fünf (Transportation, Inventory, Motion, Waiting und Overproduction) die zeitweise Untätigkeit, bzw. Nicht-Nutzung von Personen und Gütern zum Inhalt haben verhält es sich hier anders. Es herrscht eine hohe Auslastung, nur eben keine sinnvolle.

Die meisten Angestellten kennen es - ein Grossteil ihres Arbeitstages besteht aus Tätigkeiten die nicht zur Wertschöpfung beitragen sondern die Befolgung von Dokumentations-, Beantragungs- oder Arbeitsvorschriften sind. Sind die Empfänger einer Mail nach Hierarchie geordnet? Wurde für den Antrag das vorgeschriebene gelbe Formular verwendet und nicht das blaue? Waren alle Mitarbeiter in der Anwendungsunterweisung für die neuen Bürostühle?

Die offensichtlichte Folge einer derartigen Überregulierung sind steigende Kosten. Die für die Befolgung und Umsetzung der Vorschriften nötige Zeit ist Arbeitszeit die dann an anderer Stelle fehlt. Die ursprüngliche Intention kann sich so in ihr Gegenteil verkehren. Statt alles effizienter und billiger zu machen (das ist nämlich die Absicht der meisten Prozesse) wird alles langsamer und damit teurer. Und auch das lässt sich noch steigern: wenn ganze Stellen geschaffen werden die nichts anderes machen als Prozesseinhaltung zu überwachen. Auch die kosten Geld.

Ein weiterer Effekt von Überregulierung kann sein, dass nicht nur Zusatzaufwand entsteht sondern bestehende Prozesse sich verschlechtern, etwa wenn durch den Versuch Menschen besser auszulasten Staus entstehen. Hinter diesem Phänomen steckt meistens das Gesetz der Penetranz der negativen Reste: um die letzten Effizienzreserven zu heben werden Regulierungen eingeführt die für diesen Zweck unverhältnismässig kompliziert sind - und statt zu Verbesserungen kommt es zu Verschlechterungen.

Weitgehend unberücksichtigt kommt noch ein dritter Faktor dazu: eine starke Regulierung des Arbeitsalltags kann schnell dazu führen, dass nicht mehr offensichtlich ist an welche Vorschriften man sich jetzt halten muss. Ist bei der Beantwortung einer Beschwerde nur der Leitfaden für Kundenkontakt zu beachten oder auch der für lösungszentrierte Kommunikation und der für revisionssichere Fach-Dokumentation? Derartige Unklarkeiten führen schnell in Regel-Aversion und informelle Strukturen, beides mit Effektivitätsverlusten als Folge.

Aus diesen Gründen ist es empfehlenswert die vorgegebenen Prozesse und Regulierungen möglichst gering zu halten und regelmässig zu überprüfen ob die bestehenden sich nicht abschaffen lassen. Im letzten Fall wichtig: abschaffen, nicht durch andere ersetzen. Sonst ist nicht viel gewonnen.

Donnerstag, 11. April 2019

Kontinuierliches Experimentieren (Popcorn Flow)

FS
Dass ich grosser Fan von kontrollierten Experimenten bin hatte ich schon geschrieben. Wie man diese nachhalten und verstetigen kann ist von Team zu Team anders, aber eine mögliche Variante ist der PopcornFlow von Claudio Perrone. Hier von ihm selbst erklärt:



Und: hier befindet sich die dazugehörige Präsentation.

Montag, 8. April 2019

Replenishment (Just in Time-Delivery)

FS
Bild: Flickr / Lyza Danger - CC BY-SA 2.0
Für viele Kanban-Anwender in der IT oder anderen Bereichen der Wissensarbeit ist es in Vergessenheit geraten, aber dieses Framework hat ursprünglich einen sehr handfesten Hintergrund. In den ersten Jahrzehnten seiner Existenz wurden nicht Kreativarbeit oder Dienstleistungen damit gesteuert sondern Fabrikarbeit. Ein besonderer Aspekt war dabei die Organisation von Materialnachschub über so genannte Replenishments. Da es die in der Wissensarbeit auch gibt lohnt ein näherer Blick.

Die Grundidee der Kanban-Replenishments ist die Lieferung möglichst genau zum benötigten Zeitpunkt, also weder zu früh noch zu spät. Da das durch zentrale Steuerung kaum machbar wäre (alleine das dafür nötige Detail-Reporting wäre immens) erfolgt die Koordination dezentral. Wann immer der Vorat eines Werkstoffs eine Mindestmenge unterschreitet wird eine gemeinsam mit diesem Werkstoff aufbewahrte Kanban-Karte entnommen und an denjenigen weitergegeben der für die Bestellung zuständig ist. Da die Mindestmenge auf Verbrauch und Lieferzeit abgestimmt ist erfolgt die Lieferung kurz bevor der Vorrat erschöpft ist.

Der Vorteil dieser so genannten Just in Time Delivery: die Lagerhaltung wird deutlich verringert. Statt vorsichthalber grössere Mengen vorhalten zu müssen ist möglich, dass nur relativ kleine Vorräte angelegt werden. Die mit Lagerhaltungen verbundenen Nachteile (Totes Kapital, benötigte und instandzuhaltende Räumlichkeiten, Veraltung und Beschädigung der Waren, etc.) werden so minimiert. Die im Vergleich zu Europa und Amerika zeitweise erheblich billigere Produktion in Japan ist so zu erklären. Soviel zur Hardware. Aber ist das auch in der Wissensarbeit umsetzbar?

Es ist umsetzbar, wenn auch mit anderen Objekten. Werkstoffe werden in den IT- und Dienstleistungsbrachen praktisch nie zugeliefert, dafür kommt aber etwas anderes in ununterbrochener Regelmässigkeit nach: Anforderungen. Auch bei denen treten negative Effekte auf wenn sie in zu grosser Zahl gleichzeitig eintreffen - sie brauchen länger bis zur Umsetzung, veralten, ihr Kontext ändert sich, Schnittstellen ändern sich, und so weiter. Auch hier kann eine Just in Time Delivery daher Mehrwert stiften.

Natürlich ändert das die Art wie Anforderungen geschrieben werden müssen. Statt möglichst alles zu Beginn auszuspezifizieren muss jetzt mit den Detail-Beschreibungen so lange wie möglich gewartet werden, damit diese Arbeit nicht zu früh fertig wird. Das hat Auswirkungen auf die Organisation: statt einer vorgelagerten Phase ist das Erheben der Anforderungen jetzt ein parallel zur Umsetzung verlaufender Prozess. Und damit trotz allem zielgerichtet gearbeitet wird braucht es Dinge die leider nur wenige Unternehmen haben: eine Produktvision und fachliche Zwischen- bzw. Sprintziele.

Viele Organisationen scheuen diese Umstellung und gehen den scheinbar leichten Weg - vor dem Kanban-System befindet sich ein Backlog mit möglichst vielen, möglichst früh geschriebenen, möglichst detaillierten Anforderungen. Den dafür Verantwortlichen sei ein Besuch in der nächsten nach Kanban arbeitenden Fabrik empfohlen, um dort zu erfahren wie diese Arbeitsweise eigentlich gedacht ist.

Donnerstag, 4. April 2019

Broken Window (II)

FS
Bild: Pixabay / Jeimo - CC0 1.0
Der Broken Window-Effekt, bzw. die Broken-Window-Theorie gehört zu den Klassikern der Kriminologie und Sozialforschung. Sie gehen davon aus, dass die sichtbare Beschädigung eines Objekts (zum Beispiel in Form einer eingeschlagenen Autoscheibe) die Hemmschwelle für weitere Beschädigungen senkt. Findet keine Reparatur statt wird es mit grosser Wahrscheinlichkeit zu weiteren Schäden in der näheren Umgebung kommen, bis hin zum Niedergang ganzer Stadtteile.

Die Übertragbarkeit dieses Effekts, bzw. dieser Theorie auf Transitionsvorhaben ist naheliegend, auch in diesem Fall können erste Verfallserscheinungen mittelfristig zum Scheitern ganzer Change-Vorhaben führen. Darüber hinaus lassen sie sich im Fall agiler Methodeneinführungen aber auch im unmittelbaren Sinn anwenden - dann nämlich wenn es zur Beschädigung oder Verwahrlosung physischer Objekte kommt.

Den agilen Ansätzen kann in diesem Zusammenhang zum Verhängnis werden, dass mit ihnen in der Regel eine intensive Nutzung von an die Wand gehängten "Information Radiators" einhergeht. Kanban-Boards, Product Backlogs, Impediment Backlogs, Personas, Burndown Charts, Roadmaps und viele weitere Fortschrittsindikatoren gehören zum alltäglichen Erscheinungsbild der Arbeitsräume agiler Teams. An ihnen werden Unstimmigkeiten schnell offensichtlich.

Meistens beginnt der Verfall verhältnismässig unspektakulär. In einer Stressphase werden Sprint Backlog und Burndown-Chart nicht aktualisiert, in einem Offsite gesammelte Anforderungen werden nicht sofort nach der Rückkehr an die Wand übertragen, die nicht mehr zur neuen Firmenstrategie passenden Personas bleiben wegen ihrer dekorativen Wirkung hängen, etc. Nach und nach baut sich eine Bugwelle an notwendigen Aktualisierungen auf.

In Summe wird die aufzuholende Arbeit immer mehr, Prokrastination beginnt und setzt sich fest, auf weitere Verschlechterungen "kommt es jetzt auch nicht mehr an", so dass sie bewusst toleriert werden. Vor allem wenn der letzte Punkt erreicht ist, ist der Broken Window-Effekt in vollem Gang. Im harmloseren Fall wird die Arbeit jetzt durch ein schlecht koordiniertes Miteinander digitaler und physischer Tools koordiniert, im schlechtesten Fall findet sie nur noch auf Zuruf statt.

Im Gesamtbild ergeben die vielen vernachlässigten und veralteten Objekte zusammen mit den immer schlechter laufenden Prozessen irgendwann ein immer negativer werdendes Bild. Den Betrachtern kommen problematische Assoziationen in den Sinn: Ungepflegtheit, Vernachlässigung, Verwahrlosung. Früher oder später reift dann im Management die Überzeugung, dass die Mitarbeiter mit selbstorganisiertem Arbeiten überfordert sind und wieder "Führung" brauchen. Die Transition scheitert.

Will man es nicht bis zu diesem Punkt kommen lassen ist es sinnvoll und notwendig schon auf erste Zeichen des Broken Window-Effekts zu reagieren. Wann immer Information Radiators veralten muss allen Beteiligten ins Gedächtnis gerufen werden, dass es sich bei ihnen um ein Spiegelbild des Teamszustandes handelt. Alle (nicht nur der Scrum Master!) müssen daran arbeiten sie durchgehend aktuell und aussagekräftig zu halten, und zwar nicht nur für das Management sondern auch im eigenen Interesse.

Zuletzt noch ein Punkt der häufig in diesem Zusammenhang thematisiert wird: ein Umstieg von physischen auf digitale Tools würde hier Nichts besser machen - die Probleme würden nur weniger offensichtlich werden und sich länger hinziehen.

Montag, 1. April 2019

Kommentierte Links (XXXXVII)

FS
  • Dave Nicolette: Maximizing the Amount of Work Not Done

    Es ist eine der Passagen des Manifests für agile Softwareentwicklung die mehr Beachtung verdienen: Einfachheit - die Kunst die Menge nicht getaner Arbeit zu maximieren - ist von besonderer Wichtigkeit. Was das bedeutet ist nicht näher definiert, so dass es verschiedene Möglichkeiten der Umsetzung gibt.  Die hier vorgestellte ist aus dem Lean Management abgeleitet, wenn auch mit einem Twist: statt in einer negativen Definition die zu vermeidenden Mudas aufzuzählen wird eine positive Herleitung versucht - Einfachheit ist die Focussierung auf lediglich die Tätigkeiten die unmittelbaren Kundennutzen erzeugen, und deren Abarbeitung in einem Pull-orientierten Arbeitsfluss. Ein Ansatz der gut geeignet für Prozessoptimierungen jeglicher Art ist.

  • Klaus Leopold: Es war einmal ein Flight Level

  • An sich ist Kanban alleine darum wunderbar als Framework für agiles Arbeiten geeignet weil es "Open Source" ist. Jeder kann und darf es anpassen wie es passend und notwendig erscheint. Dass ausgerechnet unter den Kanban-Praktikern (vor allem denen die von der Lean Kanban University zertifiziert sind) in den letzten Jahren ein zunehmender Dogmatismus zu erkennen ist ("Das ist nicht Kanban, das ist nur die Visualisierung von Arbeit") ist demnach schade bis ironisch zu betrachten. Im Fall der von Klaus Leopold eingeführten Flight Level hat das zu einer Entkoppelung geführt - dadurch dass nicht mehr von Kanban Flight Leveln gesprochen wird lassen sich Methodendiskussionen vermeiden. Für diesen Fall eine gute Lösung, die im grossen Zusammenhang aber ein Risiko birgt - sollte an weiteren Stellen Vergleichbares passieren könnte sich Kanban irgendwann von der Praxis entkoppeln und in einen Elfenbeinturm zurückziehen.

  • Ron Jeffries: Three-C's Revisited

    Dass nahezu alle Vordenker der verschiedenen agilen Vorgehensmodelle noch am Leben (und sehr meinungsfreudig) sind hat einen grossen Vorteil: wann immer jemand versucht die ursprünglichen Ideen umzudeuten oder zu verfälschen riskiert er korrigiert und blossgestellt zu werden. In diesem Fall handelt es sich bei den Blossgestellten um die Beratungsfirma SolutionsIQ, deren Ansatz zur Standardisierung von User Stories von deren Erfinder seziert wird (siehe auch hier). Er stellt klar, dass eine derartige Vereinheitlichung weder gewollt noch sinnvoll ist. Dass Ron Jeffries sich derartig klar äussert kann man nur dankend annehmen, und man kann nur hoffen, dass er dass noch lange tun kann. Immerhin ist der Mann mittlerweile 80 Jahre alt.

  • Andrew Higgins: How Powerful Is Vladimir Putin Really?

    Ein scheinbar abseitiges Thema. Dass dieser Artikel über die russische Innenpolitik hier verlinkt wird hat aber einen Grund: es geht um die Demystifizierung der Idee des "starken Führers" anhand eines ihrer scheinbar prominentesten Beispiele. Anders als oft angenommen scheint es sich bei Russland nicht um eine "gut geführte Diktatur" zu handeln sondern um ein System in dem zunehmender Kontrollverlust herrscht. Statt den Befehlen von oben zu gehorchen entwickeln die unteren Hierarchiestufen ein Eigenleben, und da das an zu vielen Stellen gleichzeitig geschieht kann die Regierungszentrale das nur noch in Einzelfällen unter Kontrolle bekommen. Ein gutes Anschauungsbeispiel für alle die glauben, grosse Organisationen liessen sich von oben führen.

  • Michael Küsters: Your Sprint Reviews suck, and that's why!

    Zu diesem Thema hatte ich auch schon etwas geschrieben, aber natürlich noch nicht abschliessend. Michael Küsters fügt weitere wichtige Punkte hinzu. Man könnte sicher noch weitere auflisten, man kann es aber auch kurz machen: Sprint Reviews sollten unbürokratisch und handlungsorientiert auf den Punkt bringen welcher Mehrwert, bzw. Kundennutzen erzeugt wurde. Dann sind sie gut.

Donnerstag, 28. März 2019

Warum Teams nicht agil arbeiten wollen

FS
Bild: Pixabay / Niek Verlaan - CC0 1.0
Manchmal ist es merkwürdig. Da will man Gutes tun für seine Mitarbeiter, zusammen mit ihnen in die neue Arbeitswelt aufbrechen, Selbstorganisation fördern, Verantwortung delegieren und Altes hinter sich lassen - und was zurück kommt sind Unverständnis, Undank und Ablehnung. Wie kann das sein, wie haben wir das verdient? Haben wir es überhaupt verdient? Die harte Antwort: Mit hoher Wahrscheinlichkeit ja. Es gibt gute Gründe für eine Ablehnung einer agilen Transformation. Hier sind einige der häufigsten:

Für die Lösung (Agilität) gibt es kein Problem

Im Grunde ist es methodenunabhängig eine Selbstverständlichkeit: bevor irgendetwas Neues eingeführt wird sollte man sich immer fragen welches Problem damit gelöst werden soll. In der Realität kommt diese Frage aber erschreckend oft nicht vor. Agilität wird eingeführt weil es gerade modern ist, weil alle es machen, weil es vom Chef befohlen wurde, etc. Dass der Ist-Zustand ausreichend sein könnte wird nicht bedacht oder bewusst ignoriert. Wer kann es verdenken wenn davon keiner begeistert ist?

Agilität ist die falsche Lösung

Ebenfalls erstaunlich häufig. Während agile Vorgehensweisen für innovationslastige, komplexe und änderungsanfällige Vorhaben gut geeignet sind passen sie in anderen Zusammenhängen eher weniger. Wenn es zum Beispiel darum geht einen Fertigungsprozess effizienter zu machen oder in einem stabilen Umfeld einen komplizierten aber gleich bleibenden Plan umzusetzen sollten auch andere Ansätze in Betracht gezogen werden. Und bei einfachen Vorhaben kann ggf. auf jegliche Methodik verzichtet werden. Wenn trotzdem aus Prinzip alles agil sein muss ist Skepsis verständlich.

Die Beteiligten wurden nicht gefragt

Der vermutlich schlechteste Weg zur Einführung von selbstorganisierten Teams ist ein Befehl von oben. Dass Agilität nur funktioniert wenn sich die Beteiligten auf allen Ebenen freiwillig einbringen sollte ein Allgemeinplatz sein, oft ist er es nicht. Wenn Einwände und Fragen dann abgebügelt oder mit fehlendem Verständnis erklärt werden braucht man sich über Ablehnung und Widerstand nicht zu wundern. Oft wird in solchen Situationen noch versucht "die Mitarbeiter mitzunehmen", "das eigene Vorgehen besser zu erklären" oder "die Menschen zu ihrem Glück zu zwingen." Erfolgreich ist das selten.

Das Framework ist nicht das Richtige

Selbst wenn Agilität die richtige Lösung für ein existierendes Problem sein sollte und das Vorgehen von den Mitarbeitern mitgetragen wird kann die Wahl des Frameworks Probleme aufwerfen. Extreme Programming passt gut zu Anwendungsentwicklung aber schlecht zu Operations, Scrum macht in regelmässigen Umsetzungszyklen mehr Sinn als in anlassgetriebenem Arbeiten, Lean Startup funktioniert in Startups (Überraschung), kann aber in grossen Organisationen zu Schwierigkeiten führen. Ein falscher Umsetzungsweg kann aus diesen Gründen schnell für wenig Akzeptanz sorgen.

Die Umsetzung ist zu esoterisch

Auch das kommt immer wieder vor. In jeder Arbeitsumgebung sollten spielerische und kreativitätsfördernde Elemente nur so lange eingesetzt werden wie sie das Gefühl von Professionalität nicht beeinträchtigen. Bunte Post-Its an die Wand hängen, in Retrospektiven Bilder malen, Bällebäder aufstellen oder Räumen lustige Namen geben kann hilfreich sein wenn Teams es wollen, wenn sie sich damit unwohl fühlen sollte man es lassen. Und wenn all das als zwingend notwendiger Erfolgsfaktor beschrieben wird werden zurecht Sinnfragen gestellt werden. Es würde nämlich auch ohne all das gehen.

Wirkliche Veränderungen sind unerwünscht

Im Grunde gehört dieser Punkt nicht in diese Liste, denn wer Veränderungen nicht will, der will auch keine Agilität. Dass trotzdem immer wieder genau das vorkommt liegt an dem Irrglauben, dass Agilität sich in abgekapselten Bereichen umsetzen liesse, ohne dass die umgebende Organisation sich ändern muss. Das wird von den Betroffenen relativ schnell als das durchschaut was es ist - als schwere Dysfunktion. Und von der will niemand ein Teil sein.

Montag, 25. März 2019

Break your Industry Standards

FS
Immer das Gleiche zu tun wie alle anderen ist auf dauer nicht zielführend. Gesagt haben das schon viele, aber die meisten nicht so unterhaltsam wie Paul Rulkens.

Donnerstag, 21. März 2019

Agiles Change Management (II)

FS
Bild: Max Pixel - CC0 1.0
Agiles Change Management ist anders als klassisches, und das in verschiedener Hinsicht. Schon dass es Veränderungen nicht schnell hinter sich bringen sondern dauerhaft erhalten will ist ein Paradigmenwechsel (mehr dazu hier), aber auch die Art wie der Wandel gestaltet werden soll ist neu und anders.

Um den Unterschied zu erkennen zunächst ein Blick auf das klassische Vorgehen: bei den Change-Vorhaben der Vergangenheit handelte es sich in der Regel um grosse, schwerfällige Programme. Von langer Hand geplant, von zahlreichen Gremien abgenickt, mit festen Meilensteinen versehen und von Top Down-Befehlsketten begleitet stellen sie in vieler Hinsicht Musterbeispiele für klassisches Projektmanagement dar.

Auch die flankierende Kommunikation mit den Betroffenen folgt in den meisten Fällen dem "bewährten Muster". In der Theorie wird zwar Feedback eingeholt, in der Realität wird dieses aber durch passende Fragestellungen in eine "konstruktive Richtung" gelenkt. Und wenn wirklich Unzufriedenheit ermittelt wird dann nicht um den Kurs anzupassen sondern um festzustellen wo man das bisherige Vorgehen "besser erklären" und "Mitarbeiter mitnehmen" muss.

In einem agilen Change Management ist das Vorgehen ein anderes. Genau wie in der agilen Produktentwicklung werden auch hier in kleinen Schritten überschaubare Änderungen durchgeführt und deren Wirkungsgrad und Akzeptanz schnellstmöglich gemessen. Entspricht das Ergebnis nicht den Erwartungen wird der Plan überprüft und ggf. angepasst, um schnellstmöglich die nächste überschaubare Änderung validieren zu können.

Da die Angemessenheit und Wirksamkeit der Massnahmen nicht im voraus beschlossen sondern in kurzen Abständen validiert werden sind auch Planung und Durchführung zwangsläufig variabler, schlanker und leichtgewichtiger - nur so können sie im Zweifel mit vertretbarem Aufwand angepasst werden. Auch das hat Folgen: weniger Gremienbeschlüsse, weniger Planziele, mehr Ergebnisoffenheit und mehr Experiemtierbereitschaft.

Grundlegend anders muss in diesem Zusammenhang auch kommuniziert werden. Statt lediglich fertige, unumstössliche Beschlüsse zu bewerben sollte die Forderung und Förderung von (explizit auch kritischem) Feedback im Mittelpunkt stehen. Und nicht nur das, Immer wieder muss herausgestrichen werden wo dieses Feedback zu Kursanpassungen geführt hat. Nur so kann sichergestellt werden, dass diese permanente Validierung weitergeht und zur kontinuierlichen Verbesserung beiträgt.

Natürlich bedeutet ein solches Vorgehen, dass Veränderungen nicht mehr langfristig im Detail geplant und planmässig umgesetzt werden können. Die Wahrheit ist aber auch, dass das bereits vorher nicht mehr möglich gewesen ist. Man hat in den meisten Fällen lediglich so getan als ob, dann aber am Bedarf vorbeigearbeitet. Dann doch lieber Inspect & Adapt.

Montag, 18. März 2019

Die sechs (nicht fünf) Phasen einer Retrospektive

FS
Bild: Pixabay / Inspired Images - CC0 1.0
Beim Neuaufsetzen eines Scrum-, Kanban- oder XP-Teams ist es eine der immer wiederkehrenden Fragen: wie werden die Retrospektiven, KVP-Meetings oder Kaizen-Events aufgesetzt in denen das bisherige Vorgehen unter die Lupe genommen, hinterfragt und gegebenenfalls angepasst wird? Vor allem im Fall von Teams in denen der neue Scrum Master (bzw. der Facilitator, Flow Manager, etc.) selbst keine Erfahrungen in der Rolle hat kann es helfen diese Frage zu beantworten indem am Anfang auf eine bewährte Struktur zurückgegriffen wird.

Gute Erfahrungen gibt es vor allem mit einem Phasen-Modell, in dessen Rahmen in verschiedenen Arbeitsschritten verschiedene Tätigkeiten ausgeübt werden. häufig werden in diesem Zusammenhang fünf derartige Phasen genannt, zu empfehlen sind aber eine mehr, also sechs. Welche davon häufig vergessen wird wird später in diesem Text noch beleuchtet, zuerst geht es aber darum die ersten fünf kurz zu erklären. Es sind: Setting the stage, Gathering data, Generating insights, Deciding what to do, Closing (zahlreiche Beispiele für diese Phasen finden sich auf Retromat.org).

Setting the stage könnte man auch als Einleitung oder Ankommen bezeichnen. In der einfachsten Form kann das nur die Abfrage sein mit welcher Stimmung die Teilnehmer in das Meeting gehen, in komplexeren Settings kann schon ein thematischer Schwerpunkt gefunden oder ein Ventil für Frust und Freude geschaffen werden. Ein nicht zu unterschätzender sekundärer Effekt sollte es sein, symbolisch eine Unterbrechung des Arbeitsalltags vorzunehmen.

Gathering data ist als zweite Phase praktisch selbsterklärend - es geht darum die Datenbasis für das weitere Vorgehen zu schaffen. Sehr häufig ist die Unterteilung der Wand in Sektionen (z.B. start doing, keep doing, stop doing), verbunden mit der Aufforderung entsprechende Themen auf Post-Its daranzuhängen. Andere Durchführungen können Brainstormings sein, Design Thinking-Events oder Self Assessments.

Generating insights besteht fast ausschliesslich aus der Diskussion der vorher gesammelten Themen, ob in Gruppen, als Lean Coffee, Fishbowl oder in anderen Formaten. Vorgeschaltet ist oft ein Clustern zusammenhängender Themengebiete und eine Priorisierung der Themen, bzw. Themencluster. Gegebenenfalls kann es hier schon starkte Überlappungen mit der nächsten Phase geben, in der aus den Diskussionen Massnahmen abgeleitet werden.

Deciding what to do ist genau das, das Erarbeiten von Massnahmen. Welche das sind ist natürlich hochgradig Einzelfallabhängig, es gibt aber Kriterien, die bei der Formulierung hilfreich sein können: die Massnahmen sollten in nächster Zeit umsetzbar sein, sie sollten vom Team selbst umgesetzt werden können und sie sollten validierbar sein, es muss sich also überprüfen lassen ob sie erfolgreich waren.

Closing bildet gewissermassen zusammen mit dem Setting the Stage die Klammer um die Retrospektive. Auch hier wäre eine Stimmungsabfrage die einfachste Form, es ist aber auch eine "Retrospektive der Retrospektive" möglich um zu bewerten wie gut das Meeting gelaufen ist. Eine andere Form wäre das Einstimmen auf bevorstehende Herausforderungen.

Soweit die weit verbreiteten fünf Phasen. Dass die sechste relativ selten ist, ist an sich bereits bezeichnend, es handelt sich nämlich um das Inspecting the last retro's action Items, also um das Überprüfen der beim letzten mal beschlossenen Massnahmen auf Erfolg. Wie wenn nicht so soll ein Inspect and Adapt stattfinden? Und sinnigerweise sollte das auch relativ früh stattfinden. Ein zu empfehlender Ablauf einer Retrospektive wäre demnach:

Setting the stage, Inspecting last retro's action Items, Gathering data, Generating insights, Deciding what to do, Closing

Donnerstag, 14. März 2019

Deine Muda: Overproduction

FS
Bild: Flickr / Jordi Bernabeu Farrús - CC BY 2.0
Sechster Teil der Deine Muda-Serie. Die fünfte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Überproduktion, auf englisch Overproduction. Wie bei der Lagerhaltung ist es auch hier auf den ersten Blick etwas was in Hardware und Software ähnlich erscheint, während sich auf den zweiten Blick Unterschiede zeigen.

In Bezug auf die Gemeinsamkeiten von Hardware- und Softwareproduktion gibt es zunächst eine große Überschneidung mit der gerade erwähnten Lagerhaltung. Zuviel produzierte Güter können nicht schnell genug verkauft werden und müssen gelagert werden. Da die Produktion bereits bezahlt ist, die Verkaufserlöse aber noch nicht eingegangen sind, binden die Produkte in diesem Zustand Geld, sind also totes Kapital.

Gleichzeitig bindet die Überproduktion Menschen und Maschinen die an anderer Stelle fehlen, wodurch sich dort die Arbeitsfortschritte verzögern. Im schlimmsten Fall kommt es sogar zu zusätzlichen (und eigentlich unnötigen) Neueinstellungen und Neuanschaffungen, durch die es zu einer dauerhaften Zunahme von Lohn- und Instandhaltungskosten kommt, ohne dass diese durch Gewinne refinanziert werden.

Zusätzlich zu diesen Faktoren kommt es zu Verschleisserscheinungen, und zwar sowohl bei Maschinen als auch bei Menschen. Während die ersten sich durch Gebrauch abnutzen tritt bei den Mitarbeiter nicht nur physischer sondern auch psychischer Verschleiss auf. Die Erkenntnis am Markt vorbeizuproduzieren kann deprimmierend sein und sich negativ auf Arbeitsmoral, Engagement und Sorgfalt auswirken.

Softwarespezifisch kommt ein weiterer Faktor dazu, nämlich die unnötige Aufblähung der Code Base und des Funktionsumfangs. Diese sorgen zunächst für gesteigerte Kosten bei Wartung und Instandhaltung, langfristig aber auch für erhebliche Mehraufwände in der Weiterentwicklung, da mit dem Umfang auch die Menge der nötigen Integrations- und Regressionstests, des Bugfixings und des Refactorings steigt.

Zur Behebung dieser Misstände reicht es daher in der Software (anders als im Fall der Hardware) nicht aus einfach die Produktion zu drosseln. Darüber hinaus ist auch ein Rückbau der bereits implementierten Feature-Überproduktion nötig um die negativen Effekte abzustellen. Man zahlt also doppelt, einmal für die Überproduktion selbst, einmal für den Rückbau. Ein Grund mehr, damit gar nicht erst anzufangen.

Montag, 11. März 2019

Scrum-Zertifiziert - und ratlos wie Scrum funktioniert

FS
Bild: Pexels / Bruce Mars - CC0 1.0
Zertifizierungen sind ein grosses Thema. In der Wirtschaft im allgemeinen, in der IT im Speziellen, im agilen Kontext im ganz Speziellen und vor allem im Umfeld von Scrum. Alleine die grössten beiden Organisationen, die Scrum Alliance und Scrum.org haben weltweit mehr als 500.000 Zertifikate für Scrum Master und Product Owner vergeben, dazu kommt eine unklare Nummer von anderen Anbietern wie Scaledagile Inc. (SAFe) oder als deutschem Kuriosum dem TÜV.

Viel Expertise, sollte man denken. So viele Menschen mit bestandenen Prüfungen und (bei einigen Anbietern) regelmässigen Re-Zertifizierungen sollten eine gute Grundlage bilden, basierend auf der viele Unternehmen gekonnt an die Implementierung von Scrum gehen können. Denn wer so ein Zertifikat sein Eigen nennt hat bewiesen, dass er weiss wie man dieses Framework ein- und durchführt - richtig? Nun, leider nein.

Irritierenderweise ist keine der gängigen Zertifizierungen ausreichend um auf die Arbeit in oder mit Scrum vorzubereiten. Nicht nur weil sie lediglich Theorie vermitteln (obwohl schon das ein gewichtiger Punkt ist). Viel wichtiger ist aber ein zweiter: selbst das in den Zertifizierungskursen vermittelte und in den Prüfungen unter Beweis gestellte Wissen bildet nicht vollständig ab was nötig ist um später damit zu arbeiten. Selbst wer es vollständig verinnerlicht hat wird meistens an der Umsetzung scheitern, solange er nicht in grossem Umfang nicht prüfungsrelevanten Stoff verinnerlicht hat.

Dieser hochgradig irritierende Zustand der "zertifizierten Praxisuntauglichkeit" ist kein Zufall. Er ergibt sich zwangsläufig aus dem Zusammenspiel zweier Faktoren. Zum einen aus der Framework-Natur von Scrum und zum anderen aus der (schon vor Scrum existierenden) grundsätzlichen Arbeitsweise der Schulungsindustrie, an die die Zertifizierungsorganisationen die vorbereitenden Kurse ausgelagert haben.

Werfen wir zunächst einen Blick auf den Framework-Charakter. Mit voller Absicht erwähnt der Scrum Guide (das offizielle Regelwerk) zentrale Punkte nicht. Nirgendwo in ihm wird erwähnt wie Abnahmen stattfinden oder warum (und dass) paktisch alle Scrum-Teams Boards benutzen, kein einziges mal geht er auf DoR und User Stories ein, etc. etc. Das bedeutet nicht, dass es unklar wäre wie damit umgegangen werden kann - im letzten Vierteljahrhundert haben sich zahlreiche Best Practices und Good Practices herausgebildet. Da diese in Einzelfällen nicht passend sein könnten stehen sie aber nicht im Scrum Guide. Kennen muss man sie trotzdem.

Als nächstes zur Arbeitsweise der Schulungsindustrie. Es ist nicht so, dass diese die Good Practices und Best Practices nicht vermitteln könnte - sie will es aber nicht. Der Grund dafür ist, dass die üblichen ein- oder zweitägigen Kurse gerade ausreichend sind um die Inhalte des Scrum Guides zu vermitteln. Die umgebenden Kontextinformationen ebenfalls aufzunehmen würde dazu führen, dass aus Tagen Wochen würden. Da das kaum ein Arbeitgeber finanzieren würde bleibt es bei den besser verkaufbaren Kurzveranstaltungen. Umsatz ist hier letztendlich wichtiger als umfassende Wissensvermittlung.1

In Kombination führen der Frameworkcharakter von Scrum und die Gewinnorientierung der Schulungsindustie zur oben genannten zertifizierten Praxisuntauglichkeit. Sie ist der Grund für das Scheitern zahlloser Scrum-Einführungen und agiler Transitionen, denn da zahlreiche Unternehmen die oben genannten Hintergründe nicht kennen glauben sie, dass mit dem Zertifikat alles nötige Wissen erworben wäre. Sobald die Lücken im Framework auffallen werden diese dann reflexhaft mit Versatzstücken des alten Vorgehens gefüllt, wodurch Agilität meistens unmöglich wird.

Um mit einer positiven Note zu enden - das alles heisst nicht, dass man sich nicht mit dem Scrum Guide beschäftigen sollte. Man kann und sollte es tun. Man kann sein Wissen sogar prüfen lassen wenn man das möchte. Man sollte diese Prüfung nur nicht mit einem "theoretischen Führerschein für Scrum" verwechseln. Das ist sie nicht und das kann sie in der gegenwärtigen Konstellation auch nicht sein.


1Verständlicherweise, schliesslich sind die Schulungsanbieter private Unternehmen und müssen ihr Einkommen erwirtschaften

Freitag, 8. März 2019

Wann finden in agilen Teams Abnahmen statt?

FS
Bild: Pixabay / Tero Vesalainen - CC0 1.0
Zu den vielen Dingen die in den gängigen agilen Frameworks nicht geregelt werden gehören die Abnahmen eines fertigen Produktincrements. Dass sie stattfinden sollten ist naheliegend, zumindest so lange wie es einen Product Manager, Onsite Customer oder Product Owner gibt, der die Anforderung ursprünglich verfasst hat. Wann sie stattfinden soll ist weniger klar.

Was in vielen Teams stattfindet ist scheinbar naheliegend - eine Abnahme in den Review- oder Demonstrations-Meetings, die es nicht nur in Scrum gibt sondern überall dort wo Kunden, Auftraggebern oder Benutzern die Ergebnisse umgesetzter Anforderungen vorgeführt werden. Doch so naheliegend das auch erscheinen mag, eine gute Idee ist es nicht.

Zum einen ist eine Abnahme vor den Augen von Leuten ausserhalb des Teams eine zweischneidige Angelegenheit. Bestenfalls werden sie durch intern wichtige aber für Aussenstehende irrelevante Details gelangweilt (Wurden die Regressionstests aktualisiert? Entspricht die Schriftart dem Corporate Design? Etc.), schlimmstenfalls wird die Abnahme verweigert und sie haben sich umsonst in das Meeting begeben.

Zum anderen nimmt sich ein Team das Abnahmen zu einem so späten Zeitpunkt durchführt ohne Notwendigkeit selbst einen Teil der eigenen Flexibilität. Zur Verdeutlichung: wird ein Ergebnis erst am Ende eines Sprints oder Produktionsszyklus überprüft ist es im Regelfall zu spät um einen festgestellten Änderungsbedarf ohne Planänderungen umzusetzen. Der nächste Sprint, bzw. Zyklus steht ja unmittelbar bevor und muss kurzfristig noch die Nacharbeiten aufnehmen.

Eine bessere Vorgehensweise wäre eine Abnahme sofort nach der Fertigstellung der letzten Arbeit am jeweiligen Increment. Wenn dann unmittelbar eine Vorführung und Überprüfung stattfindet bleibt auch bei entdeckten Fehlern noch genug Zeit für Korrekturmassnahmen, so dass der Zeitplan eingehalten wird und im Review, bzw. Demo-Meeting der Focus da liegen kann wo er hingehört - beim Einsammeln und Diskutieren von Feedback zum fertigen Ergebnis.

Ein häufiger Hinweis an dieser Stelle ist übrigens, dass man Abnahmen doch nicht einfach irgendwann und ohne Meeting durchführen könnte, nur weil es da gerade passt. Die Antwort darauf: doch, das geht auch ohne offizielles Meeting, und ja, gerade dann wenn es passt ist der richtige Zeitpunkt. Ganz ehrlich - wann denn sonst?

Dienstag, 5. März 2019

A lot of what managers do shouldn't be done

FS
Wenn es um agile Vorzeigeunternehmen geht werden immer die gleichen Beispiele genannt: Google, Facebook, Amozon, Spotify. Eines der unbekannteren aber trotzdem hochinteressanten ist Semco aus Brasilien:



Dass das Video über 10 Jahre alt ist macht die Geschichte übrigens noch beeindruckender, denn nach allem was man hört hat sich diese Firma ihren Geist bis heute erhalten.

Donnerstag, 28. Februar 2019

Kommentierte Links (XXXXVI)

FS
  • 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

FS
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

FS
Bild: Pixabay / kalhh - CC0 1.0
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)

FS

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

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 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 blaue etc. Und noch eine weitere Information lässt sich durch farbliche Markierungen darstellen: wenn ein Arbeitsvorgang blockiert ist und nicht weitergehen kann, kann der Punkt Rot oder Rot umrandet sein.

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 oder einer Gesamtmenge von 10 Punkten) sollte eine Retrospektive stattfinden in der besprochen werden kann was die Ursache für die Umsetzungsdauer oder die Blockade war.

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 ein selbstorganisierter Verbesserungsprozess gehört.
Powered by Blogger.