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

Freitag, 15. Februar 2019

Being Agile is our favourite thing

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

Dienstag, 12. Februar 2019

Psychologische Sicherheit

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

Donnerstag, 7. Februar 2019

Objektpermanenz

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

Montag, 4. Februar 2019

Visual Facilitation

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

Donnerstag, 31. Januar 2019

Kommentierte Links (XXXXV)

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

Montag, 28. Januar 2019

Minimum viable Team

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

Donnerstag, 24. Januar 2019

Definition of Ready

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

Montag, 21. Januar 2019

Agile Governance (II)

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

Donnerstag, 17. Januar 2019

Stalemate-Machine

FS
Bild: Wikimedia Commons / US Army - CC0 1.0
Sucht man nach beispielhaften fehlgeschlagenen Grossvorhaben ist eines zwar nicht auf den ersten Blick naheliegend, in vieler Hinsicht aber gut geeignet: der verlorene Krieg der USA in Vietnam. Was nötig gewesen wäre um ihn zu gewinnen wird zwar für immer Spekulation bleiben, viele Faktoren die dazu beigetragen haben, dass er verloren wurde, kennt man aber. Um einen davon soll es hier gehen, die so genannte "Stalemate-Machine", sinngemäss übersetzt den "Stillstands-Generator".

Der Hintergrund dieses Phänomens war der steigende Unwille in der amerikanischen Bevölkerung und Regierung in diesen Krieg zu investieren. Aus Sorge um ihre Wiederwahl wollten die Regierungen der 60er und 70er Jahre nicht mit immer höheren Kosten an Leben und Geld in Verbindung gebracht werden. Ihr Ziel war es also diese Kosten möglichst gering zu halten. Die Kriegsführung wurde entsprechend angepasst.

So lange es irgendwie möglich war wurde die Beteiligung amerikanischer Einheiten gering gehalten, Auseinandersetzungen sollten in erster Linie von einheimischen Truppen ausgetragen werden. Erst wenn diese am Rand der Niederlage standen erfolgte ein Eingreifen der Amerikaner. Sobald die Situation dadurch wieder unter Kontrolle war zogen sie sich zurück, was ihren Gegnern die Neugruppierung ermöglichte.

Der Militär-Analyst und Whistleblower Daniel Ellsberg hat für diese Strategie den Begriff der Stalemate-Machine geprägt. Wegen der Möglichkeit bei drohenden Niederlagen einzugreifen konnte der Krieg nicht verloren werden, wegen der fehlenden Bereitschaft ohne drohende Niederlage grössere Operationen durchzuführen war er aber auch nicht zu gewinnen. Die Folge war ein "stillstehender Krieg" ohne Gewinner.

Die Parallelen zur Wirtschaft sind in vielen Unternehmen offensichtlich. Auch hier wird häufig der Punkt erreicht an dem ein Projekt oder Vorhaben so viel gekostet hat, dass weitere Ausgaben in Management-Runden nur schwer zu vermitteln sind. Es bekommt von da an nur noch überschaubare Beträge genehmigt, damit es aus den Bilanzen weniger heraussticht. Bedingt dadurch gerät es weiter in Verzug, was nur noch bei wichtigen Deadlines zu kurzfristigen Hau-Ruck aktionen führt, die schnell wieder vorbei sind.

Der grosse Vorteil im Vergleich zum Militär ist an dieser Stelle: man könnte ohne ethische Bedenken diesen Krisenmodus verlassen und eine angemessen moderate, dafür aber permanente Finanzierung sichern. Man müsste nur wollen. Noch besser wäre es, es gar nicht so weit kommen zu lassen und von Beginn an massvoll aber stetig zu investieren. Damit würde es gar nicht erst zum Stalemate kommen.

Montag, 14. Januar 2019

Backlog Konmari

FS
Bild: Pixabay / 123nurik123 - CC0 1.0
Wegen irgendeiner Fernsehsendung hört man gerade viel von einer Japanerin mit dem (Künstler?)Namen Marie Kondo. Bekannt geworden ist sie durch die von ihr entwickelte Konmari-Methode zum Aufräumen von Wohnungen und Garderoben, die mittlerweile aber auch für Büros, Werkstätten, Schreibtische, etc. angewandt wird. Das Ganze lässt sich aber noch weiter treiben - warum sollte man Konmari nicht auch für Product Backlogs anwenden? Auch die sind ja oft hoffnungslos überladen und zugemüllt.

Als ersten Schritt definiert Kono das Commitment. Dieses geht bei ihr über die engere Bedeutung des sich verpflichtet Fühlens hinaus und enthält auch einen Zeitplan. Es sollte ein Zieldatum geben bis zu dem die Aufräumarbeiten abgeschlossen sein müssen, es sollte Zwischenziele geben und es sollte einen oder mehrere Zeiträume geben die für diese Arbeit reserviert sind, z.B. jeden Werktag von 10 bis 11 bis zum Ende des Monats.

Als nächstes sollte Klarheit über das angestrebte Zielbild herrschen. Dazu sollte dieses in seinem Idealzustand beschrieben werden. Für ein Backlog bedeutet das: geordnet (z.B. nach Business Value, MVPs, Sprintzielen, oder Roadmap) und mit einer absteigend geringer werdenden Granularität. Basierend darauf lassen sich die Einträge später neuordnen, teilen oder zusammenlegen.

Das eigentliche Aufräumen beginnt dann mit dem Ausmisten. Orientiert am vorher verfassten Zielbild kann alles weg was nicht dazu passt. Für viele Teams dürfte das der schwerste Teil dieser Übung sein, gleichzeitig ist es auch der wichtigste. Ist die Gesamtmenge übersichtlicher geworden fällt das Sortieren leichter und geht schneller voran. Eine weitere Hilfe besteht darin, sich um Nostalgie und Emotionen weckende Anforderungen als letztes zu kümmern, um nicht abgelenkt zu werden.

Auch bei der Aufteilung der Arbeitsschritte empfiehlt Konmari ein anderes Vorgehen als das meistens anzutreffende. Statt sich von einem Ort zum nächsten vorzuarbeiten entsprechen die Arbeitsphasen verschiedenen Kategorien. Bezogen auf das Produktmanagement bedeutet das, dass nicht zuerst Jira, dann Salesforce und dann  HP-ALM abgearbeitet werden sondern z.B. erst toolübergreifend alle Innovationsvorhaben, dann die Servicetasks und dann die Bug-Tickets.

Während des Aufräumens sollte Ordnung unmittelbar entstehen. Statt neue Haufen zu bilden, die dann (hoffentlich) später sortiert werden sollte alles sofort an den (nach aktuellem Kenntnisstand) finalen Ort wandern. Um Agile-Buzzwords zu benutzen: jedes Aufräum-Incement sollte eine Definition of Done erfüllen und unmittelbaren Mehrwert stiften.

Über dem gesamten Prozess sollte im klassischen Konmari das Leitmotiv des Erzeugens von "Sparking Joy" stehen, also des Verstrahlens von Freude. Als Gegenstück im Produktmanagement würde sich das weit verbreitete "Delighting Customers" anbieten. Im Hinterkopf sollte demnach während des ganzen Aufräumvorganges stehen, dass das Endergebnis den höchstmöglichen Kundennutzen zum Ziel haben sollte.

In diesem Sinne - ab zum Aufräumen.


Nachtrag 04.02.:

Donnerstag, 10. Januar 2019

Keine Entschuldigungen im Review

FS
Bild: Pixabay / Geralt - CC0 1.0
Egal ob im Sprint Review, in einem Stakeholder-Meeting oder bei einer wie auch immer gearteten Ergebnispräsentation - jedes agil arbeitende Team sollte in regelmässigen Abständen seinen Kunden, Sponsoren und Auftraggebern Ergebnisse zeigen. Bestenfalls sollten in diesem oder in einem anderen Rahmen auch Zieldaten und Forecasts kommuniziert werden, um Umsatzplanungen, Kommunikationsstrategien und ähnliches möglich zu machen. Und da der Mensch als solcher nun mal fehlbar und die Realität nicht vorhersehbar ist werden nicht immer alle Ergebnisse zum angedachten Zeitpunkt fertig sein. Was jetzt?

Ein häufiges Verhalten vieler Teams ist es, in solchen Situationen umfangreiche Erklärungen und Begründungen abzugeben. Mitunter in erstaunlichem Detaillierungsgrad wird dargelegt warum man sich in den Aufwandsschätzungen vertan hat, wie es dazu kommen konnte, dass die Planungen zu optimistisch waren oder welche Faktoren dazu geführt haben, dass das ursprünglich realistische Ziel wider Erwarten doch nicht erreicht werden konnte.

Verbunden damit ist in der Regel guter Willen. Transparenz ist bekanntlich einer der Grundprinzipien agilen Arbeitens, es ist also scheinbar nur folgerichtig sie auch in diesem Fall anzuwenden und für jeden nachvollziehbar zu machen warum alles so gekommen ist wie es ist. Zielführend ist dieses Vorgehen allerdings nur selten. Häufiger führt es zu Befremdung und Skepsis bei den Zuhörern, also zum Gegenteil des eigentlich erhofften Ergebnisses.

Zunächst wirken Erklärungen und Begründungen schnell wie Ausreden und Fingerpointing, und zwar auch dann wenn sie explizit nicht so gemeint sind. "Wir wollten ja, aber ..." hinterlässt selten einen guten Eindruck, erst recht nicht wenn es mehrfach geschieht. Und dass es immer wieder geschehen wird ist unvermeidbar, siehe menschliche Fehlbarkeit und Unvorhersehbarkeit der Realität. Besser sind Aussagen wie "Wir sind nicht ganz fertig geworden, arbeiten aber weiter daran." oder "Dieser Lösungs-Ansatz war leider der falsche, basierend auf dem was wir daraus gelernt haben arbeiten wir jetzt an einem besseren."

Des Weiteren sind derartige Themen für die meisten Kunden, Sponsoren und Auftraggeber schlicht uninteressant. Negative (und übrigens auch positive) Implementierungsdetails sind nicht der Grund dafür, dass man sich mit einem Umsetzungsteam trifft. Normalerweise kommen die Teilnehmer solcher Veranstaltungen weil sie Ergebnisse sehen, ausprobieren und Feedback geben wollen und nicht um zu hören wo es Probleme gab die sie weder beurteilen noch beheben können.

Zuletzt fressen Erklärungen und Begründungen Zeit weg die deutlich besser und gewinnbringender genutzt werden könnte. Jede Nacherzählung unerwarteter Hindernisse könnte ersetzt werden durch Hands on-Demonstrationen, Zufriedenheitsmessungen, Verbesserungsvorschläge oder die Vorstellung und Abstimmung von nächsten Schritten. Gerade vor dem Hintergrund, dass in agilen Teams Meetings meistens timeboxed sind ein nicht zu unterschätzender Faktor.

Das Alles heisst übrigens nicht, dass Fragen nach den nicht gelieferten Ergebnissen nicht beantwortet werden sollen. Das sollten sie auf jeden Fall. Aber nur dann wenn sie gestellt werden und ohne zu viele Details. Die will niemand hören.

Montag, 7. Januar 2019

Process, Tribe and Comfort Zone

FS
Ich bin nicht sicher ob Emily Phillips hier wirklich über Agile Leadership spricht oder nicht doch eher darüber wie sie mit den Unwägbarkeiten des eigenen Lebens umgeht. Interessant ist es aber so oder so.

Donnerstag, 3. Januar 2019

Investitionsstaus

FS
Bild: Wikimedia Commons / Caliva - CC BY-SA 4.0
Es war eine der letzten Meldungen des Jahres: im Jahr 2018 wurden Investitionsmittel von insgesamt 25 Milliarden Euro nicht abgerufen. Wohlgemerkt, es handelte sich dabei um bereits freigegebene Summen, es gab nichts mehr zu beantragen und genehmigen, man hätte direkt mit dem Ausgeben anfangen können. Dass das nicht geschehen ist ist keine Besonderheit der staatlichen Verwaltung, auch in vielen grossen Firmen gibt es dieses Phänomen - und es hat Gründe.

Am Anfang steht wie so oft das Dilemma, dass die Zukunft nicht vorhersehbar ist und die Realität sich anders entwickelt als geplant. Im besten Fall führt das dazu, dass Vorhaben schneller (und damit billiger) umgesetzt werden können als vorgesehen. Das gibt es, es ist aber selten. Häufiger ist das absolute Gegenteil: weil die Planung an der Realität vorbeiging muss neu geplant werden, die Umsetzung beginnt dann deutlich später oder muss sogar ins nächste Jahr verschoben werden.1

Beide Fälle führen dazu, dass in den jeweiligen Organisationen Stillstand einkehrt. Denn um neue Vorhaben zu beginnen müssten diese eine genehmigte Finanzierung für das laufende Jahr haben, was aber bei grösseren Summen einen monatelangen bürokratischen Prozess erfordern kann. Bis dieser abgeschlossen ist kann mit der Arbeit nicht begonnen werden, und wenn er bis Jahresende nicht beendet wurde bleibt das Geld ungenutzt. Stattdessen das bereits freigegebene Budget derjenigen Vorhaben zu nehmen die nicht starten konnten geht auch nicht - derartige Mittel sind in der Regel zweckgebunden.

Letztendlich können derartige Zustände mehrfach schädlich sein. Zum Einen sorgen sie dafür, dass sich Arbeiten unnötig verzögern (→ Cost of Delay), des Weiteren wurden ggf. bereits Lizenzen oder Geräte gekauft, können aber nicht benutzt werden, wodurch sie zwar Geld kosten aber keines erwirtschaften (→ Totes Kapital), schlimmstenfalls führt der Versuch das vorhandene Geld irgendwie doch einzusetzen zu unnötigen Erweiterungen bereits fertiger Ergebnisse, wodurch diese unübersichtlicher, instabiler und wartungsintensiver werden (→ Bloatware/Feature Creep).

Alles das ist für alle Beteiligten relativ klar zu erkennen sobald es einmal eingetreten ist, es wird also versucht Gegenmassnahmen zu ergreifen. Der in vielen Fällen eingeschlagene Lösungsweg macht aber alles nur noch schlimmer: er besteht daraus, strukturell mehr Vorhaben zu beantragen und genehmigen zu lassen als durchgeführt werden können. Stellt sich jetzt eines als nicht durchführbar heraus kann man einfach das nächste beginnen, man ist also in jedem Fall ausgelastet. Problem gelöst?

Auch hier tritt wieder das Problem der nicht vorhersehbaren Zukunft auf: wenn wider Erwarten alle Vorhaben wie geplant begonnen und durchgeführt werden können, dann ist es nicht mehr möglich diejenigen umzusetzen die "auf Vorrat" beantragt worden sind. Für sie wird also eine fehlende Machbarkeit gemeldet, wodurch ihr Budget wieder zur allgemeinen Verfügung steht. Abgerufen werden kann es wegen der genannten bürokratischer Prozesse dann nicht mehr rechtzeitig. Siehe oben.

Das Bemerkenswerte ist, dass es auch andere Lösungen gäbe, durch die Inverstitionsstaus vermieden werden könnten: man könnte Genehmigungsprozesse beschleunigen, die Zweckbindung von Finanzierungen aufheben oder die Organisation vom Push- auf das Pull-Prinzip umstellen. Jede dieser Optionen würde aber tiefgreifende Änderungen der Organisations- und Genehmigungsstrukturen erfordern, wovor dann doch zurückgeschreckt wird. Und dann bleibt es dabei, dass immer wieder Geld nicht abgerufen wird.

Nachtrag:
Um auf Feedback zu reagieren: ja, in diesem Beitrag geht es hautptsächlich darum was falsch läuft und nur wenig darum wie es besser gehen würde. Das hat seinen Grund darin, dass das besser Machen aus einer Umstellung, bzw. einem Rückbau bestehender Organisationsformen bestehen muss. Da die aber von Fall zu Fall unterschiedlich sind ist es kaum möglich eine generelle Handlungsempfehlung abzugeben. Wie so oft: es kommt darauf an.

Nachtrag II:
Passend zum Thema geht es in einer der ersten Meldungen des Jahres weiter: Investitionsstau in Städten und Kommunen erreicht Rekordniveau.


1Natürlich gibt es auch die Fälle in denen die Umsetzung zum geplanten Zeitpunkt beginnt und endet oder in denen sie
zum geplanten Zeitpunkt beginnt und verspätet endet, aber die sind in diesem Zusammenhang nicht von Bedeutung
Powered by Blogger.