Freitag, 31. Mai 2019

Kommentierte Links (XLIX)

Bild: Unsplash / Compare Fibre - Lizenz
  • Steve Denning: Understanding Fake Agile

  • Der Titel dieses Artikels ist leicht irreführend, da Steve Denning in ihm nicht nur das beschreibt was er (zu Recht) als "Fake Agile" bezeichnet sondern auch Frühstadien und Mischformen die nicht unbedingt schlecht sein müssen. Im Einzelnen spricht er von den folgenden Typen:
    • Agile im Frühstadium
    • Etikettenschwindel-Agile
    • Agile nur in der Software-Erstellung
    • Angehaltene Agile Transition
    • Gebrandetes Agile
    • Skaliertes Agile (v. A. SAFe)
    • Agile light
    Besonders mit dem vorletzten Punkt hat er natürlich für Gesprächsstoff gesorgt, da er damit einen nicht unwesentlichen Teil aller sich als agil empfindenden Firmen angreift. Die Art wie denen mittlerweile gegenübergetreten wird wäre aber ein Thema für sich und geht über Dennings Artikel hinaus (siehe auch: Extremists and the hate SAFe machine).

  • Michael Küsters: It's still about agile teams

    Ein Text der auch als Reaktion auf Dennings Fake Agile-Artikel verstanden werden kann kommt von Michael und versucht sich an der Ehrenrettung von SAFe. In Anerkennung des Phänomens, dass ein Grossteil der SAFe-Implementierungen mit Agilität nicht viel zu tun hat weist er darauf hin, dass nicht alles was schlecht funktioniert auch schlecht gemeint ist. Vor allem mit dem ersten Punkt aus einer von ihm zusammengestellten Liste wiederholt auftretender Probleme dürfte er den Nagel auf den Kopf getroffen haben: SAFe wird als Management-Methode wahrgenommen und nicht als Ansatz der Produktentwicklung. In der Realität dürfte genau das die Ursache für die meisten fehlgeschlagenen Umsetzungen sein. Michaels Gegenmodell einer SAFe-Variante die die Entwicklung und Unterstützung der unteren Arbeits-, bzw. Teamebene in den Mittelpunkt stellt ist zwar idealistisch, in der Realität aber leider fast nicht existent.

  • Allen Helton: The 5 W’s of Rapid Prototyping

    Aus dem Grossen (der Skalierung) in Kleine. Rapid Prototyping ist eine Entwicklungsvariante die auch da Sinn macht wo von Agilität noch in den Anfängen steckt, die aber ebenfalls in fortgeschrittenen agilen Kontexten anzutreffen ist. Ähnlich wie ein MVP oder ein Proof of Concept ist ein Prototyp ein noch unfertiges Zwischenergebnis, mit dem schon erste Annahmen validiert oder erste Tests durchgeführt werden können. Agil wird diese Idee in Form des Rapid Prototype, was bei Allen Helton bedeutet, dass er innerhalb eines Sprints fertiggestellt werden kann. Anhand von Beispielen erläutert er wo ein solches Vorgehen Sinn macht, wie man es erreichen kann, was als Ergebnis herauskommen könnte und wer mitarbeiten sollte. Das klingt bei ihm erstmal einfach, ist es aber natürlich nicht. Ohne Produktvision, Nutzerverständnis und technische Exzellenz ist Rapid Prototyping nicht zu haben. Was aber auch zu beachten ist: selbst wenn man durch den Versuch einen Rapid Prototype zu bauen nur ein bisschen besser in diesen Bereichen wird ist auch das schon ein Gewinn.

  • Matthew Strom: Responsive Roadmaps

    Über die Gemeinsamkeiten von Product Roadmaps und geografischen Karten hatte ich schon mal etwas geschrieben, Matthew Strom denkt diese Idee aber nochmal in eine andere Richtung weiter. Angelehnt an die Darstellungsprobleme von Weltkarten zeigt er eine Fehlwahrnehmung auf die mit klassischen Roadmaps verbunden ist: statt sie als vereinfachte Darstellung zu sehen, aus der man für bessere Verständlichkeit einen Teil der Komplexität ausgeblendet hat, werden sie für ein repräsentatives Abbild der Realität gehalten. Sich derartig an ihnen zu orientieren würde aber genau so wenig ans Ziel führen wie eine Übersee-Navigation anhand einer Mercator-Karte. Sein Alternativvorschlag ist erkennbar an das Objectives and Key Results-Modell (OKR) angelehnt, was diesen Artikel aus noch einem anderen Grund lesenswert macht - es zeigt was man mit OKRs alles anfangen kann wenn man aufhört darin nur ein Instrument der Menschenführung zu sehen.

  • Stefan Barth: Wann muss das Management in agile Teams eingreifen?

    Noch einmal ein neuer Blick auf ein Thema über das ich schon einmal nachgedacht habe. Unter welchen Umständen darf ein Manager eingreifen und einem selbstorganisierten Team eben diese Selbstorganisation wieder wegnehmen? Die vereinfachte Antwort: wenn es Dysfunktionen entwickelt die so schwerwiegend sind, dass es sie selbst nicht mehr beheben kann. Dass Stefan das derartig offen anhand von (anonymisierten) Fällen aus der eigenen Firma bespricht ist einer der seltenen Fälle in denen offen über ein Phänomen gesprochen wird das häufiger ist als man denkt.

Dienstag, 28. Mai 2019

Ein Bild sagt mehr als 1000 Worte (XXV)


In einer besseren Welt wäre das ein Burndown-Chart geworden. Aber es hat nicht sollen sein.

Donnerstag, 23. Mai 2019

Frontline Staff driven Improvement

Normalerweise würde man die agilen Vorgehensweisen mit ihren kurzen Lern- und Feedbackzyklen und schnellen Reaktionen vor allem in der IT erwarten, wo sie auch bis heute schwerpunktmässig vorkommen. Beispiele für eine Umsetzung in einem anderen Umfeld gibt es trotzdem, und gerade wegen ihrer Ungewöhnlichkeit sind sie in vielen Fällen bemerkenswert. Der Grund dafür ist, dass den Beteiligten die gängigen Frameworks oft gar nicht bekannt sind, weshalb sie Vieles selbst entwickeln und so zu methodischen Innovationen beitragen. Ein derartiger Fall sind die Cleveland Kliniken, eine Krankenhauskette in den USA.



Was in diesem Video zu sehen ist, ist ein auf zweimal täglich stattfindenden "Huddles" (Standup Meetings) beruhender Verbesserungsprozess. Jedes Team führt sie für sich selbst durch, identifiziert hier Verbesserungspotentiale und arbeitet an ihrer Umsetzung. Als Umsetzungshilfe wird dabei ein selbstentwickeltes Improvement Model genutzt, das die Verbesserungsprozesse visualisiert und so vergleichbar und nachverfolgbar macht.

Da zwar viele aber nicht alle Probleme auf diese Art und Weise gelöst werden können kaskadiert der Prozess nach oben. Sobald die Teams der untersten Hierarchieebene sich besprochen haben geben sie die nicht selbst lösbaren Probleme an das zeitlich anschliessende Huddle der nächsthöheren Hierarchieebene weiter. Auch dieses löst möglichst viel davon selbst und gibt den Rest an die nächsthöhere Ebene weiter, die genauso verfährt. Da alle Huddles zeitlich begrenzt sind und aufeinander folgen sind die morgens auf den Stationen festgestellten Probleme spätestens Mittags dort angekommen wo sie gelöst werden können - selbst dann wenn das die oberste Geschäftsführung ist.

Mit diesen so genannten "Tiered Huddles" sind bei den Cleveland Kliniken bemerkenswerte Strukturen entstanden, die so auch in agilen Firmen nicht häufig zu finden sind. Vor allem die Kombination aus Subsidiarität und leichtgewichtigen Prozessen macht eine enorme Geschwindigkeit in der Abstimmung, Informationsübermittlung und Problemlösung möglich. Inspirierend.



Montag, 20. Mai 2019

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

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

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

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

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

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

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


Nachtrag 23.05.:
Ron Jeffries hat seine Gedanken in einem Artikel zusammengefasst. Verkürzt gesagt - statt Story Points empfiehlt er #NoEstimates.

Donnerstag, 16. Mai 2019

Modularisierung


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

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

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

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

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

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

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

Montag, 13. Mai 2019

Scrum in der Schule

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

Donnerstag, 9. Mai 2019

Retrospektiven-Ergebnisse

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

1. Action Items

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

2. Regeln

Ebenfalls sehr häufig vorzufinden. Anders als im Fall von Action Items ist der Umsetzungszeitraum von Regeln (meistens) nicht begrenzt, sondern sie gelten für immer - oder bis sie wieder abgeschafft werden. Im Scrum-Umfeld erfolgt die Umsetzung meistens im Rahmen der Definition of Done oder der Definition of Ready, aber auch in anderen Vorgehen können sie vorkommen, zum Beispiel indem man das Vier-Augen-Prinzip für alle Umsetzungen verpflichtend macht.

3. Anforderungen

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

4a. Apelle nach aussen

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

4b. Apelle nach innen

Ebenfalls eher unschön. Apelle nach innen gehören zur Kategorie "man müsste mal" und sind dementsprechend unspezifisch. Klassiker aus dieser Art der Retrospektiven-Ergebnisse sind Aufrufe besser zu kommunizieren, besser zu planen oder mehr auf Qualität zu achten. Alles nicht falsch, allerdings auch alles nicht wirklich validierbar. "Mehr", "Besser" oder ähnliche Begriffe sind so offen in der Auslegung, dass kaum zu sagen ist ob sie in ausreichender Weise erreicht wurden oder nicht.

5. Buffer / Slacktime

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

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

Montag, 6. Mai 2019

Code Ownership (IV)

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

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

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

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

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

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

Freitag, 3. Mai 2019

Ein Bild sagt mehr als 1000 Worte (XXIV)