Montag, 31. August 2020

Kommentierte Links (LXV)

FS
  • Adam Tooze: The Sociologist Who Could Save Us From Coronavirus

    Wieder einer dieser Momente in denen mich die Vergangenheit als Geisteswissenschaftler einholt. Das Buch Risikogesellschaft von Ulrich Beck habe ich im Studium gelesen, dann aber irgendwo zu weit im Hiterkopf abgelegt um noch daran zu denken. Vermutlich zu Unrecht. Wie Adam Tooze hier sehr schön herausarbeitet ist Beck heute noch hochaktuell. Bei ihm bezieht sich das auf die Weltlage, aber es lässt sich auch auf die Entwicklung komplexer Produkte übertragen: um Neues zu schaffen und Bestehendes zu erhalten gehen die Menschen permanent Risiken ein, weil anders Modernität und Fortschritt nicht mehr erreichbar sind. Diese treten dann zum Teil ein und werden ausgeglichen, wobei neue Risiken entstehen und in Kauf genommen werden. Ein etwas anderer aber hochinteressanter Zugang zur Untersuchung von Komplexität.

  • Barry O'Reilly: How to Implement Hypothesis-Driven Development

    Zu den Buzzwords die sich in der agilen Bewegung festgesetzt haben gehört auch die Hypothese. (Unbewusst?) aufbauend auf den Kritischen Rationalismus soll dieser Begriff anzeigen, dass alles was wir über Märkte, Kunden und Benutzer zu wissen glauben lediglich Annahmen sind, die validiert werden müssen um eine wirkliche Aussagekraft zu haben. Angelehnt an die legendäre User Story-Schablone hat Barry O'Reilly etwas Vergleichbares für Hypothesen entworfen.
    • We believe <this capability>
    • Will result in <this outcome>
    • We will have confidence to proceed when <we see a measurable signal>
    Wie bei der User Story-Schablone besteht zwar auch die Hypothesen-Schablone das Risiko einer Abdriftung in den Methodismus, für noch ungeübte Anwender kann sie aber eine Erinnerungshilfe sein durch die sich verhindern lässt, dass Annahmen als zu selbstverständlich betrachtet werden oder nicht validiert werden.

  • Steve Denning: Understanding What Good Agile Looks Like (Teil 1, Teil 2)

    Da wir von (scheinbar) einfachen Anleitungen reden - auch diese Artikel von Steve Denning enthalten eine (hier in zwei Versionen direkt verlinkt), in diesem Fall um zu überprüfen ob eine Firma klassisch oder agil strukturiert ist. Das was sie von anderen derartigen Prüflisten unterscheidet ist, dass sie sich nicht auf Implementierungsdetails konzentriert, etwa ob alle Teams nach Scrum arbeiten, sondern stattdessen aufeinander aufbauende Ebenen identifiziert und ihnen Erkennungsmerkmale zuordnet. Das sind zum Beispiel auf der obersten Ebene Unternehmensstruktur und Erfolgs-Definition, auf der mittleren Budgetierungs- und HR-Prozesse und auf der unteren Arbeitseinstellungen und Umgangsformen. Der Anspruch dieser Liste ist es, alles auf richtig verstandene Agilität überprüfbar zu machen, vom eigenen Unternehmen über Beratungs-Dienstleistungen bis zur Management-Literatur. Ob das durchgehend realistisch ist kann man dahingestellt lassen, eine wertvolle Inspiration ist es aber auf jeden Fall.

  • Mark Gray: The Definitive Guide to Burn-down Charts

    Ein schöner Artikel über die möglichen Vor- und Nachteile die sich aus der Verwendung von Burndown-Charts (die ja eines der klassischen Erkennungsmerkmale von Scrum sind) ergeben. Bemerkenswert ist hier vor allem ein Vergleich von sechs derartigen Charts (etwas weiter unten im Text) die sich zwar alle auf den selben Arbeitsstand beziehen, sich aber z.T. deutlich unterscheiden, je nachdem was da "heruntergebrannt" wird. Im dazugehörigen Text erfolgt auch die Erklärung welche dieser Messtechniken man benutzen sollte und welche besser nicht. Kurz zusammengefast: erzeugten Mehrwert und fertig integrierte Arbeitspakete in Burndown-Charts darzustellen ist eine gute Idee, vorher geschätzte Restaufwände und unintegrierte Arbeit erzeugen dagegen in derartigen Darstellungen keine verlässlichen Werte.

  • Kaluhi Anzigale: What Happens When Agile Goes Away?

    Zum Schluss eine Fallstudie. In einer Geschichte die sie selbst miterleben durfte erzählt Kaluhi Anzingale von einer Firma die versucht hat sich durch das Einsparen agiler Rollen und Praktiken profitabler zu machen. Ein Happy End gibt es nicht, die Einsparungen wurden durch die negativen Effekte mehr als ausgeglichen. Dass es nicht viele derartige Studien gibt ist nachvollziehbar, denn wer will schon sein Missmanagement laut verkünden? Um so wertvoller sind Texte wie dieser.

Donnerstag, 27. August 2020

Lean, Agile und der Markt für Zitronen

FS
Bild: Pikist - CC0 1.0

Die 1970 erschienene Studie The Market for Lemons: Quality Uncertainty and the Market Mechanism von George Akerlof gehört zu den grossen Klassikern der Wirtschaftswissenschaften. Am Beispiel scheinbar fehlerfreier, tatsächlich aber mangelhaft konstruierter Autos (in der amerikanischen Umgangssprache "Lemons", d.h. Zitronen genannt) glaubte er, eine Dysfunktion des Marktes nachweisen zu können: da Lemons im Vergleich zu fehlerfreien Autos billiger in der Herstellung aber gleich profitabel im Verkauf waren ging er davon aus, dass die Hersteller diese Fehler ihren Kunden bewusst verschweigen und damit eine Abwärtsspirale aus immer stärker nachlassender Qualität verursachen würden.


Bemerkenswerterweise erwies sich Akerlofs Analyse sowohl als richtig als auch als falsch - während es bei den amerikanischen Herstellern tatsächlich zu den von ihm beschriebenen Effekten kam war nicht etwa eine dauerhafte Abwärtsspirale die Folge sondern der Markt reparierte sich selbst. Genervt von der schlechten Qualität wandten sich die amerikanischen Kunden ausländischen Autos zu, die mit deutscher Wertarbeit oder japanischem Jidōka gebaut wurden. Um keine weiteren Marktanteile zu verlieren mussten die amerikanischen Firmen jetzt auch in Qualität investieren.


Wer in der IT arbeitet wird die Parallelen erkennen - auch hier wurde und wird Software produziert die "von Aussen" gut aussieht aber "unter der Motorhaube" Mängel hat, etwa in Form von Bugs, fehlender Lastfähigkeit, langsamer Erweiterbarkeit, schlechter Wartbarkeit, etc. Und auch hier ist es so. dass die Kunden derartige Anbieter abstrafen indem sie zur Konkurrenz wechseln, etwa vom Internet Explorer zu Chrome oder von StudiVZ zu Facebook. Und auch die Lösungen sind vergleichbar.


Die Methoden mit denen die japanischen und deutschen (und später auch amerikanischen) Firmen daran arbeiteten weniger Fabrikationsfehler entstehen zu lassen bilden heute noch die Grundlage von Lean Management und Agiler Softwareentwicklung: Probleme in der Verarbeitung sollen durch KVP, Kaizen und Inspect & Adapt möglichst früh entdeckt werden, sobald das geschehen ist wird der Verarbeitungsprozess angepasst. Fehlerhafte Auslieferungen gibt es damit immer weniger, und damit auch kaum noch Versuchungen sie aus Profitgier zu ignorieren.


Natürlich gibt es in der Umsetzung Unterschiede zwischen Auto- und IT-Industrie. Während in den immergleichen Abläufen einer Fertigungsstrasse der Automobilfertigung eine möglichst starke Standardisierung von Qualitätssicherungsschritten entlang der gesamten Wertschöpfungskette angestrebt wird steht in der IT mit ihrer Prototypen-Fixierung eine möglichst individuelle Qualitätssicherung möglichst früher Produktumfänge im Vordergrund. Das Ziel bleibt allerdings das Gleiche: Fehler verhindern bevor sie entstehen.


Letzten Endes schliesst sich hier ein Kreis: das grösste selbstorganisierte System der Welt, der freie Markt, bringt hohe Qualität hervor indem er sich der kleinsten selbstorganisierten Einheiten, der agil oder lean organisierten Produktteams bedient. Und beide basieren auf möglichst früher und transparenter Informationserhebung und Kundenkommunikation. Mit anderen Worten - der Markt für Zitronen verschwindet.


Sogar eine finale Pointe hält diese Geschichte bereit: 2001, im selben Jahr in dem Akerlof für The Market for Lemons den Wirtschafts-Nobelpreis erhielt verfassten siebzehn damals noch unbekannte Software-Entwickler in einer Hütte in den Rocky Mountains das Manifest für agile Software-Entwicklung. Eine bessere Metapher für eine Zeitenwende ist kaum denkbar.

Montag, 24. August 2020

Der Vertrag über agile Produktentwicklung

FS

 

Bild: Pixabay / Edar - CC0 1.0

Zu den frustrierenden Erlebnissen die man im Rahmen agiler Projekte haben kann gehört die Vertragskeule. Das wäre ja alles schön und richtig mit Inspect, Adapt, Incremental und Iterativ heisst es häufig, der Vertrag wäre da aber leider sehr restriktiv. Was hierbei zu bedenken ist: derartige Situationen werden in der Regel nicht bewusst herbeigeführt sondern beruhen auf Unkenntnis der für agile Vorgehensweisen nötigen Vereinbarungen. Die in meiner Sicht wichtigsten Punkte für solche Vereinbarungen möchte ich im Folgenden zusammenfassen, basierend auf eigenen Erfahrungen und einigen Impulsen von Philipp Kühn (Verfasser des "agilen Teils" des Handbuchs der IT-Verträge).


Rollen

Vor allem dort wo es noch verbreitet klassische Aufbau- und Ablaufstrukturen gibt von zentraler Bedeutung. Dass der Scrum Master nicht der Projektleiter ist und man für eine gute Software-Architektur keinen Software-Architekten haben muss mag für den überzeugten Agilisten selbstverständlich sein, für den Vertragspartner ist es das ggf nicht. Das klar festzulegen kann verhindern, dass Konflikte und falsche Erwartungen überhaupt entstehen und unnötig Energie binden.


Abnahmen

Auch klare Vereinbarungen zur Art wie Abnahmen in einem agilen Arbeitsmodus ablaufen müssen können Missverständnisse vermeiden. Zum einen dürfen diese nicht mehr ganz am Ende erfolgen sondern kurzfristig, im gleichen Takt wie die Inbetriebnahmen (dazu gleich mehr), zum anderen muss klar werden, dass es sich bei ihnen nicht um den Abgleich mit Detailspezifikationen handelt sondern um Überprüfungen auf welche Weise ein abstrakt beschriebener Anwender-Mehrwert verwirklicht wurde.


Liefer- und Inbetriebnahme-Rhythmus

Ebenfalls ein klarer Bruch zu den klassischen Vorgehensweisen, auf den man sich klar festlegen sollte. Egal ob in Scrum und XP mindestens ein Release pro Iteration stattfindet oder ob ein Kanban-Team möglichst im Single Piece-Flow arbeitet und jedes neue Feature direkt auf Produktion bringt - allen Beteiligten muss von Anfang an klar sein, dass kurze Rhythmen zwingend nötiger Bestandteil von Agilität sind.


Mitwirkung

Passend zum letzten Punkt sollte auch geregelt werden in welchem Umfang und zu welchen Zeitpunkten wer verfügbar sein muss. Das betrifft zum einen die Mitglieder des Umsetzungsteams, die nach Möglichkeit in Vollzeit und dauerhaft verfügbar sein sollten, es betrifft aber auch die Vertreter von Kunden und Auftraggebern, die für die oben genannten Inbetriebnahmen, als Onsite Customer, als Berater oder für Abnahmen verfügbar sein müssen, und zwar regelmässig.


Vergütung

Nicht nur im Umfeld der Agilität ein zentrales Thema, hier aber besonders kompliziert, da sich der Arbeits- und Funktionsumfang nach Erkenntnisgewinnen ändern kann und soll. Im Agentur-Umfeld finden sich oft Festpreise für Sprintziele, in Festpreis-Grossprojekten kann man den Austausch von alten Arbeitspaketen gegen gleichgrosse neue ermöglichen. Möglichkeiten Time & Material-Verträge flexibler zu gestalten wären Preisschwellen für Mindestabnahmemengen oder Mengenrabatte.


Anpassung

Ein weiterer Bruch zu den üblichen Vorgehen. Vertragsänderungen sollten in einem agil arbeitenden Umfeld immer möglich sein. Der dafür passende Anlass wird sich zwar nicht im voraus regeln lassen, wohl aber, dass es grundsätzlich möglich ist, dass es jederzeit zur Diskussion gestellt werden kann und dass diese Diskussion dann auch geführt werden muss. Auch eine kurzfristige Verfügbarkeit der beteiligten Stellen (Recht, Einkauf, etc) kann vereinbart werden.


Mit diesen (und ggf. anderen) Punkten lassen sich Verträge so gestalten, dass sie besser zu den agilen Vorgehensmodellen passen als es bei klassisch gestalteten Unterlagen meistens der Fall ist. Was aber auch klar sein muss - in einem solchen Umfeld wird sich nie alles festlegen lassen, ab einem gewissen Punkt muss zwischen den Vertragsparteien ein Grundvertrauen bestehen. Das ist zwar nicht überall gegeben, andererseits ist dort wo es fehlt die Agilität auch nicht das Thema das als erstes angegangen werden sollte.

Donnerstag, 20. August 2020

Best Practices and Good Practices

FS
Bild: Pikrepo - CC0 1.0

 


Wer schon immer einen lebhaften Kurzmonolog von einem Agile Coach hören wollte hat eine einfache Möglichkeit ihn herbeizuführen. Alles was man dafür tun muss ist ihn zu fragen was denn die üblichen Best Practices sind die er in seinem Beruf kennt und empfiehlt. Die Antwort wird fast immer die Gleiche sein: Best Practices gibt es in einem agilen Umfeld nicht, da sie grundsätzlich nicht zum Gesamtkonzept passen würden. Allenfalls Good Practices würden vorkommen, und die wären etwas völlig anderes.

 

Dass so argumentiert wird hängt mit grundlegenden Glaubenssätzen und Überzeugungen zusammen auf denen sich das Konzept der Agilität begründet. Ihnen zufolge ist jedes komplexe Vorhaben ständig mit dem Problem konfrontiert, dass die ursprüngliche Planung nach einiger Zeit nicht mehr für die zu lösende Aufgabe geeignet ist und per Inspect & Adapt angepasst werden muss. Da aber eine Best Practice schon von der Benennung her eine nicht mehr anzupassende Vorgehensweise ist (sie ist ja bereits die Beste) passt sie nicht in dieses Denkmodell.

 

Bei näherer Betrachtung zeigt sich auch, dass diese Glaubenssätze durchaus eine Fundierung haben. Alleine die jeweils unterschiedlichen Anwendungskontexte lassen es schwer vorstellbar scheinen, den einen richtigen Weg zu finden. Die Ablösung einer 30 Jahre alten ERP-Software und die Neuentwicklung eines Betriebssystems für eine Mondrakete mögen beides komplexe IT-Vorhaben sein, ideale Praktiken die für beides passen wird es aber nicht viele geben.

 

Auch die Unbeständigkeit der Umgebungsfaktoren spricht gegen universell gültige Best Practices. Alleine die Entwicklung immer neuer Endgeräte (Laptops, Handys, Tablets, Brillen, Uhren) verändert auch ständig die Art wie Technologien entwickelt werden, Ähnliches trifft für auch Architekturparadigmen und Nutzungsgewohnheiten zu und wird bei näherer Betrachtung auch für viele andere Aspekte zutreffend sein.


Selbst all das zusammengenommen tritt aber in den Hintergrund wenn man es mit dem grössten Problem vergleicht, dass das Konzept der Best Practice mit sich bringt - es ist zutiefst subjektiv. Alleine der Versuch bestimmte Sachverhalte als objektiv richtig zu bezeichnen kann ganze Generationen von Wissenschaftlern in Streitigkeiten stürzen, von diesen dann auch noch einen als "den Besten" auszuwählen kann eigentlich nur scheitern, und zwar bereits lange vor dem ersten Umsetzungsversuch.


Allerdings: die vollständige Verneinung jeglicher Richtlinien ist auch keine Lösung, zumindest nicht ausserhalb sehr radikaler philosophischer Denkrichtungen. Selbst wenn man sich theoretisch alles selbst erarbeiten könnte wäre der damit verbundene Aufwand unverhältnismässig hoch und die dafür erforderliche Zeit unverhältnismässig lang, ganz zu schweigen von der wirtschaftlichen Unsinnigkeit der redundanten Erarbeitung bereits errungener Erkenntnisse.


Die Lösung besteht aus den oben genannten Good Practices. Sie haben sich in bestimmten Kontexten und zu bestimmten Zeitpunkten als passend erwiesen, erheben aber keinen Absolutheitsanspruch, weshalb man sie problemlos überprüfen, anpassen und ggf. sogar verwerfen kann. Für das agil-typische Inspect & Adapt sind sie damit sehr gut geeignet. 

 

Nur eines kann die Verwendung von Good Practices statt Best Practices dem Anwender nicht ersparen: den Kurzmonolog des Agile Coaches. Sobald der dieser diese differenzierte Herangehensweise irgendwo vorfindet wird er sich zwar nicht mehr kritisch äussern, dafür aber in ähnlichem Umfang seiner Begeisterung freien Lauf zu lassen. Zu Recht.

Montag, 17. August 2020

Digitalisierung (III)

FS

 

Bild: JBSA / Zachary Bumpus - Public Domain

Zu den verwunderten bis spöttischen Reaktionen auf die in nahezu allen grossen Unternehmen und Behörden laufenden Digitalisierungsprogramme gehört die Frage warum es denn heute noch einen Bedarf dafür geben würde. Sollte die Digitalisierung von Büro- und Datenhaltungsprozessen nicht schon seit Jahrzehnten abgeschlossen sein? Die Antwort: leider nein, und aktuelle Ereignisse lassen erkennen auf warum das so ist.

 

Eine in den letzten Tagen durch die Medien gegangene Meldung handelte von fehlender Digitalisierung: an Urlaubsrückkehrern durchgeführte Krankheits-Tests fanden direkt an den Grenzen statt, wobei die Dokumentation von Kontaktdaten und Test-IDs auf Notizblöcken erfolgte. Diese Daten in die Systeme der Gesundheitsämter zu übertragen war aufwändig und manchmal wegen unleserlicher Schrift unmöglich, weshalb hunderte Menschen nicht von ihrer Erkrankung erfuhren


Die Gründe dafür, dass hier keine digitalisierte Datenerfassung stattfand sind schnell zu erkennen - die dafür notwendige Hardware hätte zuerst gekauft und die dazugehörige Software programmiert werden müssen, die Geräte hätten verteilt werden müssten und das Personal müsste geschult, und das alles unter immensem Zeitdruck, da die Ferienrückreiseverkehr sich nicht verzögern liess. Das manuelle Festhalten dürfte trotz der Probleme das Schnellste und Beste gewesen sein was so schnell machbar war.


Und selbst wenn derartige Behelfslösungen durch den Einsatz digitaler Techniken ersetzt werden ist der Digitalisierungsprozess dadurch nicht zwingend abgeschlossen, das zeigt eine andere Meldung: in anderen Testzentren gingen Dokumente zwar auf digitalem Weg ein, allerdings mit einer veralteten, eher für Einzelfallnutzung gedachten Software. Die Folge: mehrere tausend verschiedene Dokumente hatten den identischen Dateinamen "Telefax.pdf" und mussten einzeln gesichtet und umbenannt werden.


Auch hier kann man den Hintergrund verstehen - eine modernere Software wäre zwar erstrebenswert gewesen, deren Entwicklung ist aber noch nicht abgeschlossen. Die Fax-Schnittstelle dagegen existiert bereits und ermöglicht eine zwar umständliche, im Vergleich zur manuellen Erfassung aber deutlich schnellere Datenerfassung, mit der man erstmal anfangen konnte. Das Ergebnis ist eine schrittweise Digitalisierung: erst der Posteingang, dann die Benennung, dann die Sortierung, etc.


Aus "agiler Sicht" sind diese Vorgehensweisen hochgradig sinnvoll. Statt lange auf ein fertig entwickeltes Stück Software zu warten kann man mit einfachen aber schnellen Lösungen erste Erfahrungen sammeln, die Erkenntnisse in die parallel verlaufende Weiterentwicklung einfliessen lassen und dadurch am Ende bessere Ergebnisse haben. Um ein letztes mal die deutsche Seuchenbekämpfung zu nennen: dieser Ansatz wird hier genutzt und vom Ausland als vorbildlich empfunden.


Das Risiko ist allerdings, dass an irgendeinenem Punkt die noch nicht digitalisierten Prozesschritte in Relation zu anderen Aufgaben so unwichtig erscheinen, dass sie "wegpriorisiert" werden. Diese Restbestände sind es, wegen denen viele Digitalisierungsprogramme auch nach Jahrzehnten noch nicht abgeschlossen sind.

Donnerstag, 13. August 2020

Harvesting Value from Change

FS

Ein Grossvater sitzt auf seinem Sofa und gibt einige Weisheiten aus seinem Erfahrungsschatz preis. Das klingt nach nicht viel, ist aber auf ganz erstaunliche Weise fesselnd, tiefgreifend und charmant. Und das Besondere: Es funktioniert auf verschiedenen Ebenen - es lohnt sich nicht nur für Experten aus den Bereichen IT und Change Management sondern auch für Menschen die völlig neu im Thema sind.


 

Tatsächlich ist dieser Vortrag von GeePaw Hill derartig voll mit Informationen und Inspirationen, dass es sich lohnt ihn mehrfach anzusehen. Wie man auf Englisch sagen würde: It keeps on giving.

Montag, 10. August 2020

PMI goes Agile

FS
Screenshot: pmi.org


Zu den bei näherer Überlegung erstaunlichen Phänomenen im Umfeld der agilen Vorgehensweisen gehörte bisher das fehlende Engagement der klassischen Projektmanagement-Organisationen. Obwohl diese Art zu arbeiten immer weiter um sich greift und selbst zum Millionenmarkt geworden ist sind die klassischen Standardisierungs- und Zertifizierungs-Anbieter praktisch nicht wahrnehmbar. Noch weitgehend unbemerkt hat aber vor einigen Monaten ein Versuch begonnen das zu verändern.

Im Sommer 2019 wurde das Disciplined Agile Consortium, Besitzer des relativ unbekannten Skalierungsframeworks DAD (Disciplined Agile Delivery), vom Project Management Institute (PMI) gekauft. Das PMI, neben Axelos eine der beiden grossen internationalen Projektmanagement-Organisationen, hat in den folgenden Monaten vor allem an der internen Integration des Zukaufs gerarbeitet, seit Sommer 2020 ist aber auch von aussen erkennbar wohin die Reise gehen wird.

Aus dem neuen DAD-Bereich der PMI-Website lassen sich einige zentrale Weichenstellungen ablesen. Die vermutlich wichtigste: DAD (bzw. dessen Ableitung, die "Disciplined Agile Toolbox") wird explizit als Hybrid-Framework vermarktet, also als eines das auch Teile von klassischem Projektmanagement enthält. Das ist ein deutlich anderer Weg als der von LeSS, Nexus, Kanban University und SAFe, die alle den Anspruch erheben rein agile Methoden zu vertreten.

Eine weitere zentrale Entscheidung scheint zu sein, dass bewusst darauf verzichtet wird die Teams der Ausführungsebene als Scrum Teams zu bezeichnen. Das ist eine klare Unterscheidung zu LeSS, Nexus und SAFe und dürfte ein vorbeugender Befreiungsschlag gegen den Vorwurf sein, Scrum verkrüppelt oder nicht verstanden zu haben. Das dieser zu erwarten gewesen wäre ist angesichts der Team-Rollen offensichtlich - ganz klassisch gibt es hier den Teamleiter und den Architekten, zwar einen Product Owner aber dafür keinen Scrum Master.

Ebenfalls in ihren Auswirkungen nicht zu unterschätzen ist die PMI-typische Bereitschaft hochgradig umfangreiche Regelwerke zu schaffen. In seinem aktuellen Ausbaustand umfasst das DAD-Framework die vier Ebenen Delivery, DevOps, IT und Enterprise, in denen sechs verschiedene Produkt-Lebenszyklen abgebildet werden können: Agile, Lean, Agile Continuous Delivery, Lean Continuous Delivery, Lean Startup und Program. Dazu kommen Querschnittsorganisationen und Regeln und vieles mehr.

Interessant ist, dass DAD den Anspruch erhebt auf einer übergeordneten Ebene zu schweben, von der aus es alle anderen agilen und nicht-agilen Vorgehensmodelle als Baukästen nutzen kann um einzelne Elemente aus ihnen neu zu kombinieren. Diese versuchte Vereinnahmung dürfte zu ähnlichen Widerständen führen wie das vergleichbare Vorgehen von SAFe, wobei DAD ironischerweise auch SAFe lediglich als einen der besagten Baukästen aufführt.

Was zuletzt nicht fehlen kann sind die Zertifizierungen, die sowohl in der klassischen als auch in der agilen Arbeitswelt weit verbreitet sind. Hier ist am deutlichsten sichtbar, dass die Integration von DAD in das PMI noch nicht abgeschlossen ist. Auf der entsprechenden Übersichtsseite führen noch viele Links zu Einstellungs-Benachrichtigungen, Änderungsankündigungen oder Fahlermeldungen. Die einzige unveränderte Weiterführung scheint ausgerechnet (siehe oben) der Scrum Master zu sein.

Ob die PMI/DAD-Kombination sich am Markt durchsetzen wird ist natürlich noch nicht absehbar, als globale Organisation mit hunderttausenden Mitgliedern und hunderten lokalen Organisationen hat PMI aber eine gute Ausgangslage. Dem ersten Eindruck nach dürfte dabei vor allem SAFe der Konkurrent sein, die Positionierung und die Zielgruppe der beiden überschneiden sich stark. Es wird spannend zu sehen sein ob es hier zu einer Koexistenz oder zu einer Verdrängung eines der beiden kommen wird.

Donnerstag, 6. August 2020

Die Agile Framework-Matrix

FS
Es gibt Ideen von denen man direkt fasziniert ist. Diese hier von Dave Snowden gehört dazu.
Wie er selbst sagt ist sie in dieser Form nicht ganz ernstzunehmen, sie bietet aber einen guten Ansatzpunkt um weiter darüber nachzudenken ob und wie man die gängigen agilen Frameworks in eine zweidimensionale Matrix einordnen könnte und was sich danach mit dieser Einordnung machen lässt. Das Ziel dieser Übung: ein Werkzeug zu entwickeln mit dem sich Verständlichkeit und Anwendbarkeit überprüfen lassen.

Als erste Achse bietet sich definitiv das an was Snowden oben links die "kultgleiche, mystische Sprache" genannt hat. Wer schon einmal in einem agil arbeitenden Umfeld tätig gewesen ist wird wissen was er meint - über die Jahrzehnte hat sich hier eine Fachsprache aus verschiedensten Elementen gebildet (Sport-Metaphern, Management-Englisch, Japanisch, IT-Begriffe, etc.), die Vieles zu Beginn unnötig unverständlich macht. Eine geringe Ausprägung dieses Werts ist demnach gut, eine hohe schlecht.

Die zweite Achse ist schwieriger, da seine Benennung hier "leicht verkopft" ist. Um sich nicht im Versuch einer Definition von "ontologisch-epistemologisch" zu verlieren versuchen wir es mit einem Befreiungsschlag: wenn ein agiles Framework Erkenntnistheorie und Metaphysik notwendig macht ist vorher offensichtlich sein Beschreibungsumfang so ausser Kontrolle geraten, so dass er nicht mehr einfach fassbar ist. Ein geringer Umfang ist demnach gut, ein hoher schlecht.

Und mit diesen Festlegungen lässt sich die Matrix tatsächlich bauen, samt der ersten Framework-Einordnungen.
Um es auf den Punkt zu bringen: unten links in diesem Bild befinden sich die minimalistisch-einfach verständlichen Frameworks, oben rechts die aufgebläht-unverständlichen. Diese Einordnung ist natürlich nicht ohne subjektiven Einschlag, dürfte aber im Grossen und Ganzen so hinkommen.

Interessant ist noch Snowdens Idee, die Frameworks nicht als Punkte sondern als Pfeile darzustellen, also nicht nur ihre Position sondern auch ihre bisherige Entwicklung zu visualisieren. Das würde zwar etwas "historische Forschung" erfordern, würde aber auch die Option eröffnen Trends festzustellen, aus denen man Wahrscheinlichkeiten ableiten kann wie die Entwicklung vermutlich weitergehen wird.

Nachtrag:
Even more Food for Thougt

Montag, 3. August 2020

Ein Bild sagt mehr als 1000 Worte (XXIX)

FS
Powered by Blogger.