Donnerstag, 12. Dezember 2019

Ein Bild sagt mehr als 1000 Worte (XXVII)

FS

Montag, 9. Dezember 2019

Wer von agiler Skalierung spricht meint meistens etwas anderes

FS
Bild: Piqsels - CC0 1.0
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

FS
Bild: Pixabay / Ryan McGuire - CC0 1.0
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

FS
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 ddie 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)

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

    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

FS
Bild: Piqsels - CC0 1.0
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

FS
Bild: Pixabay / Assy - CC0 1.0
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.

Montag, 18. November 2019

Why agile: Gesetzliche Regulierung

FS
Bild: Unsplash / Patrick Tomasso - CC0 1.0
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

FS
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

FS
Bild: Pixabay / Engin Akyurt - CC0 1.0
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

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

FS
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. Ein Indikator dafür ist z.B. die (aktuell noch) neue Regel, dass das Sprint Backlog auch Massnahmen zur Prozessverbesserung enthalten sollte. 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 Skalierungsframeworks 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, Utra 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)

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

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

Donnerstag, 24. Oktober 2019

Logistische Intelligenz

FS
Mal wieder Gunther Dueck. Gewohnt eloquent werden die möglichen Dysfunktionen agiler Konzern-Transitionen aufgezählt und analysiert. Für meinen Geschmack etwas zu sehr focussiert auf die negativen Aspekte, aber trotzdem sehr unterhaltsam.

Montag, 21. Oktober 2019

Delivering twice the value at half the cost

FS
Bild: Flickr / Peter Linke - CC0 1.0
Einmal mehr hat sich der bekannteste Sales-Pitch von Scrum beinahe unbemerkt geändert. Bereits 2018 schwenkte Jeff Sutherland, der Verfasser von Doing twice the work in half the time um auf Delivering twice the value in half the time, aber auch das ist mittlerweile nicht mehr der neueste Stand. Der ist seit gestern Delivering twice the value at half the cost. Man kann das begrüssen, ähnlich wie die letzte hat auch diese Neuformulierung das Potential weniger missverständlich zu sein.

Da die bisherigen Formulierung nur in ihrem hinteren Teil verändert wurde soll es hier nur um den gehen (zum ersten Teil siehe hier), und zwar zunächst um die alte Version. Liefert Scrum tatsächlich in der Hälfte der Zeit? Die Antwort: nicht zwingend, genau das ist es was missverständlich ist. Ein Vergleich der unterschiedlichen Ansätze zeigt warum.

Zuerst zu Scrum: sein Anspruch ist, durch bessere Strukturen und Prozesse in kurzer Zeit lieferfähig sein. Zum einen bedeuten crossfunktionale Teams weniger Übergaben und weniger Koordinationsaufwand, zum anderen kann die Integration der Abnahme-, Integrations- und Regressionstests in jeden einzelnen Sprint die vor dem Projektende stattfindende Integrations- und Bugfixing-Phase entfallen lassen. Zusätzlich verhindert das schnelle Beheben der Fehler, dass diese sich gegenseitig verstärken und dadurch aufwändiger zu beheben sind. So verkürzt sich die Gesamtlaufzeit, wodurch das ursprüngliche Versprechen in half the time zustande kam.

Auf der anderen Seite stimmt aber auch: klassisches Projektmanagement kann "ambitionierte Lieferfristen" ebenfalls immer wieder erreichen, und zwar mit einer einfachen Massnahme. Diese besteht darin, dass zur Erreichung der gesetzten Ziele mehr Personal in das Projekt gepumpt wird1. Mit mehr Leuten kann dann versucht werden mehr zu schaffen, entweder durch parallele Arbeit gleichartiger Teams oder durch ein überlappendes Vorgehen der Teams die den unterschiedlichen Phasen zugeordnet sind. Es bleibt daher die Frage - wenn beide Ansätze schnell liefern können, macht der Umstieg auf Scrum überhaupt einen Unterschied?

Dass die Antwort darauf Ja ist liegt in den entstehenden Kosten begründet. Die Faktoren die in Scrum zu schnellem Arbeitsfortschritt beitragen sind im Gegensatz zum klassischen Projektmanagement nicht mit zusätzlichem Personalaufwand verbunden. Da dieser aber gleichbedeutend mit zusätzlichen Ausgaben ist bedeutet das, dass die Entwicklung im Vergleich billiger ist. Für praktisch jedes Vorhaben dürfte das ein wesentliches Argument sein, das Budget ist schliesslich in jedem Vorgehen ein entscheidender Faktor. Und damit erklärt sich auch die Sinnhaftigkeit der neuen Formulierung Delivering twice the value at half the cost.


1Dass dieses Vogehen zu anderen Problemen führen kann ist nochmal ein Thema für sich

Donnerstag, 17. Oktober 2019

Toyota Flow System

FS
Manchmal kommen grosse Neuigkeiten überraschend an. In einem zunächst eher unspektakulären Artikel erwähnt der Forbes-Journalist Steve Denning etwas Bemerkenswertes: nach 70 Jahren hat die Firma Toyota ihr legendäres Toyota Production System (den Ursprung des Lean Management) weiterentwickelt zu etwas Neuem, dem Toyota Flow System. Der Name ist fast gleich geblieben, der Inhalt dagegen hat sich spürbar verändert - es finden sich jetzt deutliche Spuren agiler Frameworks in ihm.

Grafik: Toyota Connected / Thurlow, Turner, Rivera - CC BY 4.0 (zum Vergrößern klicken)
Vor allem in der linken Säule taucht einiges auf was aus der agilen Welt bekannt ist. Scrum, the Toyota Way hat bereits 2018 für Aufsehen gesorgt, und auch andere bekannte Konzepte finden sich hier, etwa Cynefin und OODA-Loops. Die mittlere Säule greift eher Ideen aus dem Coaching-Umfeld auf, wie z.B. psychologische Sicherheit, aktives Zuhören und Mentoring, während die rechte Säule sich auf die sozialpsychologischen und organisatorischen Aspekte der Teamarbeit konzentriert. Zusammen mit den beiden Grundlagen Toyota Way und Toyota Production System kommt ein Gesamtbild zu Stande, dessen Einzelbestandteile es ermöglichen genug Lesestoff für Wochen zusammenzugoogeln. Auf jeden Fall spannend.


Nachtrag 07.11.2019
Passend zum Thema ein Video. Nigel Thurlow, Chief of Agile bei Toyota Connected, gibt einen Einblick in die agilen Arbeitsweisen seiner Firma:

Montag, 14. Oktober 2019

Frameworks und Werte

FS
Bild: Wikimedia Commons / ChinaFlag - CC0 1.0
Wer schon einmal in einem Workshop war in dem es darum ging agile Vorgehensmodelle zu erklären oder ihre Einführung vorzubereiten wird dort mit grosser Wahrscheinlichkeit auch über Werte gesprochen haben. Egal ob Extreme Programming (Communication, Simplicity, Feedback, Courage,  Respect), Scrum (Courage, Commitment, Focus, Openness, Respect) oder Kanban (Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement, Respect) - jedes bekannte Framework betont, dass es wertebasiert ist. Aber warum ist das so?

Die Antwort hat mit genau dieser Selbstbezeichnung zu tun. XP, Scrum & Co legen Wert darauf keine Methoden zu sein sondern Frameworks, wohinter sich ein völlig anderes Konzept verbirgt. Während durch Methoden relativ genaue Vorgaben erfolgen wer wann was mit welchem Ziel zu tun hat wollen die agilen Frameworks genau das vermeiden. Die darunterliegende Annahme: je strikter die Vorgaben desto unwahrscheinlicher, dass sie der komplexen Realität gerecht werden. Im Zweifel schaden sie sogar mehr als sie nutzen, da plötzlich der Plan nicht mehr zur Realität passt.

Um derartige Konstellationen zu vermeiden lassen die Frameworks bewusst grosse Lücken, die jeder so füllen kann wie er es für sinnvoll hält. Beispiele dafür sind Anforderungsformate und die Abnahmen fertiger Arbeit: XP, Scrum und Kanban gehen nicht darauf ein wie sie ausgestaltet sein sollen, jedes Team kann das für sich selbst festlegen. Das daraus entstehende Problem - diese Offenheit bringt das Risiko mit sich, dass versehentlich unflexible und bürokratische Strukturen (wieder)eingeführt werden, etwa indem besonders detaillierte Spezifikationen möglichst früh im voraus verfasst werden, die dann zu erfüllen sind.

Die Lösung für dieses Dilemma sind die zu Beginn genannten Werte. Sich im Zweifel an ihnen zu orientieren lässt den Beteiligten genug Freiraum um den Arbeitsprozess nach ihren Bedürfnissen auszugestalten, zeigt ihnen aber auch wo sie sich von der angestrebten Agilität entfernen. Um beim Beispiel der Abnahmen anhand von lange im voraus verfassten Detailspezifikationen zu bleiben - wer ernsthaft Simplicity, Openness und Balance als Werte verfolgt wird sich von diesem Vorgehen schnell verabschieden.

Um zuletzt einen häufigen Einwand aufzugreifen: natürlich bedeutet das auch, dass der Arbeitsprozess weniger stabil ist und häufiger geändert werden muss, nämlich immer dann wenn er sich aufgrund geänderter Realität plötzlich im Widerspruch zu den Werten befindet. Aber das ist etwas Gutes - es verhindert, dass die Menschen durch unnötige Vorgaben eingeengt werden.

Donnerstag, 10. Oktober 2019

Die agile Filterblase

FS
Bild: Flickr / Serge Melki - CC BY 2.0
Eine Frage die beim letzten bonner Scrumtisch intensiv diskutiert wurde war die: "Befindet sich die agile Community in einer Filterblase?" Natürlich lautet die Antwort im Zweifel immer "Kommt darauf an", aber ganz von der Hand zu weisen ist es nicht - eine Abkapselungstendenz ist da. In dem Punkt waren sich die Teilnehmer einig.

Zunächst zur Begrifflichkeit. Filterblasen sind ein Konzept aus der Kommunikationswissenschaft in dem davon ausgegangen wird, dass durch technische Mechanismen (personalisierte Suchmaschinen) bewussten Medienkonsum (Echokammer) oder unbewusste psychologische Vorgänge (Confirmation Bias) vor allem die Informationen wahrgenommen werden die die eigene Meinung bestätigen. Abweichende Ansichten werden ausgeblendet.

Auf die agile Community übertragen erkennt man deutliche Züge von Filterblasenhaftigkeit. Die bekannteren Agilisten gehen auf die gleichen Konferenzen, lesen die gleichen Autoren, hören die gleichen Podcasts, abonnieren die gleichen Youtube-Kanäle, folgen sich gegenseitig auf Twitter und Facebook und kennen sich untereinander schon seit Jahren. Das lässt sich sowohl auf der internationalen als auch auf der nationalen und lokalen Ebene beobachten und zeigt sich daran, dass viele der eigentlich fachlichen Zusammenkünfte mittlerweise einen Klassentreffen-Charakter haben.

Die damit verbundenen Effekte sind bedenklich: bestimmte Glaubenssätze werden kaum noch hinterfragt (z.B. "mittleres Management ist überflüssig"), bestimmte Vorzeigeunternehmen wie Spotify werden gehypt während andere wie Mercadona trotz hochinnovativer Ansätze nahezu unbekannt sind, die Berührungspunkte zu verwandten Disziplinen wie dem klassischen Projektmanagement nehmen ab, wichtige Themenfelder wie Finance oder Legal werden weitgehend ignoriert.

Das zu ändern liegt bei jedem Einzelnen selbst. Warum nicht mal auf eine Projektmanagement-Konferenz gehen, ein BWL-Buch lesen oder sich mit Lean Manufacturing beschäftigen? Und wenn das zu weit ausserhalb der eigenen Komfortzone ist - warum nicht auf dem nächsten Agile Meetup ein ungewohntes Thema einbringen wie Compliance, Budgeting oder Procurement? Das würde nicht nur zur Weitung des eigenen Horizonts führen sondern auch neue Teilnehmer anlocken. Auch so liesse sich die agile Filterblase öffnen.

Montag, 7. Oktober 2019

ScrumBut und ScrumAnd

FS
Bild: Flickr / David Molloy - CC BY 2.0
So schlicht Scrum auch ist, so viel kann man bei seiner Umsetzung falsch machen. Das meiste davon dürfte unbewusst passieren und den Handelnden gar nicht bewusst sein, also in die Kategorie fallen für die sich der schöne Name Cargo Cult eingebürgert hat. Es gibt aber auch Fälle in denen absichtlich am Vorgehen herumgedoktort wurde. Auch für die beiden hierbei möglichen Varianten gibt es mittlerweile Bezeichnungen: ScrumBut und ScrumAnd.

ScrumBut ist abgeleitet von der Aussage "We do Scrum, but ...", also "Wir machen zwar Scrum, aber ...". Hinter diesem "aber" verbergen sich dann die Einschränkungen denen das Vorgehen unterworfen wurde. "Wir machen zwar Scrum, aber nur auf Teamebene.", "Wir machen zwar Scrum, aber ohne Scrum Master." oder "Wir machen zwar Scrum, aber nur für die IT." sind klassische ScrumBut-Aussagen, wie man sie überall dort wiederfinden kann wo vor einer wirklichen Einführung zurückgeschreckt wurde.

Das irritierende an dieser Variante - selbst bei offensichtlich eingeschränktem Umfang bleiben die an Scrum gerichteten Ansprüche meistens unverändert hoch. Dass auch diese proportional zum Rückbau der Methode sinken müssten wird selten eingesehen, und selbst wenn es erkannt wird kann eine überzogene Erwartungshaltung dazu führen, dass eine ernsthafte Organisationsveränderung blockiert wird. "Das soll erstmal auf Teamebene für Verbesserung sorgen bevor wir es woanders einführen" entspricht etwa der Aussage "Die Glühbirne soll erstmal zeigen, dass sie Licht machen kann, bevor sie Strom bekommt." Kann man so sehen, bringt einen aber nicht weiter.

ScrumAnd geht dagegen ist die genau andere Richtung: Scrum wird zwar wie vorgesehen eingeführt (zumindest weitgehend), gleichzeitig aber mit zusätzlichen Inhalten überfrachtet. Ein Beispiel dafür wäre ein Geschäftsführer, der zusätzlich die Rolle eines Product Owners übernimmt (und aus Zeitmangel fast alle damit verbundenen Tätigkeiten ins Team delegiert). Ein anderes Beispiel wäre die Integration so vieler Randaspekte in die Produktentwicklung (Werbekampagnen, First Level Support, etc.), dass das Team kaum noch focussiert arbeiten kann.

Rein formal lässt sich gegen diese Auslegung in vielen Fällen nichts sagen, der Scrum Guide erwähnt zwar nichts Derartiges, untersagt es aber auch nicht. In der Realität führt eine solche Überladung erfahrungsgemäss aber fast immer zu Reibungsverlusten, Zielkonflikten und Motivationsrückgang. Gleichzeitig kann es auch im Fall von ScrumAnd zu unrealistischen Erwartungshaltungen kommen. "Aber in den Regeln steht doch, dass der PO delegieren darf und dass dass Team crossfunktional sein muss." wäre eine klassische Begründung dafür, auch in solchen Konstellationen reibungslose Performance zu erwarten.

Sowohl bei ScrumAnd als auch im Fall von ScrumBut sind die Erwartungshaltungen auch der Punkt an dem angesetzt werden sollte um an Verbesserungen zu arbeiten. Dass stark beschnittene oder überfrachtete Vorgehensweisen ihre positiven Effekte nicht voll entfalten können wird fast jeder nachvollziehen können, wer an diesen Effekten interessiert ist wird daher erkennen, dass er ein Zurückfahren der Missstände zumindest erwägen muss. Und wer von den alten Strukturen und breiten Aufgabenspektren nicht ablassen kann (wofür es gute Gründe geben kann) dem kann man vermitteln, dass Scrum seinen Ansprüchen nicht genügen wird und er einen anderen Ansatz ausprobieren sollte.

Dass auch ein anderer Ansatz mit hoher Wahrscheinlichkeit an diesen Ansprüchen scheitern dürfte steht dann auf einem anderen Blatt, hat aber mit den beiden hier beschriebenen Scrum-Antipattern nichts mehr zu tun.

Freitag, 4. Oktober 2019

Die fünf Zeitdiebe

FS
Die Ähnlichkeit zwischen den fünf Zeitdieben und den Mudas des Toyota Production System dürfte kein Zufall sein, beiden ist die Herkunft aus dem Lean Thinking deutlich anzumerken. Dementsprechend präsentiert Dominica DeGrandis hier nichts völlig Neues, betrachtet einige Aspekte aber aus einem neuen Blickwinkel.

Montag, 30. September 2019

Kommentierte Links (LIII)

FS
  • Troy Magennis: Story Point Velocity or Throughput Forecasting: Does it matter?

  • In Bezug auf das in der (IT-)Kanban-Bewegung beliebte statistikbasierte Forecasting bin ich gleichermassen Fan und Skeptiker. Natürlich hat eine auf der Story Point-Velocity beruhende Planung grosse Schwächen, von denen Troy Magennis hier einige aufzählt. Zu beachten ist dabei aber: er geht von nicht-idealen agilen Teams aus, die aufgrund nicht gegebener Crossfunktionalität und fehlender Focussierung starke Abhängigkeiten nach aussen haben. Das ist zwar durchaus realistisch, völlig unabhängige Teams sind selten. Umgekehrt wird aber bei dem als Alternative vorgeschlagenen Durchsatz-Modell nicht erwähnt, dass auch das ideale Rahmenbedingungen braucht, z.B. ein stabiles System, in dem Arbeiten nicht abgebrochen werden und in dem das Leistungsvermögen der Teams nicht schwankt. Auch das ist in der Realität aber selten. Ein bisschen wird hier also mit ungleichem Mass gemessen. Letzten Endes gilt für beide Ansätze, dass sie Unplanbares nicht planbar machen können, weshalb man sich von Anfang an auf Planänderungen einstellen sollte.

  • François Knuchel: Why aren’t Lean and Agile Collaborating?

    Mal wieder ein Artikel über die absoluten Basics. Die Unterschiede zwischen Agile und Lean dürften zwar schon oft erörtert worden sein, vermutlich aber selten so ausführlich wie hier von François Knuchel. Neben den offensichtlichen Besonderheiten arbeitet er auch einige heraus die in den meisten Betrachtungen untergehen, z.B. das Agile-Kanban ein eher linearer Prozess einzigartiger Einzelaufgaben ist, während Lean-Kanban aus wiederkehrenden Schleifen gleichartiger Arbeit besteht. Auch die Beobachtung, dass Agile aufgrund der Affinität zu IT und Open Source eine offenere Community hat als Lean ist ein interessanter Gedanke, vor allem in Verbindung mit der Hypothese, dass das eine Ursache der im Vergleich stärkeren Sichtbarkeit und Verbreitung ist. Wirklich zum Nachdenken anregend ist aber die Vermutung, dass die beiden Bewegungen sich kaum austauschen, weil sie sich zu parallelen Silo-Strukturen entwickelt haben. Damit wären sie genau da gelandet wo sie nicht hinwollen.

  • Mark Lambertz: Matrjoschkas und das Prinzip der losen Kopplung

    Noch mehr zum Nachdenken. Wie oben in anderem Zusammenhang hervorgehoben wurde geht auch Mark Lamberts davon aus, dass Teams mit zu grossen Abhängigkeiten letztendlich nicht agil sein können. Sein Betrachtungsschwerpunkt liegt dabei allerdings nicht auf den "horizontalen Abhängigkeiten" von anderen Teams sondern auf den "vertikalen Abhängigkeiten" von höheren Hierarchiestufen. Konkret geht es um die von dort vorgegebenen globalen Aufgabenschnitte, aus denen die unteren Ebenen ihre lokalen Aufgabenschnitte ableiten müssen. Dass das Selbstorganisation hemmt ist offensichtlich, dass es irgendwie zu einem Zusammenwirken aller beteiligten Einheiten kommen muss aber auch. Mark Lamberts' Idee von "lebensfähigen Systemen, welche in ein übergeordnetes lebensfähiges System eingebettet sind" ist ein interessanter Ansatz um diesen Widerspruch aufzulösen, dürfte aber in der Umsetzung sehr anspruchsvoll sein.


  • Oliver Staley: Whatever happened to Six Sigma?

    Eine Vorstellung von dem was manche Kritiker der agilen Bewegung voraussagen bietet das Schicksal von Six Sigma. Einst ähnlich gehypt ist mittlerweile nicht mehr viel davon übriggebliebben. Die von Oliver Staley genannten Ursachen sind auch tatsächlich die, die gerade bei Scrum, SAFe & Co zunehmend zu betrachten sind: Kommerzialisierung, Hype-getriebene Anwendung auf unpassende Bereiche, Wahrnehmung als Mode-Erscheinung. Dass Agile den selben Weg gehen wird ist nicht zwangsläufig, ein warnendes Beispiel für das was schlimmstenfalls passieren könnte ist Six Sigma aber auf jeden Fall.

Donnerstag, 26. September 2019

Deine Muda: Langfristige Detailplanung

FS
Grafik: Pxhere / Mohamed Hassan - CC0 1.0

Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.

Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren1) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.2 Die bereits in sie investierten Aufwände waren umsonst.

Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).

Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.

Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.


1Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
2In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.

Montag, 23. September 2019

Jack of all trades, Scrum Master of none

FS
Bild: Pixabay / Moise Theodor - CC0 1.0
Liest man im Scrum Guide nach welche Aufgaben ein Scrum Master alles übernehmen soll kann einem schnell schwindelig werden. Er soll das Team in Richtung Selbstorganisation coachen, soll Hindernisse beseitigen, Meetings moderieren, den Product Owner methodisch unterstützen und Change Management in der umgebenden Organisation betreiben. Je nach Umfeld sind noch weitere Themenfelder nötig: XP-Techniken, Liberating Structures, Design Thinking, Konflikt-Mediation, Skalierung, etc. etc. etc.

Es ist zwar nicht ausgeschlossen, dass es Menschen gibt die all das aus dem Stand beherrschen, viele sind es aber nicht. Da es den Beruf noch nicht lange gibt kommen meisten Scrum Master ursprünglich aus einem anderen Betätigungsfeld, Klassiker sind dabei Softwareentwicklungs-Spezialisierungen (Entwickler, Konzepter, Tester), Projektmanager oder IT-ferne Coaching-Berufe. Aus einem solchen Hintergrund heraus zu einem "universal gebildeten Spezialisten für alles" zu werden ist schwer, und vor allem dauert es Zeit.

Wenn man nicht den Luxus hat in einer Gruppe von Scrum Mastern zu arbeiten, in der einzelne Mitglieder sich unterschiedliche Schwerpunkte suchen können, bleibt die Wahl zwischen zwei Ausrichtungen: Spezialisierung und Generalisierung. Entweder man geht in einem (oder wenigen) Wissensgebieten in die Tiefe oder man erwirbt ein Grundwissen in möglichst vielen. In der überwiegenden Zahl der zu beobachtenden Fälle1 fällt die Entscheidung auf Variante Eins.

Dass das problematisch ist, ist intuitiv ersichtlich, schliesslich werden wichtige Felder bewusst nicht beackert. Die wahre Dimension erschliesst sich aber wenn man bedenkt, dass in den meisten Fällen die Spezialisierung in den "teamnahen" Themenfeldern stattfindet. Um nicht falsch verstanden zu werden - gekonnte Meeting-Moderation und gute Coaching-Techniken sind wichtig, wenn für sie aber (agil) strukturiertes Produktmanagement und das Alignment mit der umgebenden Organisation wegfallen ist nichts gewonnen. Die Scrum-Implementierung wird dann schwere Dysfunktionen haben.

Die Alternative ist vielversprechender: ein Grundverständnis aller relevanten Bereiche sogt zum einen dafür, dass sich nicht irgendwo unbemerkt Antipattern ausbreiten können, zum anderen ist es die Ausgangslage dafür, zielgerichtet andere Teammitglieder zur eigenen Entlastung einbinden zu können. Zum Beispiel kann die Meeting-Moderation in den meisten Fällen von Teammitgliedern selbst übernommen werden, so dass dort nur noch eingesprungen werden muss wenn ein neutraler Vermittler nötig ist.2

Zuletzt ist ein breites Grundverständnis die Voraussetzung dafür, dass in späteren Phasen der Selbstentwicklung entschieden werden kann wo eine Vertiefung der Kenntnisse den grössten Mehrwert stiften kann. Wichtig ist dabei aber die Reihenfolge: erst das breite Verständnis, dann die Vertiefung in einzelne Themen. Nicht umgekehrt.


1Basierend auf der eigenen Beratungserfahrung und dem Austausch in der agilen Community im Rheinland
2Ironie der Geschichte: diese Tätigkei zu delegieren fällt vielen Scrum Mastern besonders schwer

Donnerstag, 19. September 2019

Das beste agile Skalierungs-Framework der Welt: Reden

FS
Bild: Pexels / Christina Morillo - CC0 1.0
In den nächsten Tagen werde ich an einer Podiumsdiskussion teilnehmen dürfen, die den etwas reisserischen Titel "Battle of the Frameworks" trägt. Das Ziel: verschiedene agile Skalierungs-Frameworks nebeneinander zu halten, Vorteile und Nachteile zu vergleichen und wenn möglich herauszufinden welcher Ansatz in welcher Situation hilfreich sein könnte und welcher eher nicht.

In der Vorbereitung habe ich mir durch den Kopf gehen lassen welche der bekannten Skalierungs-Frameworks ich schon im Einsatz gesehen habe und bin auf einige gekommen: Scrum@Scale, LeSS, Nexus, SAFe, (Pseudo)Spotify, Flightlevel-Kanban und einige Hybrid-Modelle aus Agile und Wasserfall waren dabei, alle mit Aspekten die gut funktioniert haben und solchen bei denen das nicht der Fall war. Mir ist aber auch klar geworden, dass ich einen absoluten Favoriten habe - einfach miteinander reden.

Bis zu einer Größe von mindestens fünf Teams kommt man damit erstaunlich weit (und ich kenne nicht viele Fälle in denen mehr als fünf Teams Sinn gemacht haben). Wenn die Produktmanager und Product Owner den gemeinsamen Release zusammengehörender Features planen wollen können sie das tun indem sie miteinander reden. Wenn die Entwickler Coding-Standards und Schnittstellen definieren wollen können sie miteinander reden. Wenn die UX-Designer ein übergreifendes Look and Feel herbeiführen wollen können sie miteinander reden, etc.

Das passiert grundsätzlich zwar auch in allen anderen Frameworks, der Unterschied ist, dass Zeit, Ort und Gruppe dabei reglementiert sind. Planung findet im PI-Planning statt, die Klärung von Abhängigkeiten im Scrum of Scrums, die Erarbeitung von Konventionen in der Community of Practice - für nahezu jedes Anliegen lässt sich ein passendes Format finden, dass dann aber auch Risiken in sich birgt: wenn für ein Anliegen kein Format da ist oder wenn dieses erst zu einem anderen Zeitpunkt stattfindet, dann findet eine Klärung oft nicht statt.

Die Alternative: sobald der Bedarf nach Abstimmung aufkommt kann man einfach zu den Betroffenen hingehen, kann sie fragen ob sie einen Beitrag zum Thema liefern können, wann sie Zeit dafür haben und wen sie sonst noch dazuholen würden. Wenn es soweit ist spricht man miteinander, einigt sich und klärt welche nächsten Schritte zu welchem Zeitpunkt gemeinsam angegangen werden sollen. Und das ist es, mehr als das ist in den meisten Fällen nicht nötig.

Dass dieses verblüffend einfache Modell in der Realität kaum vorkommt hat natürlich Gründe: räumliche Trennung, Überplanung durch zu viele Termine, fehlende Entscheidungskompetenzen, fehlende Einsicht in grössere Zusammenhänge und zu viele Abhängigkeiten. Aber an dieser Stelle gibt es auch gute Neuigkeiten - all das kann man ändern, man muss es nur wollen. Und wenn das geschafft ist kann man alle komplizierten Zusammenarbeitmodelle den Grossprojekten überlassen und sich auf das gemeinsame Reden beschränken.
Powered by Blogger.