Dienstag, 31. Dezember 2019

Kommentierte Links (LVII)

Bild: Unsplash / Dayne Topkin - Lizenz
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

  • Mary Poppendieck: Grown-Up Lean

    Den längsten Essay gleich zu Beginn, und gleichzeitig auch den optimistischsten. Belegt mit vielen Beispielen (Toyota, Linux, Google, Amazon, SpaceX, ING, Spark NZ) schlägt Mary Poppendieck den grossen Bogen von den 80ern bis heute und zeigt auf, dass das was wir heute als Agile oder DevOps bezeichnen seine Ursprünge im Lean Management der japanischen Fabriken des 20. Jahrhunderts hat. Gleichzeitig wirkt sie auch einem verbreiteten Missverständnis entgegen, nämlich dem, dass es in Lean in erster Linie um Effizienzsteigerung, bzw. um die Vermeidung nicht zielführender Tätigkeiten ginge. Als zentrales Element stellt sie die Humanzentrierung heraus, also das in den Mittelpunkt Stellen des Mitarbeiters. Durch Product Ownership, durch dienendes Management, durch die Demokratisierung der Produktionsprozesse. Und als wäre all das nicht schon lesenswert genug beginnt sie ihre Ausführungen mit einer Anekdote aus Deutschland.

  • Gunter Dueck: How to innovate if you must

    Trotz des englischen Titels ein deutscher Text, und mal wieder ein echter Dueck. Mit im Verlauf des Artikels zunehmendem Sarkasmus seziert er die Fehler, die die Konzerne seit 30 Jahren bei der Digitalisierung und Agilisierung ihres Geschäfts machen. Zusammengefasst: viel Fassade, viel Hochmut, wenig Mut, wenig Bereitschaft sich auf Neues einzulassen. Das ist nicht falsch (und wird auch hier mit vielen bekannten und neuen Beispielen unterfüttert), lässt aber unerwähnt, dass selbst Konzernvorstände weniger frei in ihren Entscheidungen sind als man denken sollte. Von den Aktionären bis zum Betriebsrat will so ziemlich jeder mitreden. Grundsätzlich hat Dueck aber Recht - ein bisschen mehr ginge immer. Und die Anekdote, dass IBM Google Maps hätte vorwegnehmen können, es aber nicht gemacht hat, hat Potential zum Klassiker.

  • Steve Denning: Why Budgeting Kills Agile And Innovation

  • "Die Budgetierung stellt häufig einen der letzten - und grössten - Stolpersteine auf dem Weg zu einer wirklich agilen Organisation dar", lautet gleich der erste Satz von Steve Dennings Streitschrift. Trotz dieses Auftaktes geht es dann aber strukturiert durch verschiedene Argumentationsphasen. Die historischen Hintergründe, die theoretisch möglichen Vorteile klassischer Budgetprozesse, die in der Realität auftretenden Nachteile und zuletzt die grosse Alternative: Beyond Budgeting. Geschrieben ist das aus einer US-amerikanischen Perspektive, aus einer deutschen/europäischen dürfte es sogar noch schlimmer sein. Die Kombination aus übertriebenem Taylorismus (die Mitarbeiter sind so spezialisiert, dass sie nur noch an einer spezifischen Stelle einsetzbar sind) und einem de facto Kündigungsschutz führt dazu, dass häufig nur noch der Schein von Handlungsfähigkeit entsteht. in Wirklichkeit wird das Geld jedes Jahr auf die selbe Art ausgegeben - das Gegenteil von Business Agility..

  • Alistair Cockburn: Agile is not dead, quite the opposite

    In der Produkt-, Projekt- und Prozessmanagement-Filterblase kann man leicht den Eindruck gewinnen, dass die agile Bewegung die Gegenwart dominiert, vielleicht sogar so sehr, dass es zu Sellout und Overkill kommt. Die Zahlen die Alistair Cockburn anführt legen etwas anderes nahe: angesichts von hunderten Millionen von Menschen in der Wissensarbeit (davon viele aber keineswegs alle in der IT) fallen die wenigen Millionen die bereits mit dem Thema Agile in Berührung gekommen sind kaum ins Gewicht. Der Bewegung steht ihre eigentliche Wachstumsphase also noch bevor. Dass das in der Öffentlichkeit oft anders dargestellt wird macht Cockburn daran fest, dass diese Mengenverteilung nicht allen bewusst ist. Als die Untergangspropheten der Agilität sieht er jene, die schon vor 10 und mehr Jahren begonnen haben so zu arbeiten. Für die scheint sich der Lebenszyklus dieser Idee dem Ende entgegenzuneigen. Dass sie aber keineswegs repräsentativ sind sollte man im Hinterkopf behalten. Ein wertvoller Beitrag, den man sich in Erinnerung rufen sollte wenn mal wieder jemand "Agile is dead" propagiert.

  • Yuri Malishenko: Agile transformation is a bad story and here is why

    Ein lesenswerter Text, hinter dem sich mehr verbirgt als man anhand der Clickbait-Überschrift ahnen könnte. Basierend auf dem Actantial Model von Algirdas Julien Greimas versucht Yuri Malishenko darzustellen mit welchen Betrachtungsweisen und Erwartungshaltungen sich verschiedene Gruppen (Management, Agile Coaches, Mitarbeiter) einer agilen Transition nähern. Die wenig überraschende Erkenntnis: sie sind nicht identisch sondern weichen z.T. stark voneinander ab. Das Interessante daran: mit Hilfe des Actantial Model ist es möglich diese Interessenkonflikte aufzuzeigen und zu visualisieren. Im Fall strauchelnder Veränderungsvorhaben könnte das ein wertvolles Werkzeug sein um aufzuzeigen wo die Beteiligten aneinandervorbeireden.

  • Stefan Kühl: Zur Entstehung, Durchsetzung und Regulierung von Regelabweichungen

    Ich muss mich wohl korrigieren. Vermutlich hat nicht Mary Poppendieck den längsten Beitrag in dieser Liste sondern Stefan Kühl. Dass das nicht ganz klar zu sagen ist liegt daran, dass ein nicht unwesentlicher Teil des Textes aus dem Quellenverzeichnis besteht, was ein deutlicher Hinweis darauf ist, dass hier wissenschaftlich gearbeitet wurde. Die in diesem Zusammenhang behandelte zentrale These ist die, dass Gesetzesbrüche und Regelverstösse in Organisationen meistens nicht auf Schlampigkeit oder Indifferenz zurückgehen sondern das Ergebnis von rationalem Abwägen sind. Die Verstösse werden nur in dem Rahmen betrieben, der eine Erkennung oder Sanktionierung unwahrscheinlich macht - und dieser Rahmen wird durch ständiges Ausprobieren erkundet und ausgereizt. Im Grunde ein Inspect & Adapt mit dem Ziel einer möglichst effektiven brauchbaren Illegalität. Bedingt durch diese Brauchbarkeit ergibt sich implizit eine weitere Dimension der Erziehung zur Normverletzung: die Etablierung der Abweichung von Regeln als organisationskulturelle Erwartung. Führt man sich die in aller Konsequenz vor Augen kann einem schwindelig werden.

  • Cliff Berg: SpaceX’s Use of Agile Methods

    Die agile Skalierung dürfte mittlerweile als Königsdisziplin der Agilität abgelöst worden sein. Die neue Meisterklasse ist die agile Produktion von komplizierter Hardware mit eingebetteter Software. In der heutigen Form erst durch den 3D-Druck möglich geworden entstehen hier in kurzen Zyklen Produkte deren Komplexität und Disruptivität vor kurzem noch unvorstellbar gewesen wäre. Dass Cliff Berg als Paradebeispiel das Raumfahrt-Unternehmen SpaceX vorstellen kann fügt dieser Entwicklung eine zusätzliche Pointe hinzu: "Rocket Science" gilt im englischen Sprachraum als Synonym für extrem anspruchsvolle Aufgaben - und jetzt gibt es eine Firma die in diesem Bereich nicht nur führend ist, sondern das erst durch den Einsatz von MVPs, iterativ-incrementellem Arbeiten und flexibel konfigurierbaren Delivery Pipelines werden konnte.

  • Tim Themann: Von Methoden, METHODEN und MeTooden

    Eine schöne Differenzierung. Angelehnt an Tom DeMarco und Timothy Lister unterscheidet Tim Themann zwischen Methoden (Vorgehensmodellen), METHODEN (dogmatischen Regelwerken) und MeTooden (dem Versuch ein an anderer Stelle erfolgreiches Vorgehen zu kopieren). Letzteres kann leicht in Cargo Cult abgleiten, was von Theman nochmal ausdifferenziert wird: Mismatch von Lösung und Problem, versehentlich falsche Übertragung, Unterschätzung des Einführungsaufwandes, ggf. Toolfixierung und Kontaminierung der ursprünglichen, eigentlich guten Idee. Ich würde noch den Survivor Bias hinzufügen, aber das ist nur ein Detail. Was den Charme der MeToode ausmacht ist vor allem der Begriff, der jedem der ein bisschen Englisch kann sofort intuitiv verständlich sein wird.

Sonntag, 29. Dezember 2019

Kommentierte Links (LVI)

Bild: Unsplash / Compare Fibre - Lizenz
Leicht verfrüht: die Kommentierten Links des Dezember. Übermorgen mit einer weiteren Ausgabe, mit den Links die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.
  • Jason Little: Boundaries, Interventions, and Baby Ducks

  • Zum Ende des Jahrzehnts reflektiert Jason Little über die Unternehmenstransformationen die er in dieser Zeit begleiten durfte. Dabei identifiziert er drei Konzepte die man sich bei derartigen Vorhaben vor Augen führen sollte:
    • Interventions-Punkte - Es gibt gute und schlechte Momente um Veränderungen anzustossen. Gut ist z.B. vor oder während der Planung des nächsten Jahres, schlecht unmittelbar danach.
    • Einfluss-Sphären - Wo sind Prozesse und Strukturen selbst verantwortet und gestaltbar und wo sind sie es nicht? Und dort wo sie es nicht sind: würde sich der dort verantwortliche an Veränderungen beteiligen?
    • Entenküken-Syndrom - Genau wie Entenküken zu den ersten von ihnen wahrgenommenen Wesen eine starke emotionale Bindung entwickeln können Menschen vergleichbare Bindungen zu Programmiersprachen, Management-Ansätzen, etc. entwickeln.
    Während die ersten beiden Konzepte weitgehender Common Sense sein dürfte ist das das dritte eines das selten bedacht wird. Eine Gesetzmässigkeit kann man sicher nicht ableiten, einige Überlegungen ist es aber definitiv wert, sowohl in der Organisationsentwicklung als auch in der Selbstreflektion.

  • Marcus Raitner: Vorleben und infizieren statt abholen und mitnehmen

    Mehr zum Thema Unternehmenstransformation. Um beim gerade genannten Konzept der Einfluss-Sphären zu bleiben - Change Management kann die offiziellen Prozesse und Vorschriften beeinflussen, die inneren Motivationen und Verhaltensmuster dagegen nicht. Dort wo es versucht wird zeugt schon die Wortwahl von Paternalismus und Entmündigung, etwa dann wenn die Mitarbeiter "mitgenommen" werden sollen. Der von Marcus Raitner bevorzugte Weg sieht anders aus, es ist der "virale Wandel". Um ihn zu starten müssen einzelne kommunikationsstarke und vom Sinn der Veränderungsvorhaben überzeugte Personen gefunden werden, die diese so vorleben, dass andere von sich aus folgen wollen. Die (schwierige) Management-Aufgabe in diesem Modell ist es diese Personen zu finden und in die entsprechenden Positionen zu bringen.

  • Sonja Blignaut: Reconceptualising organisations - from complicated machines to flowing streams

    Noch mehr zum Thema Unternehmenstransformation. Sonja Blignaut geht davon aus, dass (produkterzeugende) Organisationen aus nichts anderem Bestehen als aus Wert- oder Handlungsströmen (Flows), die zwar bis zu einem gewissen Grad in bestimmte Richtungen gelenkt werden können, sich aber letztendlich immer den geradesten Weg Richtung Ziel suchen - im Zweifel auch an den offiziellen Prozessen vorbei. Ein interessanter Ansatz, der aber konsequent zu Ende gedacht neue Fragen aufwirft: was passiert mit Einheiten zu denen der Zufluss so verstopft ist, dass der Strom an ihnen vorbeifliesst (→ Thromben und Embolien) und wie kann dafür gesorgt werden, dass an kritischen Stellen Druck nicht zu Ausweichreaktionen sondern zu Gegendruck führt (→ Nicht-Newtonscher Flow)? Auf jeden Fall eine Anregung zum Nachdenken.

  • Christiaan Verwijs: Actual stakeholders? Or just your audience?

    Ein Grundlagen-Thema über das zu selten nachgedacht wird: wer sind eigentlich diese Stakeholder mit denen ein agiles Team regelmässig interagieren soll? Ausgehend von dem leider weit verbreiteten Antipattern, dass nur Firmen-interne Kollegen in diese Kategorie fallen versucht sich Christiaan Verwijs an einer besseren Definition. Die von ihm gefundene lautet: "Jeder der etwas zu gewinnen hat wenn das Team gute Arbeit leistet oder etwas zu verlieren hat wenn das nicht der Fall ist". Im Vergleich zur internen Lösung ein deutlich besserer Ansatz, wenn auch einer der immer noch Interpretationsspielraum lässt. Würde beispielsweise eine Audit- oder Revisionsabteilung nach dieser Definition ein Stakeholder sein? Vermutlich läuft es wieder auf die klassische Antwort hinaus - es kommt drauf an.

  • Gojko Adzic: Deliberate Side-Products

    Wenn es um die Ursachen der Komplexität von Anwendungen und Produkten geht werden immer die gleichen Gründe genannt. Technischer Wandel, sich ändernde Nutzervorlieben, wachsende Funktionsumfänge, hohe Abhängigkeiten, etc. Was selten genannt wird ist der Wunsch der beteiligten Entwickler innovative oder anspruchsvolle Technologien auszuprobieren. Gojko Adzic beleuchtet von verschiedenen Seiten wie es dazu kommen kann und hat mit seinen "Deliberate Side-Products auch eine Lösung parat. Auch der eine oder andere Agile Coach könnte sich ertappt fühlen, denn auch hier gibt es immer wieder überkandidelte methodische Lösungen, die besser nicht in kritischen Bereichen ausprobiert worden wären.

Donnerstag, 26. Dezember 2019

Lokale Optimierung (II)

Bild: Pixabay / Carlotta Silvestrini - Lizenz
Es war eine der kurioseren Meldungen der diesjährigen Weihnachtszeit. Wie der Spiegel berichtete kursierte bei Siemens der so genannte "Keks-Erlass", eine Anweisung sich beim Konsum von Kaffee und Keksen zurückzuhalten um so Kosten zu senken. Was der spezifische Grund in diesem Fall ist kann man nur erraten, wer aber länger in Grossunternehmen gearbeitet hat wird von dieser Anekdote nicht überrascht sein, derartige Sparprogramme in eigentlich kleinen und aus Systemsicht irrelevanten Budgets gibt es immer wieder. Aber wo kommen sie her?

Wenn man den hin und wieder als Verursacher vorkommenden "Faktor Mensch" (in Form übereifriger Mittelmanager) und das gelegentlich auftretende Gesetz der Penetranz der negativen Reste ausser acht lässt bleibt vor allem ein immer wiederkehrender Auslöser für derartige Einsparversuche - ein globales Sparprogramm wird auf alle Teile des Unternehmens umgeschlagen, z.B. muss jeder 10 % weniger ausgeben. Das trifft dann auch Einheiten wie das Catering, das dann nur noch an einer Stelle einsparen kann: der Bewirtung.

Was dabei beachtet werden muss: aus einer Topmanagement-Perspektive macht dieses Vorgehen meistens Sinn. Würden derartige Optimierungen nicht einheitlich auf alles ausgerollt, würde sehr schnell fast jede Einheit beantragen, dass gerade bei ihr eine Ausnahme gemacht werden müsste. Die Begründungen dafür sind meistens so detailspezifisch, dass sie nur mit grösserem Verständnisaufwand nachvollziehbar wären, wofür schlicht die Zeit fehlt. Um dieser Situation zu entgehen fällt der Sparhammer auf alles.

Aus der operativen Perspektive ist die Sicht dagegen eine andere: ich habe schon verschiedene derartige herunterkaskadierte Detail-Sparmassnahmen erlebt, von der oben genannten Reduzierung der Bewirtung über das Verbinden der Beleuchtung mit Bewegungsmeldern bis hin zum Abzählen von Flipchart-Blättern für einzelne Meetings. Das Ergebnis in praktisch jedem einzelnen Fall - am Ende war nichts billiger und vieles sogar teurer als vorher.

Die offensichtlichste Art der Verteuerung entsteht durch Verwaltungsaufwände. Wenn ein Meeting-Organisator z.B. für jeden seiner Termine drei abgezählte Flipchart-Blätter aus einer Materialausgabe abholen muss, sind alleine die dafür nötigen Arbeitszeiten so teuer, dass man den Raum damit tapezieren könnte. Und wenn für das Abzählen und Aushändigen ein Mitarbeiter durchgehend in der Materialausgabe sitzen muss, vervielfachen sich die Kosten.

Auch das Stromspar-Beispiel hatte ähnliche Effekte. Da in allen Räumen das Licht ausgehen musste wenn die Sensoren keine Bewegung wahrnahmen sassen regelmässig Mitarbeiter in den Toiletten-Kabinen im Dunkeln. Diese waren so eng, dass selbst heftiges Winken ausserhalb des Aufzeichnungsbereichs der Bewegungssensoren stattfand. Notgedrungen wurden die "Geschäfte" jetzt in den Stockwerken verrichtet in denen die Toiletten Fenster hatten. Die täglichen Wanderungen dorthin dauerten lange und kosteten damit Arbeitszeit und Produktivität.

Am teuersten waren aber (und hier kommen wir wieder zur Siemens-Geschichte) die Einsparungen bei Kaffee, Wasser und Keksen. Das Gefühl auf einer unnötig kleinteiligen Ebene gegängelt zu werden, einschliesslich einer spürbaren Beeinträchtigung der Arbeitsbedingungen (wer einmal mit trockenem Mund vortragen musste kennt das Problem) führte zu einem heftigen und kostspieligen Absacken von Arbeitsmoral, Motivation, Eigeninitiative, Effektivität und Qualität.

In allen Fällen ergaben die lokalen Optimierungen nur bei isolierter Betrachtung Sinn, aus systemischer Sicht waren sie unsinnig und kontraproduktiv. Die Ironie der Geschichte: ausgelöst wurden sie aber durch den (fehlgeleiteten) Versuch, am Gesamtsystem zu arbeiten.

Um es gar nicht erst so weit kommen zu lassen wäre in den meisten Fällen ein anderes Vorgehen sinnvoll. Statt auf intransparente und nicht nachvollziehbare Einzelprozesse mit generischen Vorgaben für alle Einheiten zu reagieren kann man versuchen sie transparent und nachvollziehbar zu machen und dann ihre Interaktionen zu optimieren. Und an der Stelle schliesst sich der Kreis - das kann aufgrund der damit verbundenen Komplexität nur gemeinsam mit den betroffenen Mitarbeitern gelingen, die sich aber nur beteiligen werden wenn sie nicht befürchten müssen dann von Micromanagement und lokalen Pseudo-Optimierungen betroffen zu sein.

Montag, 23. Dezember 2019

Der Weihnachts-Sprint

Bild: Pixabay / destressguy - Lizenz
Die Vorweihnachtszeit ist voller Traditionen die jedes Jahr wieder aufleben. Die Städte hängen voller Leuchtdekorationen, auf Weihnachtsmärkten wird Glühwein ausgeschenkt, im Fernsehprogramm laufen Der kleine Lord und Stirb langsam und in den Scrum Teams rund um die Welt wird kontrovers diskutiert wie der nächste Sprintwechsel aussehen soll.

Der Hintergrund ist einfach: je nach Sprint-Länge und -Rhytmus wird dieser Sprintwechsel entweder in die Weihnachtsfeiertage oder in die Zeit zwischen Weihnachten und Neujahr fallen, in der fast alle Menschen sich im Urlaub befinden. Dass ein geordnetes Durchführen aller Arbeiten und Meetings damit schwer bis unmöglich wird ist klar, aber was soll stattdessen gemacht werden?

Natürlich gibt es darauf mehrere mögliche Antworten. Einige wenige Teams rechnen die Feiertage aus der Sprintlänge heraus, was zwar effektiv ist aber den Kalenderrhytmus durcheinanderbringt. Andere lassen einen Sprint ausfallen und überlassen es den wenigen Kollegen die nicht im Urlaub sind ihre Zeit selbst zu verplanen. Manche ziehen die üblichen Intervalle durch, zur Not mit reduzierter Mannstärke. Die meisten machen aber einen Weihnachts-Sprint mit angepasster Länge.

In der Anwendung sieht das so aus, dass die üblichen Wochentage des Sprintwechsels beibehalten werden, allerdings nicht in den üblichen Abständen zueinander sondern in Relation zu den Feiertagen. Bei einem Mittwochs-Sprintwechsel würde das bedeuten, dass der Weihnachtssprint am letzten Mittwoch vor dem 24.12. beginnt und am ersten Mittwoch nach dem 01.01. endet.

Je nach Jahr würde ein solcher Sondersprint unterschiedlich lang dauern, etwa 2018/19 zwei Wochen oder 2019/20 drei Wochen. Abhängig von der normalen Sprintlänge (möglich sind 1 bis 4 Wochen) kann eine solche Abweichung einen deutlich kürzeren oder längeren Sprint ergeben als üblich, und aufgrund der Gruppierung um die Feiertage auch den davorliegenden Sprint spürbar verkürzen.

Dort wo eine Velocity berechnet wird macht es Sinn diese Sprints aus der Berechnung herauszunehmen, da diese sonst ihre Aussagekraft verlieren würde. Zum einen wegen des von der Norm abweichenden Verhältnisses von Dauer und Durchsatz, zum anderen aber auch weil aufgrund der Urlaube die Crossfunktionalität nicht durchgehend gewährleistet werden kann, was natürlich Auswirkungen auf die Leistungsfähigkeit hat.

Eine Tradition der besonderen Art kommt in manchen Unternehmen noch dazu: als Entschädigung für die Mitarbeiter die im Büro den Betrieb aufrechthalten währen die Kollegen sich auf den Pisten und Stränden befinden wird ihnen ermöglicht selbst zu entscheiden woran sie in dieser Zeit arbeiten wollen. In gewisser Weise ist auch das ein Weihnachtsgeschenk.

Donnerstag, 19. Dezember 2019

Velocity

Bild: Pexels / Mike Birdy - Lizenz
Es gibt Konzepte aus dem Umfeld der agilen Frameworks, die von vielen Teams und Managern mit Begeisterung aufgenommen werden. Man verspricht sich von ihnen das was (scheinbar) durch die Agilität verloren geht: Planbarkeit und Berechenbarkeit. Unter diesen Konzepten ist die Velocity, auf deutsch Durchschnittsgeschwindigkeit, eines der beliebtesten, aber auch eines der am häufigsten falsch verstandenen. Zeit für einen näheren Blick.

Normalerweise wird unter diesem Begriff die durchschnittliche Menge an Story Points verstanden, die ein (Scrum-)Team in einem Sprint fertigstellt. Beispielsweise würde bei 12 Punkten in Sprint I, 14 in Sprint II und 10 in Sprint III eine Velocity von 12 entstehen. In vielen Firmen wird dieser Wert verwandt um die verbleibende Dauer der Produkterstellung zu planen. Dafür wird das Team aufgefordert den verbleibenden Aufwand in Story Points zu schätzen, um diese danach auf einem projizierten Zeitstrahl zu verteilen.

Dieses Vorgehen erscheint auf den ersten Blick naheliegend, enthält aber einen Denkfehler, der sich aus dem folgenden Vergleich erschliesst: bei einem Auto das mit Durchschnittsgeschwindigkeit 120 km/h unterwegs ist, bezieht sich dieser Wert auf die Strecke hinter dem Auto, nicht auf die Strecke vor ihm. Er ist lediglich ein statistischer Mittelwert der Vergangenheit, ob er in Zukunft über- oder unterschritten werden wird, hängt von vielen Faktoren ab: Strassenzustand, Wetter, Verkehrsdichte, Tankfüllung, etc.

Das gilt in gleicher Weise auch für die Produktentwicklung. Gerade im Bereich komplexer Produkte stellt diese keine berechenbare Serienfertigung dar, sondern eine Abfolge von aufeinander aufbauenden und sich unvorhersehbar beeinflussenden Prototypen oder MVPs. Diese können sich in der Zukunft grundlegend anders verhalten als in der Vergangenheit, weshalb die Projektion alter Erfahrungswerte auf die weitere Planung immer wieder auf Probleme stossen wird. Die Nutzung der Velocity zu Planungszwecken ist daher sehr unzuverlässig (und jede andere Art der Prognose wäre es auch).

Das heisst nicht, dass die Erhebung der Velocity völlig unsinnig wäre, man kann durchaus Nutzen aus ihr ziehen. Dieser besteht lediglich nicht daraus, dass man genau planen könnte, wie lange die noch verbleibenden Arbeiten dauern werden. Stattdessen ist sie ein Ausgangswert für eine vorläufige Planung, die ständig anpassbar sein muss, für den Fall, dass das durch neue Erkenntnisse nötig wird. So eingesetzt kann die Velocity ein wertvolles Hilfsmittel sein, aber eben auch nur so.

Montag, 16. Dezember 2019

Andon (II)

Der vermutlich häufigste Einwand gegen das Andon-Konzept ist der, dass es nur im Maschinenbau funktionieren würde. Dass es auch in anderen Teams funktioniert zeigt dieser Vortrag, der aber nicht nur darum interessant ist, sonden auch weil er Andon mit einer anderen grundlegenden Idee verknüpft - der psychologischen Sicherheit.

Donnerstag, 12. Dezember 2019

Ein Bild sagt mehr als 1000 Worte (XXVII)

Montag, 9. Dezember 2019

Wer von agiler Skalierung spricht meint meistens etwas anderes

Bild: Piqsels - Lizenz
Unter allen Herausforderungen die eine agil arbeitende Organisation mit sich bringt dürfte die Skalierung die grösste sein. Sobald es nicht mehr nur ein Team ist das nach XP, Scrum, Kanban & Co arbeiten soll sondern mehrere, und das auch noch aufeinander abgestimmt, müssen Zusammenarbeitsmodelle entwickelt werden. Der hohe Anspruch an sie: sie sollen die auf der Teamebene mögliche Schnelligkeit und Flexibilität bewahren und auf die Gesamtorganisation übertragen, auf der anderen Seite aber auch eine gemeinsame Ausrichtung auf übergeordnete Ziele ermöglichen.

Es gibt tatsächlich auch Organisationen in denen das gelingt, in den meisten Fällen ist das Ergebnis aber nicht das gewünschte. Entweder führt der Versuch sich auf ein gemeinsames Ziel auszurichten wieder zu Hierarchie und Bürokratie oder eine nicht ausreichende Abstimmung untereinander endet in Ineffizienz und Ineffektivität. "Agil skaliert nicht" ist aufgrunddessen eine häufig zu hörende Aussage geworden. Aber ist das wirklich so? Ein anderer Erkläransatz ist der, dass das was meistens für agile Skalierung gehalten wird etwas ganz anderes ist.

Um das zu verstehen rufen wir uns kurz eine agile Organisationsform vor Augen. Am Anfang steht die noch zu erledigende Arbeit, meistens in Form eines Backlogs. Aus dem wird eine Teilmenge entnommen, die durch ein (Sprint-)Ziel zu einem sinnvollen Umfang gruppiert, durch ein crossfunktionales Team ohne externe Abhängigkeiten umgesetzt und als benutzbares Increment an die Anwender geliefert wird. Übertragen auf skalierte Ansätze bleibt das Vorgehen das gleiche, nur sind es jetzt mehrere crossfunktionale Teams ohne externe Abhängigkeiten die gleichzeitig auf ein gemeinsames Ziel hinarbeiten. Visualisiert sieht das so aus:



Und jetzt die spannende Frage: entspricht das was meistens als agile Skalierung bezeichnet wird diesem Bild? Leider nicht. Es fehlt in praktisch jedem Fall zwei entscheidende Kriterien - die Teams sind eben nicht crossfunktional und haben eben doch zahlreiche externe Abhängigkeiten. Bedingt dadurch ist es in diesen Fällen nicht möglich konzentriert auf das Ziel hinzuarbeiten, stattdessen sind alle gezwungen auf Zulieferungen zu warten und unfertige Arbeit an andere Einheiten weiterzugeben. Erst wenn alle dieser voneinander abhängigen Teams fertig sind kann ein benutzbares Increment an die Anwender geliefert werden. Visualisiert (und stark vereinfacht) sieht das so aus:


Dass in einem solchen Konstrukt die Lieferzyklen deutlich länger sind als in dem zuerst genannten ist offensichtlich. Sowohl die zeitliche als auch die inhaltliche Koordination der Übergaben ist derartig anspruchsvoll, dass sie einen Grossteil der Arbeitszeit einnimmt. Die vorderen und hinteren Teams der Prozesskette haben keine direkten Berührungspunkte und liegen zeitlich weit auseinander, so dass umfangreiche Dokumentation nötig wird. Wenn ein zulieferndes Team mit der Arbeit fertig ist wird das abnehmende nicht immer verfügbar sein, so dass Wartezeiten im System entstehen. Etc.

Das alles heisst natürlich nicht, dass diese Abläufe nicht optimierbar wären. Aber für eine Optimierung derartiger Systeme sind die agilen Ansätze nicht die beste Lösung. Hier ist das klassische Lean Management besser geeignet, dass mit seinen Wertstromanalysen, Just in Time-Lieferungen und Work in Progress-Limits auch über passende Werkzeuge verfügt. Das wird in der Regel auch unbewusst verstanden, versehentlich aber falsch bezeichnet. Es müssen doch mehrere agile Teams koordiniert werden1, also muss auch diese Koordination agil sein. Der entscheidende Irrtum vieler Transitionsvorhaben ist also der, dass von agiler Skalierung gesprochen wird, implizit aber Lean Management gemeint ist.

Vor diesem Hintergrund wird auch verständlicher, warum die gängigen agilen Skalierungsframeworks oft nicht funktionieren. Sie sind gedacht für crossfunktionale und unabhängige Teams, werden aber angewandt auf Komponententeams mit vielen Abhängigkeiten. Das kann nicht funktionieren. Und um das allen Beteiligten klar zu machen ist das Aufzeigen des zentralen Irrtums wichtig: Wer von agiler Skalierung spricht meint meistens etwas anderes.


1Dass nicht verstanden wird, dass diese Teams ohne Crossfunktionalität und Freiheit von Abhängigkeiten kaum agil sein können, ist Teil des Missverständnisses.

Donnerstag, 5. Dezember 2019

Exvernunft

Bild: Pixabay / Ryan McGuire - Lizenz
In seiner wie immer lesenswerten Kolumne ist es Sascha Lobo gestern gelungen ein neues Wort zu prägen: die Exvernunft. Gemeint ist damit ein Verhaltensmuster das in der Vergangenheit, unter anderen Rahmenbedingungen, absolut vernünftig war, das mittlerweile aber widersinnig geworden ist. Das Entscheidende - dem sich exvernünftig Verhaltenden ist dieser Bedeutungswandel nicht bewusst.

In der Kolumne wird die Exvernunft vor allem Politikern zugeschrieben, sie findet sich aber auch an vielen anderen Stellen. Unter anderem (und hier kommt der Zusammenhang zu den sonst hier behandelten Themen) in den Fehlentscheidungen auf allen Hierarchieebenen, die in vielen Unternehmen die Ursache für Ineffizienz, Ineffektivität oder sogar schwere wirtschaftliche Schäden sind.

Vielen von ihnen ist gemeinsam, dass das was sie bewirken zwar heute schädlich ist, zu früheren Zeitpunkten aber vernachlässigbar war oder unter Umständen sogar positive Effekte hatte. Big Bang Releases, "Ambitionierte Ziele", Perfektionismus, langfristige Detailplanung und Jahresgespräche können in einer weniger komplexen Vergangenheit funktioniert haben, heute ist das nicht mehr der Fall. Das ist aber nicht für jeden ersichtlich.

Die Gründe dafür sind immer wieder ähnlich: die oft mit dem hierarchischen Aufstieg gekoppelte Entfremdung von den Veränderungen der Umsetzungsebene, eine Verklärung der Vergangenheit, Wechselmüdigkeit, Group Think oder einfach nur die trügerische Verlockung scheinbar einfacher Lösungen - letzten Endes ist es in fast jedem Fall die menschliche Fehlbarkeit.

In der menschlichen Natur liegt allerdings neben dem Problem auch die Lösung für das Phänomen der Exvernunft. Wie David Dunning und Justin Kruger in ihrer legendären aber oft missverstandenen Studie gezeigt haben: der Mensch ist nicht nur fehlbar, er ist auch lernfähig. Und selbst aus den Verstrickungen der eigenen Fehlwahrnehmungen kann man sich lösen - wenn man dabei Unterstützung erhält.

Und an dieser Stelle erklärt sich einmal mehr die Existenzberechtigung von Scrum Mastern, Agile Coaches und ähnlichen Rollen. Eine ihrer zentralen Aufgaben ist es bestehende Prozesse, eingeübte Routinen und langbewährte Handlungsmuster immer wieder aufs Neue auf ihre Tauglichkeit zu überprüfen. Mit anderen Worten: sie sollen Exvernunft aufspüren und beseitigen.

Eine wichtige und verdienstvolle Aufgabe. Und eine von Dauer.

Montag, 2. Dezember 2019

The Agile Bookshelf: The Phoenix Project

Bild: Flickr / Steward Butterfield - CC BY 2.0
Um einen Klassiker wieder hervorzuholen - einer der Gründe wegen denen es nervt Scrum Master (oder Agile Coach) zu sein ist der, dass ein immer grösser werdender Stapel Bücher darauf wartet endlich gelesen zu werden. Tatsächlich kommt derart viel auf den Markt, dass nichts anderes übrig bleibt als den eigenen Rat zu befolgen, Wichtiges zu priorisieren und Unwichtiges wegzulassen. Um so schöner ist es wenn man wieder auf ein gerade durchgelesenes Buch zurückblicken kann. Heute: The Phoenix Project von Gene Kim.1

The Phoenix Project ist einer der seltenen Fälle in denen ein Fachbuch in Form von Belletristik vorliegt. Erzählt wird die Geschichte von Bill Palmer, eines Managers der fiktiven Firma Parts Unlimited, der sich nach der unerwarteten Entlassung seines Vorgesetzten plötzlich auf dessen Position wiederfindet und als Leiter IT Operations die Verantwortung für den Abschluss des am Rand des Scheiterns stehenden Grossprojektes "Phoenix" übernimmt (der am Ende natürlich gelingt).

Um es gleich zu sagen: einen Literaturpreis wird Gene Kim wohl nicht gewinnen, dafür fehlt stilistisch doch einiges. Einige Passagen fühlen sich nach BWL-Vorlesung an, die Figuren sind z.T. holzschnittartig überzeichnet, mehrere von ihnen durchlaufen irgendwann ohne nachvollziehbare Erklärung einen radikalen Verhaltenswandel, ein Stocken der Handlung wird mehrfach nur durch den weisen Aufsichtsrat Erik Reid verhindert, der immer wieder Deus ex machina-Auftritte hat. Und doch hat dieses Buch durchaus zurecht eine grosse Fangemeinde.

Deren Anhängerschaft dürfte zunächst darauf beruhen, dass nahezu jeder der schon in grossen IT-Projekten gearbeitet hat sich in der ersten Hälfte der ca. 800 Seiten wiederfinden dürfte. Hier geht schief was schiefgehen kann und nahezu jeder mögliche Missstand findet sich. Katastrophal fehlgeschlagene Grossreleases, inkompetentes Management, sich bekriegende Organisations-Silos und Abhängigkeiten ganzer Geschäftsbereiche von einzelnen Entwicklern werden so realitätsnah erzählt, dass die Parallelen zu vergleichbaren eigenen Erlebnissen geradezu unheimlich erscheinen.

Auf andere Weise ansprechend ist die Zweite Hälfte, denn hier erkämpft sich die IT von Parts Unlimited all das was in echten Firmen oft nicht genehmigt wird. Abbau von Kopfmonopolen, Automatisierung manueller Tätigkeiten, Zurückdrängen von politischen Management-Entscheidungen, Zusammenarbeit mit anderen Organisationseinheiten, Abkehr von Big Bang Releases und vieles mehr. Dem Leser wird eine Zielwelt vermittelt die nicht nur erstrebenswert sondern erreichbar erscheint. Am Ende sind die Risiken und Probleme zwar nicht verschwunden, sie sind aber beherrschbar und behebbar geworden.

Je nach Vorwissen wird The Phoenix Project den Leser unterschiedlich berühren. Wer sich schon näher mit Agile, Lean oder DevOps beschäftigt hat wird früh erkennen wie es ausgehen wird, wer sich oberflächlich damit befasst hat wird neue Inspirationen erhalten, wer neu in diesen Themen ist wird am Ende das Gefühl haben, dass das was er auf den letzten Seiten gelesen hat zu schön ist um wahr zu sein.2 Und die Frage wird aufkommen - ginge das auch bei mir? An dieser Stelle kann dieses Buch auch seine grösste Wirkung entfalten: es macht die Vorteile der sehr technischen und abstrakten DevOps-Welt plastisch und nachvollziehbar und kann so in Unternehmen die dieses Konzept noch nicht kennen zu einem Türöffner werden.


1Höchste Zeit war es auch, die Fortsetzung The Unicorn Project ist gerade erschienen.
2Und der Vollständigkeit halber: Leser ohne Projekt- oder IT-Bezug werden verwirrt sein.

Freitag, 29. November 2019

Kommentierte Links (LV)

Bild: Unsplash / Compare Fibre - Lizenz
  • Martin Fowler: Waterfall Process

  • Man sollte eigentlich denken, dass der Wasserfall-Prozess fest ausdefiniert wäre. Als das sprichwörtliche Gegenmodell zu Lean Management und Agile steht er schliesslich für Starrheit, Determinismus und Veränderungsresistenz. Bei näherer Betrachtung findet man davon aber nur wenig, ausgerechnet Wasserfall scheint das zu sein was Agile sein möchte: eine visionäre Idee von der zwar alle ein ähnliches Verständnis haben, die in der Realität aber jeder etwas anders auslegt. Martin Fowler versucht sich an einer allgemein nutzbaren Beschreibung, die vor allem dadurch nützlich ist, dass sie verschiedene Übergangsstufen definiert: Wasserfall, Prediktiv, Iterativ, Adaptiv, Agil. Ein Fest für Methoden-Liebhaber. (siehe auch: Taylorism isn’t as far from Agile and Lean as you would think)

  • Michael Rumpler: Auf welchem Flight Level wird was gemacht? [Edit: Link ist mittlerweile tot]

    Von den Flight Leveln glauben viele, dass sie das nächste grosse Ding der agilen Bewegung werden (oder schon sind). Ob das so kommt wird sich zeigen, definitiv sind sie aber ein sehr nützlicher und leichtgewichtiger Ansatz um Agilität zu skalieren. Das Schwierigkeit daran ist wie so oft die Konkretisierung: dass es auf den oberen Leveln strategischer und weniger detailliert zugeht als auf den unteren ist zwar klar, aber was genau findet denn dort statt? Ein guter Erläuterungstext kommt von Michael Rumpler, der praktisch durch die verschiedenen Flughöhen auf den Boden der Realität herabsteigt. Und ein guter Ansatzpunkt für Diskussionen ist das auch, denn er spricht bemerkenswert oft von Hierarchie.

  • Kent Beck: Inefficient Efficiency

    Im Umfeld der komplexen Produktentwicklung kann man für jede verständlich machende Analogie nur dankbar sein. Diese hier von Kent Beck ist eine die sofort jeder nachvollziehen kann, denn sie beruht auf einer einfachen Frage: was ist der bessere Weg um zwei Tassen Kaffe zu machen - getrenntes oder gemeinsames Erhitzen der benötigten Wassermenge? Die Erläuterung der Antwort braucht erstaunliche 5000 Zeichen und kommt an einer ganzen Reihe von Begriffen vorbei von denen jeder eine eigene Diskussion wert wäre: Effektivität, Effizienz, Latenz, Durchsatz und Cost of Delay. Ach ja, und die Antwort ist: getrenntes Erhitzen ist besser. Meistens.

  • Melissa Perri: Prioritization Shouldn't Be Hard

    Priorisierung ist hart, das weiss jeder der es schonmal versucht hat. Priorisierung sollte nicht hart sein, das denkt sich jeder der sich schon einmal daran schwer getan hat. Priorisierung muss nicht hart sein, sagt Melissa Peri, zumindest dann nicht wenn eine Voraussetzung gegeben ist: es braucht eine klare Strategie des Unternehmens, an der jede Entscheidung gemessen werden kann - was am besten dann funktioniert wenn das Ganze zahlenbasiert ist. Tatsächlich scheitern Priorisierungsversuche in der Realität extrem häufig am Fehlen dieser Voraussetzung. Wenn das Topmanagement einer Firma dem bekannten Leitsatz "ich will alles, und zwar alles sofort" folgt ist es kein Wunder wenn auf den unteren Ebenen Chaos ausbricht.

  • Willem-Jan Ageling: If you Scrum according to the 2010 Scrum Guide, are you doing Scrum?

    Passend zu dem was ich einmal als "historisches Scrum" beschrieben habe stellt sich Willem-Jan Ageling eine nicht ganz unwesentliche Frage: wenn sich die methodischen Vorgaben (d.h. der Scrum Guide) weiterentwickeln, ich selbst aber irgendwann auf einer dieser Evolutionsstufen stehenbleibe - mache ich dann noch Scrum? Auf den ersten Blick eine eher akademische Erwägung. Die letzten Änderungen waren so geringfügig, dass sie vernachlässigt werden können. Eine Grenzwertanalyse macht das Problem aber klar: in seiner Erstbeschreibung von 1995 gab es noch keine Refinements, keine Definition of Done und keine Retrospektiven, das wäre aus heutiger Sicht sicher kein Scrum mehr. Ab wann sich die Grenze setzen lässt ist darum eine durchaus interessante Frage.

Montag, 25. November 2019

Lead Time und Cycle Time

Bild: Piqsels - Lizenz
Wenn man in einem beliebigen agilen Team Unruhe stiften möchte gibt es einen ziemlich erfolgversprechenden Ansatz. Man muss nur beiläufig die Frage "Was ist nochmal der Unterschied zwischen Lead Time und Cycle Time?" in den Raum werfen und schon wird sich ein Grossteil der Anwesenden in eine längere Diskussion vertiefen, meistens ohne Ergebnis. Da die beiden Werte aber ziemlich wichtig sind lohnt sich eine Klarstellung. Hier ist sie.

Lead Time

Als Lead Time bezeichnet man die Gesamtdauer einer vollständigen Verarbeitungskette. Alle Ver- oder Bearbeitungsschritte die nötig sind um ein Produkt oder eine Dienstleistung zu erstellen werden addiert, die so entstandene Summe ist dann die Gesamt-Durchlaufzeit oder Lead Time. Gegebenenfalls können auch mehrere zusammengehörende Teilstrecken einer Verarbeitungskette als eigene Lead Times bezeichnet werden, etwa im Fall der Preprocessing Lead Time (Gesamtdauer der Bestellungsaufgabe und -annahmeprozesse) oder der Processing Lead Time (Gesamtdauer aller Verarbeitungsschritte)

Ein häufiges Missverständnis bei der Betrachtung einer Lead Time ist es sie zu kurz zu definieren, meistens weil Schritte am Anfang oder am Ende zu vergessen oder fälschlicherweise als nicht zugehörig betrachtet werden. Ein häufig vergessener initialer Schritt ist z.B. das Einloggen in einem Bestellportal, ein oft vergessener finaler Schritt ist die Auslieferung zum Kunden (bzw. in der IT das Produktionsdeployment). Seltener aber auch immer wieder vorkommend ist eine Lead Time die nur die Dauer der Ver- oder Bearbeitung misst aber nicht die Wartezeit dazwischen. Auch das ist nicht im Sinn der Idee.

Cycle Time

Unter Cycle Time versteht man die Zeit die benötigt wird um eine Teilstrecke einer grösseren Verarbeitungskette zu durchlaufen. Sie entspricht dabei normalerweise einem Ver- oder Bearbeitungsschritt, z.B. der Konzeption oder der Qualitätssicherung.Von den oben genannten Teil-Lead Times unterscheidet sie sich dadurch, dass sie nicht mehrere Verarbeitungsschritte umfasst sondern nur einen. Eine Rollout-Phase die Auslieferung, Installation und Schulung enthält würde demnach aus drei Cycle Times bestehen und nicht nur aus einer.

Auch bei Cycle Times gibt es Missverständnisse. Neben der gerade genannten Verwechselung mit Teil-Lead Times ist wie im Fall der Gesamt-Durchlaufzeit das "Vergessen" von vor-, nach-  oder zwischengelagerten Warte- oder Blockadezeiten zu nennenen. Vor allem in stark arbeitsteiligen Organisationen (die oft keine Lead Times messen) führt dieses Vergessen zu fehlgeleiteten Optimierungsbemühungen, in deren Rahmen nur die Bearbeitungszeit verkürzt werden soll während die normalerweise deutlich längere Nicht-Bearbeitungszeit unbeachtet bleibt.

---

Was Lead Time und Cycle Time gemeinsam ist, ist die Gefahr von Verfälschungen durch Multitasking, Repriorisierung oder Ressourcenverschiebung. In diesen Fällen bleibt Arbeit zeitweise (oder dauerhaft) liegen obwohl sie problemlos begonnen und beendet werden könnte, wirkliche Rückschlüsse auf das Leistungsvermögen von Organisationen oder Maschinen lassen sich dann aus Lead Time und Cycle Time nicht mehr ziehen. Um dem entgegenzuwirken können z.B. Work in Progress-Limits hilfreich sein.

Donnerstag, 21. November 2019

Zertifizierungs-Overkill

Die Scrum Alliance hat in dieser Woche etwas missverständlich kommuniziert. Ihr neues Mitglied in ihrem "2020 Board of Directors" kündigte sie per Mail mit den folgenden Worten an: "Hello, Community. We’re very proud to officially announce our 2020 Board of Directors. The membership of Scrum Alliance elected Karim Harbott as the new Scrum Certified Member on the Board. Here is an excerpt from Karim’s candidacy page: ..."

Ob dieser "Scrum Certified Member on the Board" ein selbstironischer Bezug darauf war, dass die Scrum Alliance in der Öffentlichkeit im Wesentlichen als Zertifizierungs-Vergabestelle wahrgenommen wird, oder eine missverständliche Umschreibung für einen Verteter der Scrum-Zertifikats-Inhaber - man weiss es nicht. Der Effekt war aber der: an Kaffetheken, in Twitterfeeds und Diskussionsgruppen rund um die Welt fragten sich verunsicherte Alliance-Mitglieder ob sie möglicherweise die Einführung der neuesten Management-Zertifizierung verpasst hätten.

Dass das überhaupt als ernstzunehmende Option in Betracht gezogen wurde hat einen Grund: seit einigen Jahren unterliegen die "Agilen Zertifizierungen" einer erstaunlichen Vermehrung. Neben die Scrum Alliance, die u.A. mit dem Certified Scrum Master die älteste Zertifizierung vergibt, ist mit der vom "Scrum-Vater" Ken Schwaber ins Leben gerufenen Scrum.org und ihrem Professional Scrum Master (und anderen) ein erster Wettbewerber getreten, der zweite Scrum-Gründer Jeff Sutherland ist mit dem Licensed Scrum Master seiner Firma Scrum Inc nachgezogen. Und noch reden wir nur über Scrum.

Mit der Lean Kanban University und ihrem Kanban Management Professional hat auch das zweite grosse agile Framework eine Zertifizierung, dazu kommen noch weitere, spezifischere Ausprägungen. Das International Requirements Engineering Board hat das Re@Agile-Zertifikat im Angebot, das International Software Testing Qualifications Board bietet die Agile Tester Extension. Natürlich ist auch irgendwie ein DevOps Institute entstanden, bei dem man zum Certified Agile Service Manager werden kann. Und jede dieser Organisationen bietet noch weitere Zertifizierungen, die hier sind nur Beispiele.

Auch das ist noch nicht alles. Seit die klassische, Top Down-getriebene Management-Bewegung reduzierte agile Ansätze auf den unteren Hierarchie-Ebenen zulässt wird auch hier zertifiziert. Beim Project Management Institute wird man Agile Certified Practitioner, Prince2 hat die Agile Practitioner Certification und die International Project Management Association vergibt die Agile Leadership Certification. Auch das Scaled Agile Framework mit seinen SAFe-Zertifikaten gehört in diese Kategorie.

Noch immer nicht genug? Kein Problem, die Zertifizierungen gehen bei den verschiedenen Anbietern noch weiter in die Breite und in die Tiefe. In der Breite stehen neben dem zertifizierten Scrum Master auch zertifizierte Product Owner, Entwickler und UX-Spezialisten, in der Tiefe findet eine Staffelung statt: Professional Scrum Master II, Professional Scrum Master III, Certified Agile Leader, Enterprise Kanban Coach und DevOps Leader zieren zweifellos jeden Lebenslauf und künden von teuer erkauften Kursen und gekonnt bestandenen Prüfungen.

Insgesamt kommen allein die bis hierher genannten Zertifizierungsanbieter auf eine mittlere zweistellige Zahl an möglichen Zertifizierungen. Noch nicht enthalten sind die zahllosen halb- und unseriösen Vergabestellen und die klassischen Zertifizierungsdienstleister (wie z.B. der TÜV und die IHK) die ihr Portfolio ebenfalls in Richtung Agilität erweitert haben sobald zu erkennen war, dass hier eine Nachfrage entsteht die man bedienen kann.

Als Folge dieser Entwicklung treten mittlerweile Overkill-Erscheinungen auf. Zunehmend ratlos stehen Personaler und Einkäufer vor der Frage ob ein CSP-SM oder ein PSM III wirklich so viel mehr wert sind als ein A-CSM oder ein PSM II, für Einzelpersonen ist nicht mehr nachvollziehbar welches Zertifikat ihnen helfen könnte, AKC und SDP sind sogar in Fachkreisen weitgehend unbekannt und der IHK-zertifizierte Agile Mindsetter löst nur noch ein Mittelding aus Fassungslosigkeit und Belustigung aus.

Letzten Endes kann man aber auch etwas Positives aus der Gesamtsituation ziehen. Je undurchsichtiger und unvergleichbarer die sich inflationär vermehrenden agilen Zertifizierungen werden, desto mehr werden Einzelpersonen, Personaler, Recruiter und Einkäufer darauf zurückgreifen müssen die Sinnhaftigkeit und das Vorhandensein der angestrebten oder verlangten Wissensgebiete, Qualifikationen und Erfahrungen selbst zu überprüfen. Und das - nicht die noch verbreitete Zertifikatsgläubigkeit - sollte ohnehin der Normalzustand sein.


Nachtrag 20.01.:
Die schiere Menge der angebotenen Zertifizierung erschliesst sich durch einen Blick auf diese Liste:
240 agile Zertifizierungen.

Montag, 18. November 2019

Why agile: Gesetzliche Regulierung

Bild: Unsplash / Patrick Tomasso - Lizenz
Zu den verbreiteten Mythen um agile Produktentwicklung gehört auch die Aussage, dass sie in bestimmten Zusammenhängen nicht einsetzbar wäre. Der vermutlich zweithäufigste Fall (nach das funktioniert in bestimmten Ländern/Kulturen nicht) ist die mit grosser Überzeugung vorgetragene Behauptung, dass Agilität in stark gesetzlich regulierten Bereichen nicht funktionieren kann. "Da muss man sich schliesslich an Vorschriften halten." heisst es oft. In der Realität ist allerdings das Gegenteil der Fall, gerade hier ist Agilität dringend nötig.

Der Grund dafür ist genau der gerade genannte: man muss sich an die Vorschriften halten. Das bedeutet aber auch, dass man die eigenen Produkte und Prozesse anpassen muss wenn die Vorschriften sich ändern - und zwar rechtzeitig zum Inkrafttreten. Wie schnell das nötig sein kann zeigt ein Bericht der Berliner Zeitung. Ihm zufolge dauert es im Durchschnitt 231 Tage bis ein Gesetz gültig wird. Klassische Change-Projekte dauern meistens deutlich länger, oft ein oder mehrere Jahre.

Selbst diese 231 Tage sind aber noch immer trügerisch lang. Zum einen ist es ein Durchschnittswert (es gibt also Abweichungen nach unten), zum anderen können während der Entstehung noch bis zur letzten Lesung signifikante Änderungen des bisherigen Standes eingebracht werden (eine Erklärung des deutschen Gesetzgebungsprozesses gibt es hier). Ein ähnlicher Fall von kurzfristigen Änderungen kann bei der Umsetzung von EU-Richtlinien entstehen, die durch ein so genanntes "Corrigendum" ergänzt werden können (wie im Fall der DSGVO geschehen).

Zuletzt bleibt immer noch das Risiko, dass die Auslegung einer bereits in Kraft getretenen Vorschrift sich durch ein Gerichtsurteil ändert, wie etwa im Fall des Urteils des Europäischen Gerichts zur Arbeitszeiterfassung. Ein gutes Beispiel für die weitreichenden Folgen, da zu seiner Umsetzung schlimmstenfalls komplette IT-Systeme neu zu konfigurieren oder sogar neu zu entwickeln und zu integrieren sind. Auch eine solche Situation erfordert schnelle Reaktionen um Rechtsunsicherheit und versehentliche Gesetzesverstösse zu vermeiden.

Der langen Rede kurzer Sinn: gerade in stark gesetzlich regulierten Bereichen ist agile Produktentwicklung nicht nur möglich sondern dringend nötig.

Donnerstag, 14. November 2019

Three Ways to break Hierarchy

Es ist eines der grossen Mantras nahezu jedes Agile Coaches: versucht nicht Spotify zu kopieren, das wird nicht funktionieren und nicht gut ausgehen, der Ansatz ist zu spezifisch und zu volatil. Inspirieren lassen kann man sich aber durchaus, zum Beispiel durch diesen Vortrag zum Thema der teamübergreifenden Koordination.



Und um es noch einmal ganz klar zu sagen: jeder der nach dem Ansehen dieses Videos reflexartig auch bei sich "Technical Steering Groups" und "Technology Architecture Groups" einführen will hat nichts, aber auch wirklich nichts verstanden.

Dienstag, 12. November 2019

Relativ erfolgreich

Bild: Pixabay / Engin Akyurt - Lizenz
Es war einer der seltenen Fälle in denen ich einen Transitionsbegleitungs-Auftrag abgebrochen habe. Trotz Schulungen, Lessons Learned-Prozessen und monatelanger Begleitung stürmte der IT-Chef noch immer die Plannings, liessen die Teams noch immer die Retrospektiven ausfallen und benutzten die POs noch immer die Backlogs als to do-Listen. Besserung war nicht in Sicht. Als "letzte Amtshandlung" machte ich eine Feedback-Runde mit allen Projektmitgliedern und bekam von einigen eine erstaunliche Rückmeldung: sie wären noch nie in einem so gut laufenden Projekt gewesen.

Da ich meine Aufgaben bereits übergeben hatte und nur noch auf letzte Bürokratieschritte warten musste nutzte ich die verbleibende Zeit um mit allen die sich so geäussert hatten vertiefende Gespräche zu führen. Am Anfang war ich verunsichert - waren mir Fortschritte entgangen? Hatte ich zu hohe Ansprüche angelegt? Wie konnte es zu einer derartig unterschiedlichen Wahrnehmung kommen? Die Antworten die ich bekam hätten auch von Albert Einstein kommen können. Natürlich wäre die agile Transition kein voller Erfolg gewesen, aber relativ erfolgreich, das schon.

Allen war zwar bewusst, dass sie in ihrem Arbeitsumfeld von erheblichen Dysfunktionen umgeben waren und dass Teile des Managements diese bewusst nicht abschaffen wollten (mehr zu den  dahinter legenden Beweggründen steht hier), im Vergleich zu dem was in der Vergangenheit in anderen Projekten passiert wäre wären die Verbesserungen aber unübersehbar: mehr Transparenz über den Arbeitsumfang, kürzere Planungszeiträume mit regelmässigen Anpassungen der bisherigen Pläne, engere Zusammenarbeit zwischen Entwicklung und Test.

Die Gegenüberstellung zeigt die unterschiedlichen Sichtweisen. In Relation zu meinem Agile Coach-Anspruch an eine Transition wurden wesentliche Elemente bewusst weggelassen: Pull-Prinzip, Inspect & Adapt, regelmässige Auslieferung von Kundenmehrwert. In Relation zu vergangenen Erfahrungen der Projektmitglieder waren aber einige der schlimmsten Zustände verschwunden oder zumindest erkennbar zurückgegangen: kryptische Anforderungen, lang andauernde Wasserfall-Phasen, starke Abkapselung der verschiedenen organisatorischen Silos.

Dementsprechend wurde auch der Erfolg unterschiedlich bewertet. Aus meiner Sicht war die agile Transition relativ erfolglos, da nach wenigen initialen Fortschritten der Verbesserungsprozess angehalten wurde und nicht wieder ans Laufen kam, aus der Sicht der anderen war er relativ erfolgreich, da diese Fortschritte zum besten Arbeitsmodus geführt hatten an den sich alle Beteiligten erinnern konnten. Wir konnten gegenseitiges Verständnis herstellen - die Anderen verstanden warum ich gehen wollte, ich verstand warum sie gerne blieben.

Rückblickend gehören die letzten Tage auf diesem Projekt zu den erkenntnisreichsten meiner Karriere. Erfolg und Misserfolg betrachte ich seitdem deutlich differenzierter, und wenn ich Einsätze beende fällt mir nicht mehr nur ins Auge wo noch Fortschritte fehlen sondern auch wo bereits welche gemacht wurden.

Samstag, 9. November 2019

Freiheit und Sinnhaftigkeit

Bild: National Guard / University of Minnesota IAS - Public Domain
Zeit für einen Blick über den Tellerrand. Am heutigen 9. November können wir den 30. Jahrestag des Mauerfalls feiern. Nach so langer Zeit dürften die damaligen Ereignisse für viele Menschen nicht mehr als eine Kindheitserinnerung sein - wenn sie damals überhaupt schon gelebt haben. Vielleicht macht es gerade deshalb Sinn ein bisschen über das zu reflektieren was damals passiert ist.

Zuerst eine kurze Anmerkung zur persönlichen Betroffenheit. Ich gehöre zwar zu den erwähnten Menschen die damals noch im Kindesalter waren (und wohnte damals nicht im Osten), mir waren aber später tiefere Einblicke in diese Zeit vergönnt. Während meines Studiums durfte ich eine Zeit lang in der Behörde der Bundesbeauftragten für die Unterlagen des Staatssicherheitsdienstes der ehemaligen Deutschen Demokratischen Republik, der BSTU, arbeiten, mit Zeitzeugen sprechen, Akten lesen und dabei helfen die Geschichte aufzuarbeiten.

Was mir aus diesen Akten, aber auch aus Gesprächen mit den Bürgerrechtlern der ehemaligen DDR in Erinnerung geblieben ist waren die Gründe für die Rebellion gegen das sozialistische Regime, die den Mauerfall auslöste. Neben sekundären Aspekten (Verwandte im Westen, Fehlen von hochwertigen Konsumgütern) waren es vor allem zwei die immer wieder genannt wurden: der Wunsch nach Freiheit und der Wunsch nach Sinnhaftigkeit, oder von der anderen Seite betrachtet die Ablehnung von Diktatur und Planwirtschaft.

Der Wunsch nach Freiheit erschliesst sich sofort. Die Bürger der DDR waren durch Mauer und Stacheldraht im eigenen Land eingesperrt und wurden regiert von einem diktatorischen Regime, das nicht durch Wahlen legitimiert war und abweichende Meinungen durch Zensur, Diskriminierung und Gefängnisstrafen unterdrücken wollte. Dass sich dagegen aufgelehnt wurde lässt sich problemlos nachvollziehen, ähnliche Reflexe dürfte jeder verspüren, der sich in derartigen Umständen wiederfindet.

Erst auf den zweiten Blick nachvollziehbar ist der zweite Grund für die Auflehnung, der Wunsch nach Sinnhaftigkeit. Bedingt durch die planwirtschaftliche Volkswirtschaft war jeder Bürger der DDR permanent von der dadurch verursachten Ineffizienz betroffen. Diese wirkte sich spürbar im Fehlen bestimmer Güter (z.B. Autos) aus, noch verheerender war allerdings die offensichtliche Unsinnigkeit der eigenen Arbeit. Dem Verrotten der Ernten, der Erstellung schlechter Produkte und der Bürokratisierung einfachster Abläufe waren die Menschen nicht nur ausgeliefert, sie mussten sich wider besseres Wissen an ihrer Herbeiführung beteiligen. Auch die Rebellion dagegen ist verständlich.

Dass die Bürger der DDR bereit waren im Kampf für Freiheit und Sinnhaftigkeit selbst Gefängnis, berufliche Diskriminierung und körperliche Gewalterfahrung in Kauf zu nehmen zeigt wie stark die Sehnsucht nach ihnen ist. Auch heute, 30 Jahre später, ist es sehr zu empfehlen sie nicht einzuschränken sondern gemeinsam mit den Menschen nach ihnen zu streben. Nicht nur in der Politik sondern auch in Wirtschaft und Gesellschaft.

Dienstag, 5. November 2019

Welches Scrum darfs denn sein?

Bilder: Flickr / Charlie / Royskeane - CC BY 2.0
"Wir machen Scrum" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat natürlich in vielen Fällen mit der freien Wahl der optionalen Bestandteile, mit Missverständnissen und mit Cargo Cult zu tun, selbst wenn man das weglässt bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Scrum, die sich z.T. deutlich unterscheiden:

Ur-Scrum

Die fast vergessene initiale Variante von Takeuchi und Nonaka, bzw. von DeGrace und Stahl. Nahezu alles was heute als Erkennungszeichen von Scrum Teams gilt fehlt hier noch. Keine Scrum Master, keine Product Owner, keine Sprints, keine Backlogs, keine Dailies, keine Sprint Reviews, keine Retrospektiven. Stattdessen findet sich vieles was heute eher zu den Grundlagen von Agilität gehört: crossfunktionale, stabile Teams, enger Kundenkontakt, Experimentier- und Fehlerkultur. In der Arbeitswelt kaum noch anzutreffen, mit Ausnahme von Teams die aus historisch interessierten Methoden-Nerds bestehen.

"Historisches" Scrum

Schon näher am "aktuellen" Scrum, aber noch nicht ganz da. Da Scrum regelmässig weiterentwickelt wird (seit 2010 im Rahmen des Scrum Guide) kommt es regemässig dazu, dass Teams auf einem älteren Entwicklungsstand stehen bleiben. Bei jüngeren Entwicklungen macht das kaum einen Unterschied, bei älteren kann der Unterschied deutlich sichtbar sein. Was z.B. noch immer verbreitet ist sind die "Pig" und "Chicken"-Rollen und verpflichtende Burndown Charts, aber auch andere "Relikte" kommen immer wieder vor. Vor allem in Teams oder Firmen anzutreffen die schon seit mehreren Jahren nach Scrum arbeiten.

Scrum by the Book

Der "Idealfall". Ist zu finden bei Teams die sich an der aktuellsten Form des Scrum Guide ausrichten und ihr Vorgehen nach jeder Aktualisierung anpassen (ob man auf dem aktuellsten Stand ist kann man mit Hilfe der Scrum Guide Revision History herausfinden). Voraussetzung ist, dass es mindestens ein Teammitglied gibt, dass sich über aktuelle Entwicklungen auf dem Laufenden hält und diese im Team einbringt (im Normalfall ist das der Scrum Master). Im weiteren Sinn gehören auch die Skalierungs-Frameworks LeSS (Large Scale Scrum) und Nexus zu dieser Kategorie, da beide Wert darauf legen kaum zusätzliche Prozesse und Strukturen einzuführen und stattdessen "Scrum auf sich selbst anzuwenden".

ScrumBut / ScrumAnd

Leider der Normalfall. Berechtigt oder unberechtigt gibt es in vielen Firmen die Überzeugung, dass Scrum by the Book dort nicht funktionieren würde. Die Folgen: Weglassungen (ScrumBut) und/oder Überfrachtungen (ScrumAnd). Zu bemängeln sind in derartigen Zusammenhängen vor allem zwei Dinge - zum Einen, dass der Begriff Scrum auch dann noch benutzt wird wenn wesentliche Voraussetzungen und Kernelemente entfernt wurden, zum Anderen, dass häufig die (irrationale) Erwartungshaltung vorherrscht trotz erheblicher Eingriffe noch immer den maximalen Umfang möglicher Verbesserungen erwarten zu können.

Verschlimmbessertes Scrum

Zum Glück ein zurückgehender Trend. Getrieben von falschem Verständnis oder von kommerziellen Interessen wurden ab ca. 2010 immer wieder scheinbare (und falsche) Widersprüche konstruiert. Scrum wäre ja toll, würde sich aber bestimmte Aspekte (z.B. Security) nicht berücksichtigen, wäre nicht geeignet für grosse Unternehmen, etc. Als Lösung wurden scheinbare Weiterentwicklungen wie Secure Scrum, Reliable Scrum, Ultra Scrum [sic], Scrum 2.0 oder Scrum 3.0 angeboten, die aber fast immer nur bürokratisierte oder verwässerte Abweichungen ohne erkennbaren Mehrwert sind. In gewisser Weise eine weitere Form von ScrumAnd. Ausschliesslich bei einzelnen Beratungsunternehmen zu finden.

Kastriertes Scrum

Der grosse zunehmende Trend der letzten Jahre. Seit etwa 2013 gibt es immer wieder Versuche Scrum in stark deskriptive oder Top Down-getriebene Projektmanagement-Methoden einzubinden. Die grosse Gemeinsamkeit - Scrum wird in diesem Zusammenhang nur als Arbeitsmodus einzelner Umsetzungsteams gesehen, die gleichzeitig nur ein untergeordneter Teil von grösseren Planungs- und Kontrollstrukturen sind (bekanntestes Beispiel ist SAFe). Bedingt dadurch sind zwei der wichtigsten Eigenschaften nicht mehr gegeben: Product Ownership und Process Ownership. In gewisser Weise eine weitere Form von ScrumBut, aber mit Literatur, Zertifizierungen, Konferenzen, etc.

Scrum@Scale / Scrum the Toyota Way

Zwei relativ neue und in ihrer Entstehung eng verknüpfte Scrum-Varianten (Scrum@Scale ist ein Skalierungsframework von Scrum-Pionier Jeff Sutherland, Toyota Connected eine der ersten Firmen die es eingesetzt hat). Das Besondere an ihnen: anders als in den weiter oben genannten Skalierungsframeworks LeSS und Nexus wird das untere und mittlere Management nicht obsolet sondern organisiert sich selbst in "Meta-Scrum-Teams" (Produktmanagement) und "Scrum of Scrums-Teams" (Prozessmanagement). Für die Toyota-Kultur mit ihrem stark auf die Team-Unterstützung ausgerichteten Management-Stil sicher passend, spannend wäre ob es auch woanders funktioniert.

Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Scrum finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es sich über die Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Scrum" ist zu wenig Information um zu erkennen was genau da gemacht wird.

Donnerstag, 31. Oktober 2019

Kommentierte Links (LIV)

Bild: Unsplash / Compare Fibre - Lizenz
  • Christopher Laine: Advice to Product Owners from a Developer

  • Eigentlich sollte es nicht der Idealfall sondern der Normalfall sein, dass auch die Mitglieder der (Scrum-)Entwicklungsteams den Arbeitsprozess als etwas sehen das für sie wichtig ist, dessen Sinn sie verstehen und an dessen Verbesserung sie arbeiten. Viel zu häufig wird darin aber nur "das was der Scrum Master macht" gesehen. Christopher Laine scheint die positive Abweichung davon zu sein, seine Ausführungen zeigen, dass er sich gründlich mit der Frage beschäftigt hat was er von seinen Product Ownern erwartet und was nicht. Besonders hervorzuheben: er sieht es ausdrücklich als Aufgabe des Teams an, dem PO ehrliches Feedback und Hilfe zu geben falls dessen Berufsausübung zu wünschen übrig lässt. Das kann man gar nicht genug unterstreichen.

  • Piet Hadermann: The Cost of Waiting for Feedback in Software Development

    Apropos Entwickler die sich Gedanken um die Verbesserung von Arbeitsprozessen machen. Piet Hadermann gehört ebenfalls dazu, und er hat sich eines wahren Klassikers angenommen - den negativen Effekten von zu viel Multitasking, bzw. den Möglichkeiten dem entgegenzuwirken. Seine naheliegenden Erkenntnisse: Work in Progress-Limits und Sofortbehebung auftretender Fehler können wirkungsvolle Massnahmen sein um die Entwicklungsgeschwindigkeit zu beschleunigen. Aber auch weniger naheliegende Erkenntnisse sind dabei. Dass auch kurze Sprints mit unveränderbarem Inhalt eine Form der Work in Progress-Limitierung sind ist eine Einsicht die viele Teams noch nicht haben. Und neben all diesen ernsten Themen enthält der Artikel auch noch zwei kleine Comics, von denen einer lustig und einer sogar wirklich witzig ist.

  • Carolin Wahnbaeck: Wo Zara und H&M zu langsam sind

    Man könnte lange darüber diskutieren ob das was Carolin Wahnbaeck in diesem Artikel beschreibt Lean Management, Business Agility, beides oder etwas ganz anderes ist. Viel wesentlicher ist: die "Ultrafast Fashion Companies" haben es offensichtlich geschafft eine Time to Market zu erreichen die deutlich unter einem Monat liegt - und das nicht etwa in der IT sondern in der Textilproduktion. Die dafür angewandten Erfolgsrezepte scheinen zunächst schlicht und bekannt - Optimierung der Lieferketten, Aufgreifen von Trends und Reagieren auf Änderungen der Nachfrage. Wer jemals versucht hat daran zu arbeiten weiss aber, dass dafür ein erheblicher Aufwand nötig ist. Bemerkenswert auch ein Nebenaspekt: da weniger unverkaufte Kleidung weggeworfen wird kann Ultrafast Fashion sogar umweltschonend sein.

  • Dave Snowden: Separated by a common language?

    Zu den (agilen) Frameworks die mich seit Jahren faszinieren gehört die Cynefin. Dass rund um etwas scheinbar so Schlichtes eine solche Menge an Ideen, Praktiken, Erläuterungen und Anwendungen entstehen kann ist bemerkenswert. Das ist besonders dann gegeben wenn dabei auch noch eine "Sekundärerkenntnis" entsteht, so wie in diesem Fall. Dave Snowdens Abgrenzung von Cynefin zur äusserlich ähnlichen aber inhaltlich völlig anderen Stacey-Matrix ist an sich schon interessant, der zusätzliche Aha-Effekt kommt aber dadurch zu Stande, dass er en passant erklärt, dass besagte Stacey-Matrix in Wirklichkeit gar nicht so aussieht wie allgemein angenommen. Das was meistens so bezeichnet wird ist eine vereinfachte Version, die Zimmermann-Matrix. Wieder etwas gelernt.

  • John Clopton: The Scrum is for Projects, Kanban is for Maintenance Myth

    In der Tat ein verbreiteter Mythos, und ein irreführender dazu. Dass Scrum eher zur Anwendungsentwicklung passt und Kanban eher zum Anwendungsbetrieb ist eine Aussage an der man erkennen kann, dass diese Konzepte nur oberflächlich verstanden wurden. John Clopton übernimmt die ehrenvolle Aufgabe die Dinge wieder geradezurücken..

Montag, 28. Oktober 2019

Erosion

Bild: Wikimedia Commons / Thomas Wilken - CC BY-SA 3.0
Vermutlich war es eine der interessantesten Diskussionen mit denen ich in letzter Zeit beteiligt war: was ist die häufigste Art der Abschaffung von agilen Transitionen oder Arbeitsweisen? Eine spontane Management-Entscheidung alles bisher Erreichte rückgängig zu machen? Eine bewusste Verfälschung oder Überladung der Methodik? Versehentlicher Murks? Widerstand der Mitarbeiter? Über-Optimierung? All das kommt vor, und doch glaube ich, dass ein anderes Phänomen häufiger ist - Erosion.

Unter Erosion (von lateinisch erodere, "abnagen") versteht man in der Geologie das langsame Abtragen von Erde oder Gestein durch Regen und Wind. Dieser Prozess verläuft aufgrund seiner Kleinteiligkeit und Langsamkeit nahezu unsichtbar - nach und nach verschwinden so kleine Mengen von der Oberfläche, dass der Effekt nur über Langzeitbeobachtungen feststellbar ist. Im Vergleich weit auseinanderliegender Zeiträume ist der Unterschied aber offensichtlich: von einstmals massiven Bergen und Felsen ist nicht mehr viel übrig.

Im übertragenen Sinn lässt sich Erosion auch in Organisationsformen betrachten. Am Anfang beginnt es meistens harmlos, fast unscheinbar. Die Timeboxes dauern ein bisschen länger als geplant, die Punkte auf den Zetteln werden manchmal vergessen, bei "offensichlichen" User Stories wird auf den Zwecksatz verzichtet, etc., etc., etc. Die Gemeinsamkeit mit der geologischen Erosion: auch hier erscheint jede einzelne Abtragung so klein, dass es sich kaum lohnt über sie zu reden. Und tatsächlich - ist es wirklich von Bedeutung wenn das Daily Standup 19 Minuten dauert statt 15?

Die zunächst un-intuitive Antwort: ja, es ist von Bedeutung, und zwar von grosser. Die vielen kleinen, scheinbar unbedeutenden Regelverletzungen haben Folgen. Wenn begonnen wird Vereinbarung zu verletzen schwindet mit jedem mal die Hemmung es erneut zu tun (Broken Window-Effect), wenn sich diese Regelverstösse als "pragmatisches Vorgehen" etablieren erfolgt dadurch eine Erziehung zur Normverletzung und wenn sich auch diese ohne Widerspruch ausbreitet droht als Endzustand der Konzern-Anarchismus. Und selbst wenn es kleinlich klingt - all das entsteht durch für sich genommen kaum erwähnenswerte Abweichungen.

Um nicht am Ende dieses Erosionsprozesses mit einem abgenagten Rest des ursprünglich agilen Prozesses dazustehen empfiehlt es sich regelmässig in Retrospektiven darüber zu refektieren ob das Erodieren schon irgendwo begonnen hat. Und sollte das der Fall sein ist es hochgradig sinnvoll sich gemeinsam Gegenmassnahmen zu überlegen, durch die verhindert wird, dass die gemeinsame Arbeitsgrundlage langsam weiter wegbröckelt.