Wer von agiler Skalierung spricht meint meistens etwas anderes

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 werden¹, 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.


¹Dass nicht verstanden wird, dass diese Teams ohne Crossfunktionalität und Freiheit von Abhängigkeiten kaum agil sein können, ist Teil des Missverständnisses.

Exvernunft

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.

The Agile Bookshelf: The Phoenix Project

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

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


¹Höchste Zeit war es auch, die Fortsetzung The Unicorn Project ist gerade erschienen.
²Und der Vollständigkeit halber: Leser ohne Projekt- oder IT-Bezug werden verwirrt sein.

Kommentierte Links (LV)

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

Lead Time und Cycle Time

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.

Zertifizierungs-Overkill

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.

Why agile: Gesetzliche Regulierung

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.

Three Ways to break Hierarchy

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.