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

Freitag, 31. Juli 2020

Kommentierte Links (LXIV)

FS
  • Jeff Gothelf: Working Backwards - A New Version Of Amazon’s “Press Release” Approach To Plan Customer-Centric Projects

  • Über den bei Amazon üblichen Ansatz Produkte und Anforderungen Form von Pressemitteilungen zu verfassen hatte ich letztes Jahr schon etwas geschrieben. Auch Jeff Gothelf sieht darin ein wichtiges Werkzeug, an dem er aber zwei Kritikpunkte sieht - eine zu starke Focussierung auf Output statt auf Outcomes und eine Vernachlässigung der Herausforderungen in der teamübergreifenden Zusammenarbeit. Er schlägt daher das folgende, veränderte, "Pressemitteilungs-Format" vor:
    1. What did you ship?
    2. What customer problems does it solve?
    3. How do you know the problem solved those problems?
    4. What business benefit has been achieved?
    5. Internal quote from someone involved or invested in this project and its success.
    6. Provide a customer quote sharing how this new product made them more successful or helped them achieve something.
    7. How did the team works together to achieve these results? What challenges did the team overcome to make the product successful?
    8. Provide a call to action.
    In dieser Form auf jeden Fall ein interessanter und vielversprechender Ansatz. Ob er ausserhalb von Amazon als Anforderungsbeschreibung ausreichend ist ist zwar diskutabel, aber ein Einsatz in Produktfindungs-Workshops dürfte definitiv eine Option sein.

  • Bob Emiliani: What Comes After Lean?

    Lean Management und Agile sind sich in vielem ähnlich, unter anderem auch in der häufigen Aussenwahrnehmung als vorübergehende Management-Trends (angesichts einer 70-jährigen, bzw. 30-jährigen Geschichte eine gewagte Annahme, aber das wäre ein anderes Thema). Bob Emiliani nimmt das zum Anlass für ein Gedankenspiel - was könnte wohl danach kommen (in seinem Fall nach Lean)? Vier Optionen fallen ihm ein:
    1. Es findet eine Ablösung statt durch einen neuen Ansatz, der die bisherigen Herausforderungen besser lösen kann
    2. Es werden so lange neue Ideen und Prinzipien integriert bis der aktuelle Stand nur noch eine kleine Teilmenge des grossen Ganzen bildet
    3. Die Herausforderungen ändern sich und getrieben dadurch entstehen neue Lösungsansätze (man beachte den Unterschied zu Option 1)
    4. Es folgt einfach nichts. Die ganze Idee methodischer Ansätze verschwindet
    Die spannende Frage aus "agiler Sicht": lässt sich dieses Gedankenspiel von Lean auf Agile übertragen? Ein gutes Thema für die nächste Grundsatz-Diskussion zwischen Agile Coaches (oder sogar für ein ganzes Barcamp).

  • Jason Little: Balancing the Push and Pull of Change

    Der Lean Change-Ansatz von Jason Little hat sich (zumindest im deutschsprachigen Raum) nie so ganz durchsetzen können, weshalb er trotz seiner mittlerweile mehr als zehnjährigen Geschichte noch immer das Potential hat neue Impulse zu liefern. Ganz im Sinn des Agilen Manifests sind auch hier mehrere Gegensatzpaare entwickelt worden an denen man sein Handeln ausrichten kann:
    1. Co-creation over getting buy-in
    2. Meaningful dialogue over broadcasting
    3. Cause & purpose over creating urgency
    4. Experimentation over executing tasks
    5. Response to change over resistance to change
    Genau wie im Fall des Agilen Manifests ist auch hier wichtig, dass sich nicht jeweils eine richtige und eine falsche Option gegenüberstehen, sondern dass beide ihre Berechtigung haben. Die Bevorzugung der linken Seite ist also eher als Richtlinie zu sehen und nicht als Dogma.

  • David Robson: Can you learn to navigate uncertainty?

    Zur Abwechselung mal ein Absatz ohne Aufzählungen. Was die BBC hier gemacht hat ist ein hochinteressantes Experiment. In einer gross angelegten Studie sollten über 7000 Teilnehmer versuchen mehrere Monate im voraus Voraussagen zu Ereignissen in unberechenbaren Umfeldern zu machen - zu Wahlergebnissen, Währungsschwankungen, Pandemie-Verläufen, aber auch zu Produkt-Neuheiten grosser Unternehmen. Das unerwartete Ergebnis: Laien machten bessere Voraussagen als Experten und jüngere Menschen machten bessere Voraussagen als ältere. Dem Anschein nach können Erfahrung und Expertise also schädlich sein wenn man versucht sich in einem volatil oder chaotisch verhaltenden Umfeld zurechtzufinden. Die Erklärungsansätze die sich aus der Studie ergeben sollten nachdenklich machen - Experten und Menschen mit grösserer Lebenserfahrung tendieren demnach dazu die eigene Kompetenz zu überschätzen und neigen dazu die Lösungen vergangener Probleme undifferenziert auf zukünftige zu übertragen. Im Selbstbild vieler Menschen dürfte das spürbare Kratzer hinterlassen.

  • John Cutler: Developer & Designer Collaboration (in the Real World)

    Grau ist alle Theorie, die Praxis ist bunt. Was John Cutler hier teilt ist eine der vielen Arbeitsablauf-Varianten die sich in der Realität nach und nach entwickeln, wenn Teams ihre Prozesse kontinuierlich optimieren. Scheinbar Wasserfall-artige Phasen lösen sich ab mit iterativem Arbeiten, zeitweise wird Arbeit parallelisiert, dann kommt es wieder zu teamübergreifendem Pairing. Die Moral aus dieser Geschichte: diese Abläufe sind in diesem (und nur in diesem) Kontext optimal - und ein erzwungener Einheitsprozess hätte zu suboptimalen Ergebnissen geführt.

Montag, 27. Juli 2020

Die drei Bedeutungen von (agiler) Skalierung

FS

Bild: Pikrepo - CC0 1.0

Die agile Skalierung gilt als eine der Königsdisziplinen der Agilität. Scrum oder XP mit einem Team zu machen ist heute nichts Ungewöhnliches mehr, auch zwei oder drei gehen noch - aber mit zehn Teams? oder zwanzig? Oder noch mehr? Das wird hart. Erklärungen für diese Wahrnehmung gibt es viele: steigende Komplexität, Parallelität der Ereignisse und Einbeziehung nicht-agiler Einheiten sind unter den häufigsten, hier soll es aber um einen anderen Erklärungsansatz gehen. In ihm scheitert alles bereits an der Kommunikation.

Die These - wenn verschiedene Menschen miteinander über agile Skalierung reden meinen sie damit oft völlig unterschiedliche Dinge und reden aneinander vorbei. Durch diese fehlschlagende Kommunikation entstehen Frustration, falsche Erwartungshaltungen und später dann Enttäuschungen durch die so nicht erwarteten oder anerkannten Ergebnisse. Was von aussen wie ein Organisationsproblem aussiert ist also in Wirklichkeit ein Verständnisproblem. Um dem auf den Grund zu gehen - welche Verständnisse sind das?

Verständnis Nr. I: agile Skalierung ist das Wachstum einer agil organisierten Einheit

Skalierung bedeutet in diesem Fall, dass eine agil operierende Einheit grösser wird - und dabei weiterhin agil bleiben soll. Die steigende Zahl der beteiligten Teams führt hier zu einem steigenden Koordinationsbedarf, der durch die sukzessive Einführung teamübergreifender Zusammenarbeitsformen bedient wird. Am Anfang z.B. mit einem Scrum of Scrums, später mit Release Trains, noch später mit Gilden, etc. Zum Verständnistyp I ist wichtig: solange das Wachstum anhält ändern sich auch die Zusammenarbeitsformen.

Verständnis Nr. II: agile Skalierung ist ein definiertes Zusammenarbeitsmodell

Wenn Manager zum ersten mal über agile Skalierung reden meinen sie meistens das: ein Regelwerk, das die einzelnen agil arbeitenden Teams umgibt und verbindet und in dem es wenn möglich für alles eine Rolle, ein Meeting, ein Quality Gate oder einen Prozess gibt. Häufig stecken dahinter SAFe oder ein "hauseigenes Hybrid-Modell", seltener LeSS, Nexus oder (Pseudo-)Spotify. Zum Verständnistyp II ist wichtig, dass meistens erwartet wird, dass er nach der Einführung "stabil läuft" und nicht mehr angepasst werden muss.

Verständnis Nr. III: agile Skalierung ist die ständige Anpassung eines Zusammenarbeitsmodells

Das was sich Agile Coaches unter agiler Skalierung vorstellen ist genau gegenläufig zum zuletzt genannten Typ: der Skalierungsansatz selbst soll Gegenstand agiler Vorgehensmuster sein, sich also permanent durch inspect & adapt an ändernde Rahmenbedingungen anpassen. Die Entwicklung neuer Zusammenarbeitsformen erfolgt damit explizit ergebnisoffen, einschliesslich der Möglichkeit Veränderungen wieder rückgängig zu machen. Zum Verständnistyp III ist wichtig: in ihm gilt es als Risiko wenn sich das Skalierungsmodell nicht ständig ändert.

Dass diese verschiedenen Verständnistypen zu Problemen führen können wenn sie nebeneinander existieren ist offensichtlich. Nur Typ I und Typ III sind kompatibel miteinander, Typ I und Typ III werden früher oder später in Konflikte laufen, Typ II und Typ III sind völlig inkompatibel. Selbst wenn diese unterschiedlichen Sichtweisen sich gegenseitig bekannt sind ist eine Vermittlung schwierig, wenn das nicht der Fall ist und jeder annimmt, dass sein Verständnis von den anderen geteilt wird, sind Konflikte unausweichlich.

Vor Beginn eines agilen Skalierungsvorhabens macht es also hochgradig Sinn, dass alle Beteiligten sich darüber unterhalten, was sie denn unter agiler Skalierung verstehen. Das erscheint naheliegend, findet aber leider nur selten statt.

Donnerstag, 23. Juli 2020

Value, Flow & Bottlenecks (& Visualization)

FS
Heute gibt es zwei kleine Videos (jeweils weniger als 10 Minuten) zu den Themen Value, Flow und Bottlenecks. Zum einen weil der Verfasser John Cutler darin viele sinnvolle Sachen sagt, zum anderen aber auch wegen der Visualisierungen, die in ihrem Minimalismus sicher irgendwie auf Flipcharts übertragbar sind. Ein Projekt für einen der nächsten Freitagnachmittage.



Montag, 20. Juli 2020

Stabile Teams

FS

Bild: Wikimedia Commons / Zossolino - CC BY-SA 4.0

"Ok, für das neue Projekt braucht es also ein Entwicklungsteam von fünf Personen, mal sehen. Einen könnten wir sofort zur Verfügung stellen, nur in einem Monat müssten wir ihn für einen Release drei Wochen rausziehen, in der Zeit kommt aber jemand als Vertretung. Zwei weitere könnten wir in zwei Wochen zur Verfügung stellen, aber nur bis zum Beginn des Weihnachtsgeschäfts. Dann stellen wir aber auch zwei Neue ein die sie ersetzen können. Die beiden letzten Stellen würden wir wechselnd besetzen, je nachdem welches andere Projekt gerade Leute entbehren kann."

Überlegungen wie diese kann man in vielen grossen Organisationen hören wenn neue Vorhaben geplant werden, und dass sie häufig vorkommen ist auch kein Zufall. Es sind zwei tayloristische Grundprinzipien deren Anwendung zu derartigem Ressourcen-Tetris führt: zum einen, dass eine möglichst hundertprozentige Auslastung aller Angestellten anzustreben ist und zum anderen, dass die Menschen auf der untersten Ausführungsebene ohne grosse Probleme austauschbar sind. In Frederick Taylors Stahlwerk mag das auch funktioniert haben, in der Wissensarbeit führt es aber zu Problemen.

Selbst wenn man ausser Acht lässt, dass alleine die Idee einer Vollauslastung hochproblematisch ist (mehr dazu hier) wird der Versuch der Ressourcenoptimierung in einem Wissensberuf wie IT, Marketing, etc. zu permanenten Effektivitätsverlusten führen. Der Grund: er lässt sich nur mit ständigem Neu-Zuordnen momentan untätiger Mitarbeiter zu den aktuell arbeitsintensivsten Vorhaben durchführen. Das erscheint zwar auf den ersten Blick sinnvoll, da so Untätigkeit vermieden werden soll. Auf den zweiten Blick fallen aber Probleme auf.

Am offensichtlichsten ist der Wegfall von Routinen und Erfahrungswerten. Wer sich ständig in neue Aufgabengebiete und Anwendungen hineindenken muss, die bisher von anderen bearbeitet worden sind, wird sich häufiger einlesen müssen, Fehler machen und diese korrigieren müssen. Falls die Folgen bereits gemachter Fehler mit zeitlichem Versatz auftreten kann es sogar nötig sein Reparaturen vorzunehmen ohne bei den ursächlichen Handlungen dabeigewesen zu sein, was das Ganze nochmal erschwert.

Ebenfalls naheliegend ist, dass häufige personelle Wechsel das Teambuilding deutlich erschweren. Dort wo ständig neue oder nur vorübergehend anwesende Kollegen in den gemeinsamen Runden sitzen wird sich nur schwer ein Gefühl der psychologischen Sicherheit einstellen. Und selbst wenn man diesen weichen Aspekt beiseite lässt bleibt noch das Problem, dass im Team getroffene gemeinsame Entscheidungen immer wieder verhandelt werden müssen wenn sich jeder daran gebunden fühlen soll.

Weniger offensichtlich aber in den Auswirkungen extrem weitreichend ist ein anderer Effekt: wenn sich das bedarfsgetriebene Hin- und Herschieben von Personal einmal etabliert hat wird es nicht nur dann stattfinden wenn jemand gerade nichts zu tun hat sondern auch dann wenn an einer anderen Stelle etwas zu tun ist das wichtiger ist als die aktuelle Tätigkeit. Die Folge ist ein Liegenbleiben und Aufstauen unerledigter Arbeit, mit der häufigen Folge dass nichts mehr richtig fertig wird und überall Behelfslösungen im Einsatz sind.

Um diese negativen Effekte zu vermeiden ist es sinnvoll stabile Teams einzurichten. Damit ist nicht gemeint, dass sich deren Zusammensetzung nie ändern darf, es bedeutet aber, dass nicht jede Unter- oder Überlastung sofort ein Grund für eine organisatorische Veränderung sein sollte. Dass dadurch keine hundertprozentige Optimierung der jeweiligen Arbeitszeiten mehr möglich ist sollte bewusst hingenommen werden, zum einen weil diese durch die Effektivitätsverluste mehr als ausgeglichen würde, zum anderen weil so Zeit zur Abarbeitung der liegengebliebenen Arbeit entsteht.

So naheliegend das auch erschent, für grosse Organisationen sind stabile Teams etwas hochgradig Ungewohntes, das sich nur schwer umsetzen lässt. Dort wo das Hin- und Herschieben zwischen Projekten, Taskforces, Stabilisierungsphasen und Sondereinsätzen Normalität ist sorgen stabile Teams nämlich zunächst für Störungen in den Abläufen - wer daran gewohnt ist in Stressphasen mehr personelle Unterstützung anfordern zu können wird es als Behinderung seiner Arbeit empfinden wenn das nicht mehr geht.

Um zu verhindern dass diese Stabilisierung direkt im ersten Belastungsfall weg-eskaliert wird ist eine Rückendeckung der höheren Entscheidungseben hilfreich. Und wenn diese zuerst überzeugt werden müssen - um so besser. Denn wer stabile Teams will sollte erklären können warum.
Powered by Blogger.