Chapter Leads & Group Leads

Bild: Pexels / Yan Krukau - Lizenz

Noch einmal zum Thema der neuen Führungsrollen in einem agiler werdenden Umfeld. Dass bei ihrer Ausgestaltung verhindert werden sollte, dass der disziplinarische Vorgesetzte eines Teams auch dessen fachliche oder methodische Leitung innehat, ist eine Einsicht, die sich immer mehr durchsetzt. Alles andere würde zwangsläufig zu einer (Teil-)Entmachtung des Product Owners oder Product Managers führen, da dieser dann nicht mehr der Einzige wäre, der seinem Team Ziele vorgibt.

Die sich zur Zeit etablierende Rolle des People Managers wird dieser Anforderung gerecht, indem sie in den meisten Fällen völlig aus dem operativen Geschäft herausgelöst wird. Das verhindert zwar Zielkonflikte, die Entkoppelung von der täglichen Arbeit macht es aber für viele People Manager sehr schwer zu erkennen, welche Mitarbeiter sich Versetzungen, Beförderungen oder Gehaltserhöhungen verdient haben und welche nicht (mehr dazu hier).

Manche Unternehmen versuchen daher einen dritten Weg zu gehen. In ihm wird die disziplinarische Führung nur in Teilzeit ausgeübt (zumindest auf den unteren Hierarchie-Ebenen), wodurch weiter ein unmittelbarer Bezug zur eigentlichen Arbeit gewahrt wird. Ausserdem bleibt ein Teil der fachlichen Führung erhalten, aber nicht in Bezug darauf was gemacht wird, sondern wie es gemacht wird (eine wichtige Unterscheidung).

In diesem Modell bleibt auf diese Weise die Entscheidung darüber welche Kundenprobleme gelöst werden oder welche Features gebaut werden (→ die Product Ownership) ausschliesslich beim Product Owner oder Product Manager, die Grundlage auf der die die disziplinarische Führungsrolle über Versetzungen, Beförderungen oder Gehaltserhöhungen entscheidet ist dagegen die Qualität der Arbeit - idealerweise anhand transparenter und im voraus feststehender Kriterien.

In diesem Modell gibt es dann nochmal zwei verschiedene Arten der Ausgestaltung. Eine allgemein übliche Bezeichnung hat sich für sie noch nicht durchgesetzt, um sie hier beschreiben zu können möchte ich aber die Titel aus den vermutlich jeweils bekanntesten Anwendungsfällen benutzen: den Chapter Lead aus dem Spotify Model (ja, ich weiss) und den Group Lead (japanisch Hanchô / 班長) aus dem Toyota Production System.

Chapter Lead

Das entscheidende Erkennungsmerkmal des Chapter Leads ist seine Einordnung in eine Matrix-Organisation. Seine Einheit (das Chapter) arbeitet nicht selbst an einem Produkt oder Feature, sondern besteht aus gleichartigen Spezialisten (z.B. UX, QA oder Kundenservice) die über mehrere produktorientierte Teams verteilt sind. Dieser sehr ähnliche Arbeitsgegenstand aller Chapter-Mitglieder ermöglicht es dem Chapter Lead, gemeinsame Qualitätskriterien zu erstellen (auch teamübergreifend).

Group Lead

Im Umfeld der Group Lead-Rolle sind Ablauf- und Aufbauorganisation identisch, es gibt also keine Matrix-Organisation. Eine Gruppe verantwortet in Gänze ein (Teil-)Produkt, ein Feature oder eine Fertigungsstation, und umfasst alle dafür notwendigen beruflichen Spezialisten. Für den Group Lead bedeutet das, dass er einen besseren Einblick in die Zusammenarbeit der Spezialisten hat als der Chapter Lead, dafür aber schlechter die jeweiligen Einzelleistungen beurteilen kann.

Um es vereinfacht zusammenzufassen: sowohl Chapter Leads als auch Group Leads überlassen die Product Ownership dem Product Owner, bzw. Produktmanager und haben stattdessen die Qualität als ihr Führungsgebiet. Während das bei dem stark spezialisierten Chapter Lead vor allem die Qualität der Arbeitsvorgänge ist, ist es bei dem eher generalistischen Group Lead vor allem die Qualität des jeweiligen (Teil-)Produkts. Beide Ausprägungen haben Vor- und Nachteile, keine ist besser als die andere.

Zur Sicherheit noch ein zweites Mal zur Klarstellung: die beiden hier genutzten Begriffe sind nicht offiziell oder allgemein anerkannt, dass ich sie hier benutzt habe, hat nur den Zweck, zwei Rollen, für die es noch keinen feststehenden Namen gibt, beschreiben zu können. Im Einzelfall können die Benennungen ganz anders sein. Das ist auch unproblematisch, wichtiger als die Bezeichnung ist das Verständnis der dahinterstehenden Ausgestaltungen.

Das ist auch der finale Ratschlag, bzw. das Fazit dieses Artikels: wichtiger als die schönen englischen oder japanischen Namen sind die Gestaltungsparameter: wie kann eine disziplinarische Führungsrolle so gestaltet werden, dass sie die Product Ownership des Product Owner/Produktmanager nicht untergräbt, trotzdem in der Lage ist auf sachlicher Ebene über über Versetzungen, Beförderungen oder Gehaltserhöhungen zu entscheiden und einen für alle klar erkennbaren Verantwortungsbereich hat?

Am Ende muss es nicht zwangsläufig auf eine der beiden hier genannten Varianten herauslaufen, zumindest sind sie aber ein guter Ausgangspunkt für die Neu-Konzeption sinnvoll ausgestalteter Führungsrollen in einem agiler werdenden Umfeld. In vielen Fällen die ich gesehen habe, hätten sich Firmen damit grosse Missverständnisse und Schmerzen ersparen können.

Scrum goes Pop Music (III)

Nachdem ich in der Vergangenheits bereits mehrfach Videos von Chad Beier hier eingebunden habe, habe ich seinen Youtube-Kanal irgendwie aus den Augen verloren. Nachdem er mir jetzt wieder in den Sinn gekommen ist, habe ich dort tatsächlich einige neue "agilisierte" Coverversionen bekannter Popsongs gefunden. Wie immer ein großer Spass.

Virtue Signaling

Bild: Pexels / Polina Tankilevitch - Lizenz

Eines der kurioseren soziologischen Phänomene der letzten Jahre ist das so genannte Virtue Signaling. Hinter diesem Begriff verbirgt sich das demonstrative öffentliche Kommunizieren von Standpunkten die als moralisch gut oder sogar überlegen wahrgenommen werden. Zweck dieser Handlung ist neben der Selbstvergewisserung die Symbolisierung einer Gruppenzugehörigkeit, die Abgrenzung zu anderen, als unmoralisch empfundenen Gruppen und die Beanspruchung einer Diskurs-Dominanz.

Virtue Signaling tritt vor allem im politischen Kontext auf, greift aber auch in der agilen Community um sich, etwa auf Meetups und Konferenzen, in Social Media oder Fachpublikationen. Verbunden ist es hier fast immer mit dem Kampf gegen eine (vermeintliche) Verfälschung und übermässige Kommerzialisierung der Idee der agilen Produktentwicklung, bzw. mit der Positionierung als Bewahrer der (idealisierten) ursprünglichen Absichten und Überzeugungen.

Mit der Zeit haben sich in diesem Zusammenhang einige populäre, stetig wiederholte Standard-Botschaften herausgebildet. Sie alle haben einen realen Kern, sprechen also tatsächliche Good Practices und Antipattern an, definieren sich aber sehr stark durch die Ablehnung bestimmter Missstände, wodurch sie oft von einem eher kritischen oder anprangernden Grundton durchzogen werden und in ihrem Dogmatismus mitunter über das Ziel hinausschiessen können.

Mit dieser Vorrede im Hintergrund - hier sind einige der am häufigsten vorgetragenen "agilen Virtue Signals", samt einer kleinen Einordnung:

Wir haben keinen Prozess, wir verhalten uns einfach vernünftig

Was steckt dahinter? Die Ablehnung der sehr stark ausufernden Prozessbeschreibungen, die SAFe, Disciplined Agile, Scrumstudy und weitere kommerzialisierte Anbieter verfasst haben. Diese werden als im Widerspruch stehend zu Selbstorganisation und Inspect & Adapt wahrgenommen.

Was ist davon zu halten? Die Grundidee mag vernünftig sein, in der Umsetzung stösst sie aber schnell an Grenzen. In jeder Situation neu zu erforschen und zu verhandeln was gerade die beste Lösung ist, selbst wenn es bereits passende Lösungen gibt, wäre verlangsamend und unwirtschaftlich.

Agile ist ein Mindset

Was steckt dahinter? Die Ablehnung der Reduktion von agilem Arbeiten auf spezifische Meetings, Rollen und Anforderungsformate, ohne das nötige Hinterfragen klassischer Welt- und Menschenbilder, die ohne Veränderung auch gutgemeinte Prozesse hierarchisch und kontrollierend umformen können.

Was ist davon zu halten? Ein kontroverses Thema. Für viele Agilisten ist dieser Spruch eine unverrückbare Wahrheit, die sie ständig rezitieren, für andere eine nicht zielführende Verlagerung systemischer Probleme auf die persönliche Ebene. Auf jeden Fall gut für lebhafte Diskussionen.

Kanban ist agiler als Scrum

Was steckt dahinter? Schlechte Erfahrungen mit rigide durchgesetztem und dogmatisch befolgtem Scrum, vor allem in Kontexten in denen Sprints und Sprintziele nur schlecht funktionieren können. Umgekehrt kommen gute Erfahrungen mit den schlanken und flexiblen Kanban-Prozessen dazu.

Was ist davon zu halten? In den meisten Fällen dürften derartige Äusserungen darauf beruhen, dass Scrum falsch (oder an einer nicht passenden Stelle) umgesetzt wurde. Grundsätzlich ist Kanban völlig in Ordnung, es ist aber nicht "Scrum ohne komische Vorschriften" (und beide sind ähnlich agil).

Extreme Programming ist das beste agile Framework

Was steckt dahinter? Zum einen Vergangenheitsverklärung - vor der Kommerzialisierungswelle der 2000er Jahre war XP das dominante Framework. Zum anderen der Ursprung vieler technischer agiler Praktiken in XP, ohne die Agilität (in der IT) nicht funktionieren kann.

Was ist davon zu halten? Wenn wirklich die technische Dimension im Vordergrund steht ist XP tatsächlich eines der besten agilen Frameworks (zumindest in der IT). Man muss sich nur bewusst machen, dass es seit ca. 20 Jahren nicht weiterentwickelt wurde und keinen Skalierungsansatz hat.

Story Points und Velocity gehören nicht zur Agilität

Was steckt dahinter? Die Ablehnung von Cargo Cult-Praktiken. Story Points und Velocity können bei falschem Verständnis die Illusion erzeugen, dass auch in volatilen und komplexen Umgebungen klassische Zeit- und Aufwandsplanung möglich ist. Dieses Missbrauchspotential führt zu einer Komplett-Ablehnung.

Was ist davon zu halten? Zum einen ist es richtig, dass Story Points und Velocity in keinem agilen Framework verpflichtend sind, man sollte aber zwischen Symptom und Root Cause differenzieren. Nicht diese Praktiken sind das Problem, sondern eher die Motive für ihren falschen Einsatz.

SAFe ist nicht agil

Was steckt dahinter? Die Ablehnung von zu umfangreichen oder falsch eingesetzten Regelwerken und Praktiken (siehe oben) und die Ablehnung zu starker Kommerzialisierung, für die SAFe mit seinen jährlich zu erneuernden, teuren Zertifizierungen das bekannteste Beispiel ist (siehe unten).

Was ist davon zu halten? Auch hier wieder: Ein kontroverses Thema. Für viele Agilisten ist die vehemente Ablehnung von SAFe Teil ihres Selbstverständnisses, andere bestehen darauf, auch mit SAFe agil arbeiten zu können (was z.T. sogar stimmen kann). Wie so oft - es kommt darauf an.

Wir machen Wir machen #NoBacklogs / #NoEstimates

Was steckt dahinter? Schlechte Erfahrungen mit zu detaillierten Planungen und dem Schätz-Zwang unschätzbarer Tasks. Aus Sorge, dass selbst gutgemeinte Ansätze zu diesem Zweck missbraucht werden können, kommt es auch hier zu kategorischen Ablehnungen von Planung und Aufwandsschätzung.

Was ist davon zu halten? Wenig, hier wird über das Ziel hinausgeschossen. Backlogs entstehen automatisch sobald unerledigte Arbeit da ist und Aufwandsschätzungen sind selbst dann gegeben wenn man sich fragt ob etwas im nächsten Monat machbar ist. Das zu vermeiden ist unmöglich.

Jira und andere Ticket-Tools sind nicht agil

Was steckt dahinter? Zum einen schlechte Benutzungserfahrungen, wie z.B. die, dass manche agilen Praktiken und Workflows in ihnen nicht abbildbar sind, zum Anderen schlechte Erfahrungen mit zu restiktiver Administration und Berechtigungsvergabe.

Was ist davon zu halten? Wie bei Story Points und Velocity sollte man auch hier zwischen Symptom und Root Cause differenzieren. Jira & Co haben ihre Schwächen (welches Tool hat die nicht?), meistens ist aber der nicht zielführende Einsatz das Problem, nicht das Tool selbst.

Selbst Spotify benutzt das Spotify Model nicht

Was steckt dahinter? Die Erzählung, dass das Spotify Model mit seinen Tribes, Squads, Gilden und Chaptern nur eine temporäre Momentaufnahme aus einer längeren Entwicklung war und nie als Blaupause für andere Organisationen gedacht gewesen ist (obwohl genau das passiert ist).

Was ist davon zu halten? Es kommt darauf an. Wenn man unter dem Spotify Model nur die Matrix-Organisation aus Tribes, Squads und Chaptern versteht, ist sie dort jahrelang im Einsatz gewesen (siehe hier ab Minute 28). Als Blaupause gedacht war sie nie, funktionieren kann sie trotzdem.

LeSS ist das beste agile Skalierungs-Framework

Was steckt dahinter? Erneut die Ablehnung übermässiger Prozesslastigkeit, die in den meisten Skalierungen anzutreffen ist. Das Versprechen von LeSS, Scrum ohne zusätzliche Meetings skalieren zu können, wirkt im Vergleich sehr verlockend.

Was ist davon zu halten? Erneut: es kommt darauf an. Wenn die beteiligten Teams mit einem gemeinsamen Ziel an einem gemeinsamen Produkt in einem gemeinsamen System arbeiten sind LeSS (oder Nexus) sehr zu empfehlen, bei anderen Konstellationen können andere Ansätze besser passen.

Es gibt einen agil-industriellen Komplex

Was steckt dahinter? Die Erkenntnis, dass es einem Grossteil der Schulungs- und Zertifizierungs-Anbieter vor allem um ein sicheres Business Model geht und weniger um bessere Produkte und flexiblere Prozesse, weshalb mitunter auch unnötige Kurse und Zertifikate verkauft werden.

Was ist davon zu halten? Über das Wording kann man streten, aber das Phänomen ist real. Es gibt eine Schulungs- und Zertifizierungs-Industrie in der aufgrund systemischer Zusammenhänge teure Prüfungs- und Teilnahmebescheinigungen zum Selbstzweck geworden sind.

Die Liste liesse sich sicher noch erweitern, die grundlegende Stossrichtung dürfte aber klar sein, genau wie die sich daraus ergebende Problematik. (Agiles) Virtue Signaling wirkt bewusst polarisierend und z.T. ausgrenzend, zudem beansprucht es die Deutungshoheit über richtig und falsch. Das Führen differenzierter und konstruktiver Diskussionen ist auf dieser Basis sehr schwierig, mit grosser Wahrscheinlichkeit wird diese Art der Gesprächsführung in Konflikten enden (oder in Group Think).

Um die (ja grundlegend richten) Ausgangsüberlegungen besser zu vertreten bieten sich daher andere Vorgehensweisen eher an. Kritischer Rationalismus, Prime Directive und Datengetriebene Validierung lassen sich zwar nicht mit vergleichbarer Emotionalität vertreten, aber genau das ist am Ende auch der Punkt: wer in einer ungewissen und wechselhaften Umgebung versucht bestimmte Ideen als richtig und falsch zu kategorisieren mag sich zwar moralisch überlegen fühlen, der Realität gerecht werden wird er aber eher nicht.

Fachkräftemangel und Selbstorganisation

Bild: Pexels / Fauxels - Lizenz

Zu den spannenden Fragen im Umfeld der stark auf selbstorganisierte Teams setzenden agilen Frameworks gehört diese: warum ist es vor allem in der Software-Entwicklung zu ihrer starken Verbreitung gekommen, während sie in anderen Branchen bisher eher Ausnahmeerscheinungen sind? Natürlich gibt es Erklärungsansätze, die aber meistens von der selben Prämisse ausgehen - der Komplexität des Arbeitsgegenstandes. Möglicherweise ist der Grund aber ein ganz anderer.

Zum besseren Verständnis kurz eine Erklärung der Arbeitsgegenstand-Hypothese. Sie beruht darauf, dass es sich bei der Softwareentwicklung um eine komplexe Tätigkeit handelt, also um eine, bei der Kleinteiligkeit, Vernetztheit und Volatilität dafür sorgen, dass ständig Neu- und Umgeplant werden muss. Da zentrale Befehls- oder Koordinations-Instanzen dabei zu verlangsamenden Flaschenhälsen werden können, wird angenommen, dass Selbstorganisation die logische Folge ist.

Was diese Annahme in Frage stellt ist ein Blick auf andere komplexe Arbeitskonstellationen. Z.B. unterliegen auch Filmproduktionen, Nachrichtenredaktionen und Spitzengastronomie den Faktoren Kleinteiligkeit, Vernetztheit und Volatilität, trotzdem ist Selbstorganisation in ihnen eher selten. Regelmässig aufkommende Skandale zeugen sogar vom Gegenteil: Macht-Zentralisierung (und Machtmissbrauch) sind weit verbreitet und werden stillschweigend geduldet.

Der zentrale Unterschied, der die IT-Branche von den gerade genannten (und vielen anderen) Branchen unterscheidet, ist der Fachkräftemangel. Während es auf dem Arbeitsmarkt ein deutliches Überangebot an Schauspielern, Kameraleuten, Journalisten und Köchen gibt, sind Softwareentwickler selten und schwer zu kriegen. Und selbst dort, wo es gelingt die freien Stellen zu besetzen, geschieht das häufig nur durch externe Dienstleister und Freiberufler.

Die sich daraus ergebenden Folgen kann sich jeder vorstellen: wer froh sein muss, einen von wenigen gut bezahlten Jobs ergattert zu haben, wird gegenüber seinem Vorgesetzten ein eher unterwürfiges Verhalten an den Tag legen, um ihn möglichst lange ausüben zu können. Und das sogar dann, wenn die Behandlung die man erfährt bestimmend, micro-managend oder sogar missbrauchend ist (in den oben verlinkten Artikeln sind z.T. verstörende Details zu lesen).

Umgekehrt wird jemand der nicht nur in kurzer Zeit sondern auch in der näheren Umgebung jederzeit eine neue, gleich gut bezahlte Anstellung finden kann, sich wenig gefallen lassen und im Zweifel durch eine Abstimmung mit den Füssen dafür sorgen, dass dominante Vorgesetzte bald niemanden mehr haben, den sie im Detail managen können. Und da jeder Manager das weiss wird er seinen Untergebenen bereits vorauseilend möglichst grosse Freiheiten gewähren.

Auch im Rahmen grosszügig gewährter Freiheiten muss aber sichergestellt sein, dass Kunden- und Unternehmens-Interessen und Gesetze gewahrt werden. Und da eine Erzwingung von oben die kostbaren Fachkräfte verschrecken könnte, ist die Gewährung von Selbstorganisation oft der beste Weg um zur Einhaltung dieser Vorgaben zu kommen - ihre Umsetzung wird einfach in die Verantwortung von selbstorganisierten Teams übergeben.

Um Missverständnisse zu vermeiden: damit soll nicht gesagt sein, dass die Annahme falsch ist, dass komplexe Herausforderungen am besten durch selbstorganisierte Teams gemeistert werden können. Vieles spricht dafür, dass das tatsächlich der Fall ist. Der tatsächliche Grund für die Zulassung und Förderung von selbstorganisiertem Arbeiten ist aber sehr oft eher darin zu finden, dass Jobs in den Mangelberufen der IT attraktiv ausgestaltet werden sollen.

Dass agile Frameworks wie Scrum & Co in der Softwareentwicklung derartig stark verbreitet sind, dürfte daher ganz wesentlich mit dem dort vorherrschenden Fachkräftemangel zu tun haben, und nicht nur mit dem Arbeitsgegenstand. Und jeder Versuch, derartige Arbeitsweisen in Bereichen mit Arbeitskräfte-Überschuss einzuführen, wird nur dann erfolgreich sein, wenn dort der Missbrauch von Abhängigkeitsverältnissen konsequent und frühzeitig verhindert wird.

Lean-Metriken (III)

Grafik: Wikimedia Commons / Daniel Penfield - Public Domain

Dritter Teil der Übersicht über die Lean-Metriken. Nach einer allgmeinen Übersicht über die Typen von Durchlaufzeiten im ersten Teil (zu finden hier) und die einer Einführung in die Flusseffektivität im zweiten Teil (zu finden hier) soll es heute um die Flusseffizienz gehen. Um diese ähnlich klingenden Begriffe zu unterscheiden: während es bei der Effektivität darum geht die eigenen Tätigkeiten auf Sinnhaftigkeit zu optimieren (→ wenig Waste) hat Effizienz die Leistungsfähigkeit als Ziel (→ hoher Ausstoß). Zu beachten ist dabei natürlich, dass beides angestrebt werden sollte, hier soll es aber jetzt nur um Metriken für die Flusseffizienz gehen.

Takt Time

Die Takt Time bezeichnet die (anzustrebenderweise) immer gleich bleibende Zeit die zur Fertigstellung eines Liefergegenstandes benötigt wird, beispielsweise die 30 Sekunden die für einen Stanz- oder Fräs-Vorgang nötig sind. Eine der Lean-Metriken die nur schwer in die Software-Entwicklung übertragbar sind, wenn überhaupt eher auf automatisierte Prozesse als auf Programmiertätigkeiten.

Throughput Time

Auf Deutsch der Durchsatz. Bei ihm wird nicht mehr die Dauer einzelner Arbeitsvorgänge gemessen, sondern die Anzahl der erzeugten Ergebnisse (Produkte, Features, etc.) pro Zeiteinheit. Ein Beispiel wären 500 Autos die pro Tag in einer Fabrik gebaut werden. Aus dem Versuch die Throughput-Messung in die Software-Enwicklung zu übertragen ist das Konzept der Velocity entstanden.

Maintenance Time

Eine Metrik die leicht für einen Teil der Blocked Time gehalten werden kann, da Maintenance (Wartung) ähnlich wie diese dafür sorgt, dass die eigentliche Arbeit nicht stattfinden kann. Die Differenzierung: statt die Gesamtzeit der Nichtverfügbarkeit zu messen geht ist hier um die Durchschnittsdauer eines Wartungsintervalls, die idealerweise möglichst kurz sein sollte.

Recovery Time

Dieser Metriken-Typ ist von Bedeutung wenn es trotz Wartungen zu unfallbedingten Ausfällen kommt und misst die Durchschnittsdauer der Reparaturen und und der anschliessenden Wiederinbetriebnahme. Diese Dauer möglichst kurz zu halten ist nochmal wichtiger als bei der Maintenance Time, da das Eintreten von Zwischenfällen und Recovery-Phasen meistens unvorhersehbar und nicht planbar ist.

Flusseffizienz

Sowohl in Bezug auf die Produktion von Ergebnissen (Produkte, Features, etc.) als auch in Bezug auf Wartungen und Wiederinbetriebnahmen ist es das Ziel, die durchschnittliche Erstellungs- oder Bearbeitungszeiten so kurz wie möglich zu halten. Mit Hilfe der hier genannten Metriken darauf zu optimieren ermöglicht eine höhere Effizienz im Arbeitsfluss, die aber nicht ohne Risiko ist.

Eine ausschliessliche Fixierung auf Flusseffizienz macht vor allem in der Serienfertigung Sinn, in der Produktentwicklung besteht das Risiko, dass man in der Build Trap landet, also versehentlich das Falsche produziert, davon aber sehr schnell sehr viel. Hier solte also regelmässig überprüft werden, ob man noch immer in der richtigen Richtung unterwegs ist.

Der Scrum Master als Impediment (II)

Bild: Pixabay / Robin Higgins - Lizenz

Um es vorwegzunehmen: ich bin grosser Fan von Scrum im Allgemeinen und von der Rolle des Scrum Masters im Besonderen. Wie aber bei allen guten Ideen gibt es aber leider auch hier die Möglichkeit, sie so umzusetzen, dass sie eher schadet als nützt. Das kann schon bei der Ausgestaltung und Besetzung der Rolle beginnen (siehe hier), es kann aber auch sein, dass der Rollen-Inhaber sich (ggf. unbewusst) kontraproduktiv verhält. Um einen solchen Fall soll es hier gehen.

Ein Verhaltensmuster, das immer wieder zu beobachten ist, ist dass der Scrum Master bestimmte Tätigkeiten auf sich monopolisiert. Das kann auf den ersten Blick sinnvoll erscheinen, da die Absicht dahintersteckt das Team zu entlasten oder zu beschützen, im Ergebnis führt ein solches Verhalten aber meistens zu Flaschenhälsen in der Kommunikation, zu Unselbstständigkeit des Teams und zur Errichtung von Barrieren zwischen Menschen die eigentlich zusammenarbeiten sollten.

Der Klassiker unter diesen Monopolisierungen betrifft die Moderation der Meetings. Obwohl im Scrum Guide nicht vorgegeben ist, wer die Moderatoren-Rolle einzunehmen hat, wird sie in gefühlt 99 Prozent der Fälle vom Scrum Master übernommen. Dafür gibt es auch Gründe (der einfachste ist der, dass er es am besten kann), die Konsequenz ist aber häufig, dass in seiner Abwesenheit die Termine ausfallen, unstrukturiert ablaufen oder einen externen Moderator brauchen. Alles nicht im Sinn der Idee.

Ebenfalls problematisch ist die Monopolisierung des Impediment-Lösens. Auch hier ist die Absicht meistens eine gute: die anderen Teammitglieder sollen sich auf ihre Arbeit konzentrieren können und für die Stakeholder soll ein durchgehender Ansprechpartner da sein. Das Ergebnis sind aber häufig stille Post-Effekte und verlangsame Kommunikation, da die von Problemen betroffenen Personen und die, die es lösen können nicht mehr in direktem Kontakt sind.

Ein dritter Problemfall tritt auf, wenn die Koordination zwischen den Teams vor allem über deren Scrum Master läuft, z.B. wenn nur sie an einem Scrum of Scrums teilnehmen, neben dem es keine anderen gemeinsamen Kommunikations-Gelegenheiten gibt. Stille Post-Effekte und verlangsame Kommunikation sind auch in diesem Fall wahrscheinlich und werden oft dadurch verstärkt, dass die Scrum Master keinen technischen Hintergrund haben.

Die Lösung für diese (und viele weitere) Probleme ist es, gezielt nach den Themen zu suchen, die bisher ausschliesslich beim Scrum Master liegen und dafür zu sorgen, dass auch andere Mitglieder des Scrumteams Übung darin bekommen, sie zu übernehmen. Das ist am Einfachsten möglich bei der Meeting-Moderation, relativ einfach bei den teamübergreifenden Abstimmungen und am schwierigsten bei der Impediment-Lösung. Möglich ist es aber in allen Fällen.

Zuletzt noch zu möglichen Gegenargumenten. Anders als häufig angenommen wird gibt der Scrum Guide nicht vor, dass bestimmte Themen ausschliesslich dem Scrum Master zugeordnet sind. Um die häufigsten Missverständnisse zu nennen - "ensuring that all Scrum events take place" bedeutet eben nicht, dass er sie alle moderiert (im Daily ist nichtmal seine Anwesenheit nötig), und "causing the removal of impediments" bedeutet eben nicht, dass er sie alle selbst beseitigt.

Auch das Argument, dass die Übernahme von Meeting-Moderation, Impediment-Lösungen und übergreifender Kommunikation die Team-Mitglieder von ihrer "eigentlichen Arbeit" abhält, ist mindestens fragwürdig. In Scrum sind "self-management and cross-functionality" explizit für das gesamte Team vorgesehen, eben um zu verhindern, von einzelnen Personen abhängig zu sein. Die (scheinbaren) Scrum Master-Aufgaben zu übernehmen gehört also explizit zur Arbeit dazu.

Natürlich muss man diese Ansichten nicht teilen, man kann auch der Meinung sein, dass es effizienter oder effektiver ist, derartige Aufgaben vom Team fernzuhalten. Der Punkt ist aber: selbst wenn man das aus dem besten Willen heraus tut, wird man sehr schnell in einen Widerspruch zu den Regeln von Scrum geraten. Und jemand, der die Regeln von Scrum unterläuft oder aufhebt, ist per Definiton ein Impediment, selbst dann wenn diese Person der Scrum Master ist.

Practical Project Aristotle

Ich bin mir ziemlich sicher, dass ich irgendwann mal etwas über das Arisoteles-Projekt von Google geschrieben habe, eine Studie mit 180 teilnehmenden Teams, deren Ergebnis war, dass Hochleistung vor allem dann möglich ist, wenn die folgenden Dinge gegeben sind: Psychologische Sicherheit, Verlässlichkeit der Kollegen, Struktur und Klarheit der Ziele, Sinnhaftigkeit der Arbeit und Selbstwirksamkeitserwartung. Ich finde meinen Text gerade nicht, daher ist es um so besser, dass Talia Lancaster einen Vortrag zu dem Thema gehalten hat, den man sich ansehen kann.

Der Vortrag fasst dabei nicht nur die Ergebnisse des Aristoteles-Projekts zusammen, sondern zeigt auch auf wie im eigenen Unternehmen überprüft werden kann ob die verschiedenen Faktoren gegeben sind. Man kann sich also direkt für eine eigene Anwendung inspirieren lassen.

Der Endspurt

Bild: Pexels / Fauxels - Lizenz

Team, der Sprint ist fast zu Ende
Seht den Burndown, wie er brennt
Bald schon woll’n wir fertig werden
Stellt es her, das Inkrement

Integriert den Code auf PreProd
Bringt die Build Pipeline zum Glüh’n
Führt die letzten Code Reviews durch
Haltet mir den Master grün

Bringt die Features auf Production
Testet schnell in Regression
Aktiviert das Feature Toggle
Uns’re Nutzer warten schon

Baut ein Dashboard! Ein A/B-Test
Wird uns helfen, klar zu seh’n
Ob die Menschen uns’re Features
Finden, mögen und versteh’n

Und mit diesem bess‘ren Wissen
Was der Nutzer Wünsche sind
Soll ein neuer Plan entstehen
Für den neuen, nächsten Sprint

***

Wer erkennt, von welchem klassischen Gedicht dieses kleine Werk inspiriert ist, darf sich melden, ich gebe dann einen aus

Kommentierte Links (C)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Hier ist die mittlerweile hundertste (!!) Monatsübersicht über die erwähnenswertesten unter ihnen. Irre, was da zusammengekommen ist.

Kent Beck: “Friction” >> “Debt”

Carl von Clausewitz wäre begeistert, denn Kent Beck, einer der Erfinder von Extreme Programming, greift hier eine seiner Ideen auf. Ausgangspunkt ist die Überlegung, dass der Begriff der Technischen Schulden mittlerweile etwas in die Jahre gekommen ist, eine gewisse Unschärfe in der Bedeutung entwickelt hat und zum Teil konflikthaft aufgeladen ist. Auf der Suche nach etwas Besserem ist Beck bei der Friktion (Reibung) gelandet, jenem vor langer Zeit von Clausewitz eingeführten Begriff, dessen Aussage ist, dass viele kleinteilige Störungen grosse Vorhaben nachhaltig behindern und verzögern können. Ob dieser neue Begriff tatsächlich besser ist als der alte sei dahingestellt, zumindest kann er aber dort verwendet werden wo technische Schulden vorbelastet sind.

Christoph Roser: On the Team Structure at Toyota

Dafür, dass Toyota als Vorzeigefirma für Lean Management gilt, weiss man in Europa erstaunlich wenig darüber wie es intern strukturiert ist. Christoph Roser lüftet den Schleier an einer kleinen aber bedeutsamen Stelle und lässt uns einen Blick auf die Struktur der Teams auf der untersten Hierarchie-Ebene werfen. Die hier anzutreffenden Einheiten sind relativ klein (vier bis sechs Mitglieder) und werden von einem Vorarbeiter geleitet, der diesen Job nur in Teilzeit ausübt, in seiner restlichen Zeit aber der selben Arbeit nachgeht wie die restlichen Teammitglieder (u.a. als Springer, der dabei hilft Arbeitsspitzen abzufedern). Er hat keine (!) Weisungsbefugnis über die anderen, schreibt aber ihre jährlichen Bewertungen und pflegt die Skill-Matrix des Teams. Für die Methoden-Nerds: der Chapter Lead im Spotify Model ist erkennbar an den Toyota-Teamleiter angelehnt.

Emil: When Scrum Masters and Agile Coaches Unleash Their Team Building Madness

Ich lehne mich weit aus dem Fenster mit der folgenden Einschätzung: Emil von der Sarcastic Society ist zur Zeit der beste Satiriker der gesammten Agile Community. Seine Texte sind extrem überzeichnet, stellen aber gerade dadurch einige unter agilen Teams und Methodikern verbreitete Dysfunktionen ins Rampenlicht. In diesem Text hat er sich die verbreitete Unsitte vorgenommen, Teambuilding-Workshops derartig übermässig verspielt (und für introvertierte Personen latent übergriffig) zu machen, dass das Ergebnis für alle Beteiligten nur noch unangenehm ist. Wer schon ein bisschen in agil arbeitenden Unternehmen herumgekommen ist wird einiges wiedererkennen. Bitterböse und zutiefst witzig.

Philip Rogers: A Fresh Perspective on Forecasting in Software Development

Ob die Perspektive von Philip Rogers auf die Aufwandsschätzungen in der Software-Entwicklung frisch ist, hängt vermutlich vom Stand des eigenen Vorwissens ab, auf jeden Fall ist sie aber ausführlich. Aufbauend auf verschiedenen psychologischen Studien (die sich mit der allgemeinen Fähigkeit befassen, Prognosen abzugeben) identifiziert er drei Faktoren, die zu besseren Ergebnissen bei Aufwands- oder Zeitschätzungen führen: Training, Teamarbeit und Zusammenarbeit mit anderen Menschen, die ebenfalls gut im Aufwandsschätzen sind. Zusätzlich dazu arbeitet er die beiden schwerwiegendsten Ursachen für Fehleinschätzungen heraus, nämlich kognitive Verzerrungen und Signal-Rauschen. Vereinfacht gesagt fasst er nicht zusammen wie man besser schätzt, sondern wodurch. Ein feiner Unterschied.

Kurt Bittner, Pierre Pureur: Agility and Architecture

Ein bewusst kontrovers gehaltener Artikel, der sich unter anderem an der unter agil arbeitenden Entwicklern weit verbreiteten Ansicht abarbeitet, dass architektonische Entscheidungen zum letztmöglichen Zeitpunkt gefällt werden sollten. Ohne alle Argumente vorwegzunehmen - ganz so einfach ist es nicht, unter anderem deshalb weil niemals ganz klar ist, was der letztmögliche Zeitpunkt ist. Das an die Idee des Minimum Viable Product (MVP) angelehnte Gegenkonzept ist die Minimum Viable Architecture (MVA). Ein interessanter Ansatz.

Feature Toggles

Ein häufiges Argument gegen iterativ-incrementelle Softwareentwicklung ist, dass diese bei vielen grossen Anwendungen nicht funktionieren würde. Es gäbe zu viele verschiedene Anforderungen, die aufgrund geschäftlicher Zwänge (z.B. dem Beginn des Saison-Geschäfts oder dem Tag des Inkrafttretens eines Gesetzes) alle gleichzeitig in Betrieb genommen werden müssten und nicht nach und nach. Ein Big Bang-Release wäre daher in diesen Fällen unvermeidlich.

Auf den ersten Blick mag das wie ein valides Argument erscheinen, auf den zweiten gibt es aber trotz dieser Vorgaben eine Möglichkeit zum regelmässigen Fertigstellen, Integrieren und Testen neuer Funktionen. Sie basiert auf dem Konzept so genannter Feature Toggles (alternativ auch Feature Flags genannt), deren Funktion vereinfacht gesagt ist, bestimmte Teile einer Anwendung unsichtbar und unbenutzbar zu machen (welche das sind kann bei der Erstellung bestimmt werden).

Bedingt durch diese Technik ist es möglich, auch solche Funktionen live zu schalten, die für sich genommen oder zu diesem Zeitpunkt noch nicht live sein sollten. Ein typisches Vorgehen ist, das zu einem Zeitpunkt zu tun, an dem normalerweise keine Benutzung stattfindet (z.B. tief in der Nacht), die Akzeptanz-, Regression- und Lasttests einmal laufen zu lassen und die neuen Funktionen dann unsichtbar zu machen (man spricht dabei vom sogenannten "Austogglen").

Auch differenzierte Varianten des Austogglens sind möglich, z.B. das sichtbar-, bzw. unsichtbar machen für verschiedene Gruppen, verschiedene geografische Regionen oder verschiedene Zugangsberechtigungen. Bei Bedarf können so der Betrieb der alten Funktionen und das Testen der neuen Funktionen parallel stattfinden, und bei zeitlich versetzten Livegängen für verschiedene Märkte lässt sich das temporäre gleichzeitige Existieren verschiedener Branches vermeiden.

Selbst nach dem jeweiligen Livegang können Feature Toggles noch einen Zweck haben. Wenn einzelne Teile einer Anwendung einen wesentlichen Teil des Traffics erzeugen, kann es beispielsweise Sinn machen, sie auf diese Weise mit einer "Notfallabschaltung" zu versehen. Im Fall von Lastspitzen kann damit dann ein Crash des Gesamtsystems verhindert werden, stattdessen stehen nur einzelne Features vorrübergehend nicht zur Verfügung.

Um negative Seiten nicht zu verschweigen - sobald sie nicht mehr benutzt werden sollten Feature Toggles wieder entfernt werden, sonst blähen sie den Code unnötig auf und machen ihn schwerer verständlich (und ganz abgesehen davon, kann es bei ihnen zu versehentlicher Aktivierung und Bedienfehlern kommen, wodurch Anwendungen unbrauchbar werden können). Das passiert aber häufig nicht, weil anderes gerade wichtiger erscheint. Fehlender Clean Code ist dann die Folge.

Trotz dieses Risikos: grundsätzlich sind Feature Toggles sehr nützliche Werkzeuge, durch die auch das iterativ-incrementelle Ausliefern grosser Anwendungen möglich wird. Und dank ihnen kann man auch wunderbare Sätze formulieren, wie diesen hier: Wenn das austogglebare Feature eingetoggelt ist, der Feature-Toggle aber ausgetoggelt, dann ist das austoggelbare eingetoggelte Feature nicht mehr austoggelbar. So sieht es nämlich aus.

Dark Constraints

Bild: Unsplask / Jan Baborák - Lizenz

Egal ob es um Produkt-, Organisations- oder Personalentwicklung geht, jedem, der eines dieser Vorhaben angeht, muss bewusst sein, dass ihnen Begrenzungen (englisch: Constraints) gegeben sind. Das können ganz schlicht Budget-Begrenzungen sein, aber auch Grenzen der zulässigen Selbstorganisation. Auch Abhängigkeiten zu anderen Teams gehören dazu, ggf. sogar solche zum Wetter oder zu Jahreszeiten (Stichwort Weihnanchtsgeschäft).

Die Gemeinsamkeit all dieser Constraints ist, dass sie bekannt und erkennbar sind, in den meisten Fällen sogar dokumentiert. Dass das nicht selbstverständlich ist, kann man am Beispiel von anderen sehen, die zwar existieren und eine Wirkung haben, aber bestenfalls einen halboffiziellen Status haben und in manchen Fällen sogar überhaupt nicht thematisiert werden, so dass es eine gewisse Zeit dauern kann bevor man bemerkt, dass sie da sind.

Ein Beispiel für diese unsichtbaren Begrenzungen ist der Grad an Perfektionismus, der in der Organisation verbreitet ist. Ist er hoch, werden viele neue Ideen und Konzepte selbst dann nicht freigegeben und noch "fertig entwickelt" werden, wenn sie schon vorher vorführbar gewesen wären. Umgekehrt kann ein niedriger Grad an Perfektionismus dazu führen, dass letzte Entwicklungsschritte fast immer ausgelassen werden, da das Ergebnis ja "gut genug für den Moment" ist.

Auch der Grad an vorhandenem Vertrauen kann eine derartige Begrenzung sein, vor allem wenn es um Veränderungsvorhaben oder Konfliktklärungen geht. Weitere Beispiele wären Risiko-Affinität oder -Aversion, das (Nicht-)Vorhandensein von Hierarchiegläubigkeit, die grundsätzliche (Nicht-)Offenheit für Neues oder das Ausmass der gewohnheitsmässigen Verknüpfung von Pausen oder Tätigkeits-Durchführungen mit bestimmten Uhrzeiten oder Wochentagen.

Dave Snowden hat für diese Art von Begrenzungen den Begriff der Dark Constraints erfunden. Gemeint ist damit nicht dark (dunkel) im Sinn von böse sondern eher im Sinn von "im Dunkeln liegend". Wenn man sie kennt und weiss wo sie sind, kann man mit ihnen umgehen, wenn nicht wird man zu Beginn nicht merken, dass sie da sind, um dann irgendwann in einem ungünstigen Moment über sie zu stolpern, im Zweifel gerade dann, wenn man es am wenigsten gebrauchen kann.

Bei einer Bestandsaufnahme am Anfang eines Produkt-, Organisations- oder Personalentwicklungs-Vorhabens sollte die Suche nach Dark Constraints daher ein wesentlicher Punkt sein. Das ist nicht immer einfach (selbst den von ihnen Betroffenen ist die Existenz dieser Beschränkungen nicht immer bewusst), macht aber vieles, was später kommt, einfacher und nachvollziehbarer. Es ist also gut investierte Zeit.

Abhängigkeiten

Grafik: Pixabay / user1518572209 - Lizenz

Eines der stärksten und gleichzeitig am häufigsten unterschätzten Hindernisse für agiles Projekt- oder Produktmanagement sind Abhängigkeiten zwischen Organisationseinheiten. Während für ein Arbeitspaket auf externe Zulieferungen gewartet wird, kann nicht weitergearbeitet werden, der Fortschritt steht still und mit ihm auch die Liefer- und Reaktionsfähigkeit. Aber sind Abhängigkeiten ein einheitliches Problem, sind sie alle gleich? Natürlich nicht, es gibt Unterschiede.

Der Abhängigkeits-Typ von dem wir meistens sprechen wenn wir das Wort Abhängigkeit benutzen ist die asynchrone Abhängigkeit. Diese ist dann gegeben wenn die Zulieferung durch ein anderes Team, die eigene Arbeit und die nachgelagerte Arbeit eines wiederum anderen Teams sequentiell angeordnet sind. Erst wenn die Zulieferung erfolgt ist kann die eigene Arbeit beginnen, erst wenn diese abgeschlossen ist kann die Übergabe zum nachgelagerten Team erfolgen.

Wesentlich seltener denken wir bei Abhängigkeiten an den zweiten Typ, die synchronen Abhängigkeiten. Diese erfordern eine zeitgleiche Erledigung der eigenen Arbeit und der Arbeit der jeweils anderen Teams, z.B. dann, wenn in einem Markt der Euro eingeführt wird und alle Systeme gleichzeitig umgestellt werden müssen. Ggf. können die Arbeiten auch versetzt begonnen werden, abgeschlossen werden müssen sie aber möglichst gleichzeitig.

Wenn wir diese beiden Typen betrachten,¹ lässt sich erahnen, welcher der beiden im Kontext angestrebter Agilität das grössere Problem ist: es sind die asynchronen Abhängigkeiten. Wenn asynchron voneinander abhängige Teams für ihre Arbeitspakete die Statustypen Waiting und Blocked erfassen und aktuell halten, machen diese meistens bei den Durchlaufzeiten einen so grossen Anteil aus, dass man die Prozesseffektivität auf niedrigste Werte sinken sieht.

Als weitere Folge kommt dazu, dass die Erstellung von Produkt-Incrementen in überschaubaren Zeiträumen schwierig bis unmöglich wird. Durch die sequentielle Anordnung, die notwendigen Übergaben und die Tatsache, dass beim Eintreffen von Zulieferungen in der Regel noch eigene Tätigkeiten unvollendet sind und abgeschlossen werden müssen, kann sich die Erstellung nutzbarer Funktionalität (und deren Validiereung) in erstaunliche Längen ziehen.

Wenn es sich nicht vermeiden lässt, Abhängigkeiten zu haben, sind synchrone Abhängigkeiten deutlich besser. Bei ihnen ist Arbeit parallelisierbar, was bedeutet, dass sie gleichzeitig ausgeführt werden können und die Teams nicht aufeinander warten müssen. Die Waiting- und Blocked-Zeiten gehen so zurück, die Auslieferung beschleunigt sich und mit ihr die Reaktionsfähigkeit. Es ist aber wichtig zu verstehen, dass es auch bei den synchronen Abhängigkeiten nochmal zwei Untertypen gibt.

Technische synchrone Abhängigkeiten bedeuten, dass die Teams zwar parallelisiert arbeiten können, dass ihre Ergebnisse ohne die Kombination mit denen jeweils anderen aber noch keinen nutzbaren Mehrwert ergeben. Der vermutlich häufigste derartige Fall sind separate Komponenten-Teams für Frontend und Backend. Das ist besser als eine komplett sequentielle Anordnung, erfordert aber immer noch hohen Abstimmungsaufwand und gemeinsame Release-Termine.

Business-basierte synchrone Abhängigkeiten sind technisch unabhängig voneinander und eher fachlich oder kommerziell miteinander verbunden. Um beim oben genannten Beispiel der Euro-Einführung zu bleiben: dass sowohl der Webshop als auch das Redaktionssystem der Werbeprospekte auf die neue Währung umgestellt werden müssen wäre eine derartige fachliche Abhängigkeit, eine mit der Umstellung verbundene Werbekampagne auf allen Kanälen wäre eine kommerzielle.

Gerade vor dem Hintergrund, dass es möglich ist, technisch vollständige Features integriert und getestet auf Produktion zu bringen und dort durch ein Feature Toggle bis zu einem Stichtag unsichtbar zu machen, wird klar, wie weit die Konzentration auf business-basierte synchrone Abhängigkeiten dazu beitragen kann, Teams unabhängig voneinander zu machen. Stillstand durch gegenseitiges aufeinander Warten lässt sich so weitgehend verhindern.

¹Es gibt natürlich noch weitere Abhängigkeiten, z.B. finanzielle oder emotionale, die sind im Kontext von Projekt- oder Produktmanagement aber nicht von Bedeutung

Ein Bild sagt mehr als 1000 Worte (XXXVI)

Grafik: Vincent Deniel - CC BY NC 4.0

Vielleicht die prägnanteste Art den Grund dafür zu visualisieren, dass irgendwer irgendwann mal DevOps erfunden hat. Passiert wie hier zu sehen leider immer noch viel zu häufig.

Und ganz nebenbei: der Künstler hinter dieser Zeichnung feiert gerade das dreijährige Jubiläum seines Schaffens. Seinem Drawing-Blog zu folgen ist sehr zu empfehlen.

Small rule tweaks can have unintended consequences

Nigel Bakers Vortrag "Playing Games with Scrum" ist ein interessanter Ansatz zur Erklärung agiler Frameworks, und vor allem einer den nahezu jeder sofort nachvollziehen können wird. Selbst wenn man nicht alle Spiele kennt die er hier als Analogie verwendet, einige dürfte jeder bereits gespielt haben, und die anderen werden nachvollziehbar erklärt.

Was darüber hinaus noch erwähnenswert ist, ist der lebhafte Vortragsstil, der alleine für sich genommen ein ausreichender Grund ist, sich das Video anzusehen.

Lean-Metriken (II)

Bild: Pixabay / Prawny - Lizenz

Zweiter Teil der Übersicht über die Lean-Metriken (Teil 1 ist hier). Auch mit dieser Erweiterung ist die Aufzählung sicher noch nicht vollständig, irgendwann kommt mindestens noch ein dritter Teil. Zunächst aber soll es hier um die Fluss-Effektivität gehen, also um Metriken mit deren Hilfe sich erkennen lässt ob überhaupt die richtigen Tätigkeiten stattfinden oder ob gerade unnötig Geld und Zeit verbraucht werden. Wichtig ist dabei, dass sie im Zusammenhang mit den Durchlaufmetriken des ersten Teils gesehen werden können, und zwar sowohl für die Lead Time/Gesamtdurchlaufzeit als auch für ihre einzelnen Teilstrecken (dazu am Ende mehr).

Value Adding Time

Der Idealfall. In etwa als "Wertschöpfungszeit" übersetzbar sollte die Value Adding Time eigentlich den grössten Teil der Durchlaufzeiten ausmachen. Was dort geschieht kann je nach Art des Produkts oder der Dienstleitung sehr unterschiedlich sein, im Normalfall sind aber Tätigkeiten enthalten die zur Erstellung, Vermarktung und Inbetriebnahme von Produkt oder Dienstleitung gehören, ggf. einschliesslich von Vorarbeiten wie dem Einkauf oder nachgelagerter Tätigkeiten wie dem Kundenservice. Die Wichtigkeit ergibt sich daraus, dass es im Wesentlichen diese Tätigkeiten sind, für die Kunden Geld bezahlen.

Transportation Time

Der erste zu vermeidende Typ und gleichzeitig ein alter Bekannter. Transporte sind eine der klassischen Mudas des Toyota Production System (TPS), also eine nicht gewinnbringende aber Ressourcen verbrauchende Tätigkeit. Je nachdem, in welchem Rahmen sie gemessen wird, kann auch die Transportation Time sehr unterschiedlich aussehen, angefangen vom Werkstoff-Transport zum anderen Ende der Firma bis zum Containerschiff, dass das Produkt rund um die Erde fahren muss. Eine weitere Variante wäre das langsame Herunterladen eines digitalen Produkts durch eine schlechte Telefonleitung.

Waiting Time

Ebenfalls eine Muda, und dazu die vielleicht die am weitesten verbreitete. Überall dort, wo die Menschen oder Maschinen mehr Arbeit zu erledigen haben als sie bewältigen können, werden sich Aufgaben aufstauen und auf ihre Erledigung warten, was in grossen Organisationen auch Monate und sogar Jahre dauern kann. Als Zusatzeffekt erzeugen Wartezeiten, sobald sie auftreten, noch weitere Aufwände, da die wartenden Aufgaben aktuell gehalten und ggf. verworfen, neu formuliert, neu verhandelt oder repriorisiert werden müssen.

Blocked-Time

Die Blocked Time wird häufig mit der Waiting Time verwechselt, hat aber eine andere Natur. Wartende Aufgaben könnte man selbst erledigen, wenn man denn die Zeit hätte. Geblockte Aufgaben müssen durch jemanden anderen erledigt werden, der dafür zuerst seine gegenwärtige Tätigkeit abschliessen und sich die Aufgabe erklären lassen muss (ggf. kommen noch Preisverhandlungen und Beauftragungen dazu). Besser wäre es, diese Tätigkeiten selbst erledigen zu können, wodurch die Blocked Time verschwinden würde.

Repair Time

Noch eine Muda. Wenn man Repair Time nicht als den Reparaturaufwand nach einem Unfall versteht, sondern als die Zeit die für die Behebung von Hardware-Produktionsfehlern und Software-Bugs nötig ist, ist klar, dass sie so gering wie möglich sein sollte. Auch hier kann es zu negativen Zusatzeffekten kommen, da auch Reklamationen und Umtausche Aufwände erzeugen und die mit den Reparaturen betrauten Menschen dadurch aus ihren aktuellen Tätigkeiten herausgerissen werden, mit Verlangsamungen durch Context Switching und Rüstzeiten als Folge.

Red Tape Time

Hinter der Red Tape Time verbirgt sich die letzte Muda dieser Übersicht, das Overprocessing. Red Tape ist im Englischen ein Sammelbegriff für unnötig komplizierte Prozesse und unnötig bürokratische Vorschriften, und wer bereits in grossen Organisationen gearbeitet hat wird wissen, dass sie dort weit verbreitet sind (hier ein besonders verstörendes Beispiel aus einer deutschen Behörde). Und dass derartige Tätigkeiten nichts zur Wertschöpfung beitragen dürfte ebenfalls offensichtlich sein.

Process Effectivity

Setzt man jetzt die Value Adding Time und die ressourcenverbrauchenden aber nicht wertschöpfenden Varianten Transportation Time, Waiting Time, Blocked Time, Repair Time und Red Tape Time in Verhältnis zueinander, erhält man die Prozess-Effektivität. Wenn die gesamte Durchlaufzeit nur aus Value Adding Time besteht ist das Ergebnis ideal, wenn die Zeit überwiegend für die anderen Typen verbraucht wird ist es eher schlecht. In diesen Fällen macht es sinn, den Prozess so zu verändern, dass diese Aufwände zurückgehen.

Von der Prozess-Effektivität zu unterscheiden ist übrigens die Prozess-Effizienz. Dazu ein anderes mal mehr.

Chaos Engineering (III)

Bild: Pixabay / GlauchauCity - Lizenz

Dem regelmässigen Leser dieser Seite dürfte es aufgefallen sein, dass ich ein Fan von Chaos Engineering bin. Als technische Praktik kann es entscheidend dafür sorgen, dass die in den methodischen Frameworks vorgesehehene kontinuierliche Liefer- und Reaktionsfähigkeit tatsächlich auch stattfinden kann. Darüber hinaus lässt sich Chaos Engineering aber auch von der Technik lösen und selbst als methodischer Ansatz einsetzen.

Noch einmal kurz zur Erinnerung: Chaos Engineering stellt die Resilienz (und damit auch die Liefer- und Reaktionsfähigkeit) eines Systems sicher indem auf Produktion nach Zufallsprinzip wichtige Ressourcen temporär abgeschaltet werden (Server, Übertragungskapazitäten, etc.). Übersteht das System diesen Stresstest ist alles gut, übersteht es ihn nicht, wird klar, an welcher Stelle an Kompensations-Automatismen gearbeitet werden muss.

Auf dieser Abstraktionsebene beschrieben lässt sich die Idee problemlos auf soziele Systeme übertragen, also auf Teams, Abteilungen oder Projekte. Auch hier lassen sich einzelne Ressourcen (→ Personen) temporär aus den Arbeitsabläufen herausnehmen, um festzustellen ob die anderen diesen Ausfall kompensieren können. Ist das nicht der Fall, ist ein Problem identifiziert, das beim nächsten Urlaub oder Krankheitsfall für Störungen oder Stillstand sorgen würde.

Die Problembehebung ist dann relativ einfach, denn in fast allen Fällen liegt einer von zwei Root Causes vor: entweder fehlen den anderen Mitarbeitern die Kenntnisse, um die Tätigkeiten des ausfallenden Kollegen zu übernehmen. Das kann kompensiert werden, indem sie sich in Richtung T-Shape oder Full Stack entwickeln. Oder ihnen fehlen Zugriffsberechtigungen auf die vom ausfallenden Kollegen verantworteten Systeme, was sich lösen lässt, in dem diese erteilt werden.

Ein zum Glück seltener werdender dritter Root Cause liegt vor, wenn der ausfallende Kollege Code Ownership in Teilen der Anwendung hat, also vereinbart wurde, dass er als Einziger dort Änderungen vornehmen darf. Eine andere Variante dieses Problems ist es, wenn nur eine Person für bestimmte Bereiche Pull Requests annehmen, also Änderungen genehmigen darf. Die Lösung ist in beiden Fällen einfach - man muss nur diese limitierenden Regeln abschaffen.

Die Ergebnisse von "sozialem Chaos Engineering" sind häufig überraschend, da Wissensmonopole, Berechtigungs-Engpässe und Code Ownership nicht immer explizit gemacht werden. Oft sind sie eher unbemerkt entstanden und werden selbst von den Beteiligten in ihrer Tragweite unterschätzt. Um so wichtiger ist es herauszufinden, ob sie vorliegen. Und einen netten Nebeneffekt gibt es auch noch: die temporär abwesenden Kollegen haben Zeit für Weiterbildung oder Überstunden-Abbau.

Politik im Konzern

Bilder: Wikimedia Commons / Luke Fildes (1, 2) - Public Domain

Wenn in grossen Unternehmen Entscheidungen getroffen werden, bei denen es weniger um die Sache und mehr um die Wahrung von Partikular-Interessen geht, spricht man von politischem Verhalten. Worauf sie beruhen bleibt dabei aber meistens unklar. Verständnis für diese Motivationen schaffen kann passenderweise die Politikwissenschaft, und hier ein eher unerwarteter Zweig: das Teilgebiet der Internationalen Beziehungen.

Nicht ohne Grund werden die Abteilungen, Bereiche und Ressorts eines Konzerns immer wieder als "kleine Königreiche" bezeichnet. Nach innen sind sie hierarchisch gegliedert, nach aussen konkurieren sie um Ressourcen, gehen Bündnisse ein oder tragen Konflikte aus. Die Parallelen zu Staaten sind offensichtlich. Und da das Fach der Internationalen Beziehungen verschiedene Deutungsmodelle für Handlungs-Motivationen entwickelt hat liegt es nahe sie zu übertragen. Hier sind die Wichtigsten:

Idealismus

Wie es der Name sagt - der Idealfall. Der Idealismus geht davon aus, dass alle Beteiligten vernunftbegabt sind und rational handeln, was im Ergebnis dazu führt, dass alle kooperieren und an einem gemeinsamen grösseren Ziel arbeiten. Der Idealismus basiert auf einem positiven Menschenbild, kann aber bei häufiger Enttäuschung durch das nächste Deutungsmodell ersetzt werden.

Realismus

Der Realismus sieht in der Politik vor allem einen Kampf um Macht, was fast zwangsläufig in Konflikten enden muss, schliesslich kann nicht jeder gleichzeitig der Mächtigste sein. Sowohl in der internationalen Politik als auch in Konzernen scheinbar häufig anzutreffen, allerdings mit Vorsicht zu behandeln. Nicht nur der Realismus sondern auch seine Unterstellung basieren auf problematischen Menschenbildern.

Neo-Realismus

Naheliegenderweise eine Weiterentwicklung des Realismus. Als zentrales Handlungsmotiv wird nicht mehr Machtstreben unterstellt sondern ein Sicherheitsbedürfnis, das (basierend auf einem eher negativen Menschenbild) dazu führt, dass man einen zu grossen Machtzuwachs anderer verhindern will und in alle relevanten Entscheidungen einbezogen werden möchte. Kann in die Thukydides-Falle führen.

Institutionalismus

Der Institutionalismus baut auf den vorherigen Ansätzen auf und entwickelt sie weiter. Er geht davon aus, dass Zusammenarbeitsstrukturen (egal ob sie auf Rationalität, Machtstreben oder Sicherheitsbedürfnis beruhen) Eigendynamiken und Selbsterhaltungs-Bestrebungen entwickeln und sich so immer mehr verfestigen. Eine häufige (positive und negative) Folge ist die Herausbildung von Bürokratie.

Funktionalismus

Nochmal eine Weiterentwicklung. Im Funktionalismus wird davon ausgegangen, dass es die Funktion von Kooperation ist, noch mehr Kooperation zu erzeugen. Dort wo bereits zusammengearbeitet wird kommt es daher mit hoher Wahrscheinlichkeit dazu, dass das in Nachbar-Bereiche überschwappt (Spill Over-Effect). Das ist grundsätzlich positiv, kann aber auch in die Verflechtungsfalle führen.

Konstruktivismus

Abweichend von den anderen Ansätzen sieht der Konstruktivismus nicht (zweck)rationales Handeln als politisches Hauptmotiv, sondern die Ideen und Glaubenssätze mit denen die Beteiligten ihre Realitäts-Wahrnehmung konstruieren. In der Politik sind das z.B. Demokratie und Kommunismus, in Konzernen können es u.A. der Glaube an Mitbestimmung oder an geniale Anführer (Jobs, Musk, etc.) sein.

Natürlich gibt es noch zahlreiche weitere Theorien der Internationalen Beziehungen, die meisten sind aber nur Vorstufen oder Ableitungen der hier dargestellten (oder gelten als überholt, wie z.B. der zum Kommunismus gehörende historische Materialismus von Karl Marx), weshalb die hier genannten einen recht vollständigen Überblick über die zentralen Ideen bieten.

Wie bei allen abstrakten Denk- und Deutungsmodellen können auch die aus der internationalen Politik nicht alles erklären, sie bieten aber bewährte Erklärungsmuster mit deren Hilfe die Analyse komplexer (Konzern-)politischer Strukturen leichter fallen kann. Und in jedem Fall sind sie differenzierter (und damit brauchbarer) als die Zuweisung (un)moralischer Motive, mit denen sonst häufig versucht wird politische Hundlungen zu erklären.

Kommentierte Links (XCIX)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Nathan Furr, Kate O’Keeffe : The Hybrid Start-Up

In den letzten Jahren habe ich verschiedene "Corporate Startups", also Startup-artige Ausgründungen grosser Konzerne, bei Gründung und Wachstum begleiten dürfen. Aus dieser Erfahrung heraus kann ich das, was Nathan Furr und Kate O’Keeffe schreiben, bestätigen - derartige Konstellationen haben gegenüber klassischen Startups viele Vorteile. Sie sind von den traditionellen und oft verkrusteten Strukturen ihrer Muttergesellschaften befreit, können aber auf deren Expertise und Kontakte zugreifen und haben eine stabilere Finanzierung als die durch Wagniskapital-Runden. Was ich an dem Artikel besonders mag: er gibt auch Ratschläge was man tun und lassen sollte, um zu verhindern, dass die Schwerfälligkeit des Mutterschiffs sich auf das Tochterunternehmen überträgt.

Lucas Fernandes da Costa: How processes are born, why they can be damaging, and how to fix them

Dass es zu viele Prozesse gibt, ist eine Beschwerde, die man in nahezu jedem grösseren Unternehmen hören kann. Wesentlich seltener wird gefragt, wo sie herkommen und ob der Grund, wegen dem sie existieren, nicht eigentlich ein sinnvoller ist. Lucas Fernandes da Costa nennt den häufigsten Ursprung: irgendwann ist etwas schiefgelaufen, und um zu verhindern, dass es wieder passiert, wurden Regeln eingeführt. Da die nicht alle Eventualitäten abdecken können, kommt es trotzdem zu neuen Fehlern, die zu neuen Regeln führen, die dann von Konzern-Trollen missbraucht werden. Etc. Um die so entstandenen Prozesse wieder verschlanken zu können, muss daran gearbeitet werden, dass Root Causes, Auswirkungen und Wahrnehmungen von Fehlern sich ändern. Erst dann werden die Widerstände gegen Verschlankungsvorhaben zurückgehen.

Johanna Rothman: How to Measure All Your Work in Progress to Make Better Decisions

Dass Datengetriebenheit und Reduzierung paralleler Arbeit zu agilem Arbeiten gehören ist (hoffentlich) eine allgemein anerkannte Selbstverständlichkeit. Was in der Realität aber immer wieder passiert, ist, dass diese Praktiken nur auf der Umsetzungs-Ebene angewandt werden. Johanna Rothman zeigt am Beispiel eines ihrer Beratungsprojekte auf, dass auch die Management-Ebene und die Produktportfolio-Planung von ihnen profitieren können. Ein Punkt den sie dabei macht und den auch ich für wichtig halte: um den tatsächlichen Grad der Überplanung zu erkennen sollte der Status eines Projekts oder Arbeitspakets nicht zu granular sein. Alles woran bereits (Vor-)Arbeiten begonnen haben befindet sich in der Umsetzung. Die sich daraus ergebende Menge paralleler Arbeit ist in der Regel deutlich höher als man denkt.

Dan North: But what about the BAU work?

Nein, hier geht es nicht um agile Bauprojekte. Was Dan North meint sind Tätigkeiten aus der Kategorie "Business as usual", also das was man im Deutschen als Regeltätigkeiten bezeichnen würde. Sie treten vor allem bei Komponententeams auf, also dort wo eine Einheit nicht an allen Aspekten eines Produkts oder Service arbeitet, sondern nur ein einzelnes, allein genommen nicht wertstiftendes System entwickelt oder administriert. Die BAU-Tätigkeiten bestehen in solchen Fällen daraus die immer gleiche Tätigkeit auszuüben, die von aussen angefragt wird, etwa das Konfigurieren von Firewalls oder Datenbanken. Seine Empfehlung (der man sich nur voll anschliessen kann) ist es, möglichst wenige derartige Teams zu haben und stattdessen crossfunktionale Einheiten zu schaffen, die alles für ihre Produktentwicklung Notwendige selbst machen können und dürfen. Nur so lässt es sich verhindern, dass ständig jeder auf jeden wartet und dadurch nichts vorangeht.

Willem-Jan Ageling: SAFe Scrum — Is it actually Scrum?

Willem-Jan Ageling hat sich schon seit einiger Zeit als fundierter Kenner und Kritiker von SAFe positioniert, mittlerweile sind über 20 Artikel von ihm zu diesem Thema zusammengekommen. In diesem hier geht es um die neueste Version dieser ständig erweiterten Methode, und obwohl er weiterhin kritisch ist sieht er auch Positives - an einigen Stellen entwickelt sich SAFe in die richtige Richtung, an anderen wird aufgehört etablierte Begriffe falsch zu benutzen. Auch ich habe diesen Eindruck: SAFe ist zwar noch immer nicht das was ich agil nennen würde, es ist aber näher daran als jemals zuvor.

Empathie-Lücke und Subjektive Validierung

Cognitive Biases, zu deutsch verzerrte Wahrnehmungen, sind häufiger, als wir es uns eingestehen wollen. Nahezu alle Aspekte unseres Lebens sind davon betroffen, dass wir die Realität nicht immer so wahrnehmen wie sie ist, sondern so wie wir sie uns vorstellen. Auch in der Produktentwicklung kommen derartige Verzerrungen vor, und zwei von ihnen können besonders unschöne Auswirkungen haben: die Empathie-Lücke und die subjektive Validierung.

Empathie-Lücken liegen vor, wenn wir nicht in der Lage sind, uns in die Situation anderer Menschen hineinzuversetzen. Die Ursache dafür sind in der Regel Unterschiede in Herkunft, Alter, Geschlecht, Ethnie oder anderen Faktoren. Warum das in der Produktentwicklung ein Problem ist, dürfte offensichtlich sein - schlimmstenfalls entwickeln wir Produkte an den Bedürfnissen oder Vorlieben der Zielgruppe vorbei, mit der Folge, dass sie am Markt nicht erfolgreich sind.

Eine subjektive Validierung bedeutet, dass wir uns selbst unbewusst zum Massstab für andere machen. Unsere eigenen Wahrnehmungen, Gefühle und Vorlieben kommen uns so selbstverständlich vor, dass wir gar nicht auf den Gedanken kommen, dass andere sie nicht teilen können. In der Produktentwicklung bedeutet das, dass wir schlimmstenfalls nur das entwickeln, was wir selbst verstehen und gut finden und nicht das was auch die Zielgruppe verstehen und brauchen würde.

Ein Beispiel, mit dem man das plastischer machen kann, sind die Schlüsselkarten-Lichtschalter in Hotelzimmern. Sir wurden um das Jahr 2000 herum entwickelt und beruhen auf einer simplen Idee: das Licht im Zimmer lässt sich nur einschalten, wenn die Karte, mit der man auch die Zimmertür öffnet, in einen Schlitz an einem Hauptschalter steckt. Verlässt man das Zimmer, nimmt man die Schlüsselkarte mit, das Licht geht wieder aus und das Hotel spart Strom.

Wir können jetzt versuchen uns vorzustellen, wie wir reagiert hätten, wenn man uns damals diese Idee vorgestellt hätte. Vermutlich positiv. Die Idee klingt gut, man versteht sofort worum es geht, sie ist relativ einfach umzusetzen und mit dem Stromsparen dient sie einem Zweck, der Wirtschaftlichkeit und Umweltschutz vereint. Auch die Manager der Hotelketten waren damals sofort überzeugt, Schlüsselkarten-Lichtschalter sind heute der fast überall anzutreffende Standard.

Das Problem an dieser eigentlich schönen Geschichte: die Idee hat in der Realität nicht gut funktioniert. Viele Hotelgäste verstanden die Funktionsweise nicht und hielten das Licht für kaputt, andere fanden im Dunkeln den Schlitz nicht, wieder andere waren es gewohnt, die Schlüsselkarte im Portemonnaie mit sich zu tragen und vergassen sie ständig im Zimmer. Die Folgen waren schlechte Bewertungen und hoher Arbeitsaufwand für das ständig  zur Hilfe gerufene Personal.

Heute steckt in fast allen Hotels eine zweite Karte dauerhaft in den Schlitzen der Hauptschalter, die dadurch ständig angeschaltet sind. Es gibt zwar meistens den Hinweis, dass man durch das Herausziehen Strom sparen kann (wie oben auf dem Bild), wer sich erkundigt wird aber erfahren, dass das nur selten passiert. Am Ende hat die eigentlich gute Idee also nur dazu geführt, dass in allen Zimmern ein zusätzlicher, kaum genutzer und unnötig komplizierter Lichtschalter eingebaut wurde.

Um wieder zum eigentlichen Thema zurückzukommen - wenn es uns schon bei so einfachen Einrichtungen wie Lichtschaltern und Schlüsselkarten schwer fällt uns in die Anwender hineinzuversetzen, wieviel schwieriger ist es dann bei komplizierten Geräten oder Software-Anwendungen? Das Risiko, dass wir an Bedürfnissen und Vorlieben vorbeientwickeln ist immens, auch (und gerade dann) wenn wir das Gefühl haben, das alles einfach und offensichtlich wäre.

Als Mittel gegen Empathie-Lücken und subjektive Validierungen bleibt am Ende nur eine Möglichkeit: Vertreter der Zielgruppe müssen möglichst früh als Tester und Feedback-Geber in den Entwicklungsprozess eingebunden werden. Onsite Custumer in XP, MVPs in Lean Startup, Sprint Reviews in Scrum und viele ähnliche Konzepte wurden aus genau diesem Grund erfunden. Nur so lässt sich feststellen, ob die eigenen Annahmen stimmen oder nicht.

Zuletzt noch ein kleiner Erfahrungswert: der vermutlich stärkste Indikator für das Vorhandensein der hier besprochenen verzerrten Wahrnehmungen ist die feste Überzeugung, von ihnen nicht betroffen zu sein. Überall dort, wo voller Selbstsicherheit behauptet wird die eigenen Kunden schon zu kennen und sie darum nicht einbeziehen zu müssen, ist es dringend geboten genau das schnellstmöglich zu tun.

Agile Product Design From the Trenches

Mit seinen Büchern Lean from the Trenches und Scrum and XP from the Trenches ist Henrik Kniberg vor langer Zeit bekannt geworden, da liegt es nahe das Benennungsmuster weiterzubenutzen, in diesem Fall als Agile Product Design from the Trenches (mal sehen ob daraus auch noch ein Buch wird).

Inhaltlich geht es in diesem Vortrag darum, wie bei Minecraft (seinem aktuellen Arbeitgeber) Produktentwicklung stattfindet. Nicht revolutionär neu, aber auf jeden Fall ist es interessant zu sehen wie die Ideen von Agile und Lean Startup dort angewandt werden.

The Agile Bookshelf: How Big Things Get Done

Bild: Wikimedia Commons / Fred Romero - CC BY 2.0

Da die anekdotische Evidenz auf der viele Berater-Ratschläge beruhen, eine recht dünne Grundlage für Entscheidungen sein kann, ist es um so willkommener, wenn jemand seine Aussage auf Basis einer soliden Datenbasis macht. In diesem Fall ist es einmal mehr der Oxford-Professor Bent Flyvbjerg, dessen Forschung ich ja von Zeit zu Zeit bereits zitiert habe. Seine neuesten Erkenntnisse hat er in einem Buch zusammengefasst, das den schönen Namen How Big Things Get Done trägt.

Das Thema des Buches ist sein Forschungsschwerpunkt, das Scheitern und Gelingen grosser Projekte, wobei "gross" hier eine weite Spanne umfasst. Behandelt werden riesige Vorhaben wie das der Bau des Guggenheim-Museum in Bilbao oder das Drehen eines Hollywood-Films, aber auch relativ kleine wie die (spektakulär aus dem Ruder gelaufene) Renovierung einer Küche in einem New Yorker Wohnhaus. Insgesamt hat er tausende untersucht, und in ihnen macht er zwei Grundmuster aus.

Scheiternde Projekte zeichnen sich für Flyvbjerg durch ein Vorgehen aus, dass er "thinking fast, acting slow" nennt, und bei dem ein wenig durchdachter Plan zu ständigen Umsetzungsproblemen führt. Umgekehrt führt "thinking slow, acting fast", also ein sorgfältiges Planen, zu einer schnellen und problemlosen Umsetzung. Aber bedeutet das etwa, dass er durch seine Forschung die Überlegenheit eines Wasserfall-Vorgehens bewiesen hat? Nun, nicht ganz.

Gute Planung im Sinn von thinking slow zeichnet sich laut seinem Buch dadurch aus, dass sie bereits in sich iterativ angelegt ist und in kurzen Zyklen versucht, Annahmen und Hypothesen zu validieren. Als Methoden mit denen das stattfinden kann, nennt er neben Klassikern wie Coputer-aided Design und Lean Startup auch eher unbekannte wie das Pixar-Planning auch der gleich benannten Firma. Diese Vorgehensweisen entsprechen eher agilem Vorgehen als Wasserfall.

Ebenfalls einem agilen Ansatz entsprechend ist die Art der Umsetzung, die regelmässig in Fällen von thinking slow, acting fast zu finden ist: Modularität. Wenn statt auf einen Big Bang-Release darauf hingearbeitet wird, dass viele kleine, bereits für sich Mehrwert stiftende Liefergegenstände erzeugt werden, dann wird das Projekt erfolgreicher. Und Flyvbjerg erklärt das nicht nur am Beispiel von Software, sondern auch anhand von Hochhäusern, U-Bahnen und Satelliten.

Für alle die seinen Erkenntnissen nicht folgen wollen zeigt er deutliche Konsequenzen auf. Eine der von ihm aufgeführten Statistiken besagt zum Beispiel, dass 18 Prozent aller IT-Projekte die geplanten Kosten um mehr als 50 Prozent überschreiten, dass in dieser Gruppe die Überschreitung im Durchschnitt (!) aber bei 447 Prozent liegt (!). Wenn es schief geht, dann richtig. [Siehe dazu auch seinen Artikel The Empirical Reality of IT Project Cost Overruns]

Um kein Missverständnis entstehen zu lassen, How Big Things Get Done ist keine Buch über Agile Vorgehensmodelle (der Begriff Agile kommt kein einziges mal vor), es zeigt aber empirisch validiert auf, dass viele Grundprinzipien auf denen agiles Arbeiten aufbaut eher zu erfolgreichen Projekten führen als solche die eher klassisch durchgeführt werden. Alleine, dass das aus einer externen Perspektive bestätigt wird, macht das Buch zu einem, dass man auch ausserhalb der Agilen Filterblase empfehlen kann.