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.
Powered by Blogger.