Agile Success Stories: Agile QA

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist bedauerlich, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine an der ich vor längerer Zeit beteiligt war betraf die Qualitätssicherung in einem grossen IT-Projekt. Die hier tätigen Tester galten in der allgemeinen Wahrnehmung als doppelt problematischer Schwachstelle: am Ende fast jedes Sprints wurden in den Entwicklungsteams die Tests der dort programmierten Features nicht mehr rechtzeitig fertig, und nach dem Sprintende waren die Regressionstests häufig zuerst grün, enthielten aber Wochen später plötzlich doch Fehlermeldungen.

Eine Analyse der Entwicklungsabläufe zeigte schnell zwei Hauptprobleme auf: zum Einen gab es in den Teams wasserfallartige Abläufe, in deren Rahmen die Entwickler lange unter sich arbeiteten, und die Tester erst kurz vor Sprintende erfuhren, was sie zu testen hatten (und das dann unter Zeitdruck tun mussten) zum Anderen hatte sich die übergreifende Regressionstest-Suite mit der Zeit selbst zu einem schwerfälligen Legacy-System entwickelt, dass nur noch aufwändig anzupassen war.

Dementsprechend wurden drei Verbesserungsmassnahmen durchgeführt. Zuerst wurden die Tester früher in die Abläufe ihrer Teams integriert. In den Backlog Refinements wurden sie daran beteiligt, die Akzeptanzkriterien testbar zu verfassen statt abstrakt, ihre Testaufwände wurden stärker in den Aufwandsschätzungen berücksichtigt und beim Planen der Sprints wurden Grösse, Auswahl und Anzahl der Entwicklungs-Aufgaben so vorgenommen, dass am Ende genug Zeit zum Testen blieb.

Als zweite Massnahme erfolgte eine stärkere Einbeziehung der Software-Entwickler in die QA-Abläufe. Wie oben geschrieben hatten die bis dahin das Testen als ein nachgelagertes Thema gesehen, das sie selber nicht mehr betraf. In dem verbesserten Vorgehen wurde dagegen eine Testpyramide angestrebt (siehe hier), in der bestimmte Mengen an (von den Entwicklern erstellten) Unit-, Integrations- und Lasttests zu einem Abnahmekriterium wurden, was das Testen am Sprintende deutlich beschleunigte.

Als Drittes wurde eine Überarbeitung der Regressionstest-Suite vorgenommen, die zu einem eigenen Problem geworden war. Bis dahin war sie einfach nach jedem Sprint um weitere Tests erweitert worden, während die bestehenden nur angepasst wurden, wenn (und nur dort wo) es Änderungen an den getesteten Funktionen gegeben hatte. Aufgrunddessen waren viele Tests redundant, kompliziert und unübersichtlich, was Anpassungen extrem aufwändig machte.

Um das zu verbessern wurde die Testsuite modularisiert und parametrisiert. Das Eine bedeutete, dass bestimmte Validierungen (z.B. des Login) nicht mehr in verschiedenen Tests enthalten waren, sondern nur noch in einem einzigen Modul, das dafür in beliebig viele Tests eingebunden werden konnte. Das Andere bedeutete, dass bestimmte variable Informationen (Browser, Ordnerpfade, etc.) nicht mehr hart im Test standen, sondern an einer zentralen Stelle systemweit geändert werden konnten.

In Summe führten diese verschiedenen Massnahmen dazu, dass die zu Beginn genannten Probleme fast völlig verschwanden. Die Tests (und mit ihnen die neuen Features) wurden in den Sprints fertig, in denen sie auch programmiert wurden, und die Aktualisierung der Regressionstests benötigte nur noch die Arbeit an einzelnen Modulen oder Parametern, statt an zig Stellen, wodurch versehentliche Seitenauswirkungen der neuen Features sofort gefunden werden konnten, statt Wochen später.

Am Ende ist es eine Binsenweisheit: eine Kette ist nur so stark wie ihr schwächstes Glied, und in vielen Softwareentwicklungs-Organisationen ist dieses schwächste Glied die Qualitätssicherung. Auch hier die agilen Praktiken einzuführen, und zwar sowohl technisch als auch prozessual, ist etwas, wovon alle Beteiligten massiv profitieren können.

Kommentierte Links (CXXXVIII)

Bild: Pexels / Ekam Juneja - 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.

Mike Fisher: Twitching Before You Sprint

Dass sich die Welt (oder zumindest die Welt der Software-Entwicklung) immer schneller dreht, merkt man auch daran, dass Vorgehensweisen die früher als unglaublich schnell galten, plötzlich als langsam wahrgenommen werden. Mike Fisher empfiehlt hier zum Beispiel anstatt der üblichen Sprints (die normalerweise ein bis vier Wochen dauern) einen deutlich schnelleren Modus: kleine Mikro-Vorhaben, die er "Twitches" (Zuckungen) nennt. Mal sehen, wo diese Beschleunigung noch hinführt.

Steve Blank: Your Startup Is Probably Dead On Arrival

Apropos Beschleunigung. Steve Blank geht in diesem Blogpost davon aus, dass Startups die vor Beginn der Durchbrüche der KI-Technologie gegründet wurden, bereits jetzt technisch und prozessual abgehängt sind - und das selbst dann, wenn sie erst wenige Jahre alt sind (für ihn trifft das auf alle zu, die vor 2025 gegründet wurden). Der aus seiner Sicht entscheidende Paradigmenwechsel: die Erstellung von Software ist plötzlich so billig, dass hier ein limitierender Faktor komplett entfällt.

Christina Wodtke: Everyone on Your Team Is Right (And That’s the Problem)

Das was Christina Wodtke in ihrem Artikel beschreibt, habe ich selbst zigfach erlebt: verschiedene Einheiten oder Hierarchieebenen einer grossen Organisation sind so stark von ihren jeweiligen Sachzwängen, Erfahrungen und Glaubenssätzen geprägt, dass jede andere Sichtweise ihnen widersinnig erscheint, und jeder der eine andere Sichtweise hat irrational. Was sie als Ausweg aus dieser Situation sieht, würde ich unterschreiben: man muss sich selbst aktiv in die jeweils andere Position begeben.

Doc Norton: This Has Happened Before. It's Happening Again.

Dass im Moment ganze Berufe von den Fortschritten in der Künstlichen Intelligenz grundlegend verändert werden dürfte unstrittig sein, und dass die Softwareentwicklung einer dieser Berufe ist, ebenso. Ob dieser Umbruch ein nie dagewesenes Ausmass hat, ist dagegen diskutabel, Doc Norton kann mehrere Beispiele vergleichbarer vergangener Umbrüche nennen, an die sich die Entwickler auch angepasst haben. [Ein Zusatz-Link: im Pragmatic Engineering-Podcast äussert sich Grady Booch sehr ähnlich.]

Jannik Reigl: What if Germany isn’t very good at research?

Als letztes ein grundsätzliche Beobachtung, die ich ebenfalls schon in vielen Firmen gemacht habe. In Deutschland sind wir offensichtlich sehr gut darin, bestehende Technologien und Produkte weiterzuentwickeln und ihre Herstellung zu optimieren. Wenn es zu Disruptiven Innovationen und Sprunginnovationen kommt, tun wir uns dagegen oft schwer. Jannik Reigl versucht zu erklären, welche Faktoren uns in diese Situation geführt haben.

Cockburn's Razor

In der englischen Sprache gibt es die schöne Firur des Razors (Rasiermessers) mit dem ein Vorgehen bezeichnet wird, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert" werden. Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), es gibt aber auch weitere, wie zum Beispiel diesen hier.

Cockburn's Razor ist benannt nach Alistair Cockburn, einem der initialen Unterzeichner des Manifests für agile Softwareentwicklung. Wann genau er entstanden ist lässt sich nicht mehr genau zurückverfolgen, es wird aber vermutlich irgendwann nach Mitte der 90er Jahre gewesen sein, da Cockburn erst ab dieser Zeit einen Bekanntheitsgrad hatte, der es möglich machte, seinen Namen für die Popularisierung von Vorgehensmodellen zu benutzen. Er lautet:

Don't add stept to process until you need them
Delete steps from process as soon as you can
Apply this to every file, every process doc, every CSV Column
If it doesn't serve Ring 0 right now, archive it or delete it

Alistair Cockburn, Cockburn's Razor

Diese Faustregel wirkt auf den ersten Blick eingängig, da sie ein einfacher Weg ist, um sowohl soziale als auch technische Prozesse schlank zu halten, sie ist aber in vielen Organisationen nur schwer umzusetzen. Der Hauptgrund dafür ist der vor allem in grösseren Einheiten stark verbreitete Wunsch, möglichst viel Standardisierung, Vergleichbarkeit und Stabilität zu haben, welcher wiederum auf der Hoffnung beruht, dadurch die Transparenz und Steuerungsfähigkeit zu erhalten.

Selbst wenn es gelingen sollte, diese Quelle ständig nachwachsender Bürokratie zu neutralisieren, bleiben aber ggf. noch Probleme in der individuellen Dimension. Vor allem auf den unteren Ebenen einer Organisation gibt es Menschen, die eine kategorische Ablehnung gegen Prozesse und Meetings jeglicher Art entwickelt haben (siehe hier) und sie darum grundsätzlich alle abrasieren wollen - selbst dann, wenn sie einen sinnvollen Zweck haben. Die müssen überzeugt oder überstimmt werden.

Die Umsetzung von Cockburn's Razor erfordert daher nicht nur ein ständiges Überprüfen und Anpassen, sondern in der Realität auch ein kontinuierliches Informieren, informiert Werden, Überzeugen und Aushandeln. Es ist also keine leichte und eindeutige Lösung, trotzdem aber eine die besser für die Verschlankung und Schlankhaltung von Prozessen geeignet ist als die meisten anderen.

Greenfield, Brownfield, Blackfield

Es gibt Begrifflichkeiten, die man irgendwann benutzt ohne gross darüber nachzudenken. Im IT-Projektmanagement gehört dazu das Gegensatzpaar Greenfield und Brownfield, welches vereinfacht gesagt für Neuentwicklungen und Weiterentwicklungen von Systemen steht. Wie ich vor kurzem erfahren habe, gibt es aber auch noch eine dritte, bisher neue Kategorie - die des Blackfield, wobei ausgerechnet die in meinem Umfeld relativ häufig ist.

Alle drei sind Teile der metaphorischen Sprache, einer alten, durch das Extreme Programming popularisierten Praktik des Software-Projektmanagement, bei der man komplexe Sachverhalte dadurch nachvollziehbar macht, dass man für ihre Beschreibung Worte des alltäglichen Lebens benutzt. Da die drei "Feldtypen" jeweils typische Ausgangslagen von Entwicklungsprojekten beschreiben, lohnt es sich, sie zu kennen. Hier sind sie:

Greenfield

Zu Greenfield gibt es in der deutschen Sprache sogar eine Entsprechung, nämlich das Beginnen eines Vorhabens "auf der grünen Wiese", wo vorher noch nichts war. Das bedeutet keine bestehenden Strukturen und Architekturen, keine technischen Schulden und keine hohen Betriebsaufwände, auf der anderen Seite aber auch keine Bestandskunden und kein bereits existierendes Business Model. Wenig überraschend: Entwickler lieben Greenfield, Manager sind eher Misstrauisch ihnen gegenüber.

Brownfield

Ohne dass es eine gebräuchliche deutsche Übersetzung gibt, kann man sich Brownfield-Projekte wie Vorhaben auf einem schlammigem Acker vorstellen, in dem die Reste vergangener Vorhaben versunken oder untergepflügt sind. Bestehende Strukturen, Architekturen und technische Schulden (und Business Models) gibt es hier mehr als genug, weshalb alle weiteren Schritte mit etwas "Archäologie" beginnen müssen, um zu verstehen auf was für Fundamente man aufbaut und in welchem Zustand diese sind.

Blackfield

Blackfield ist die neue, mir bisher noch unbekannte Analogie. Um beim Bild zu bleiben: man steht hier auf verbrannter Erde. Gescheiterte Ablöseprojekte, abgebrochene Weiterentwicklungen, hastige Notlösungen und nicht dokumentierte Hotfixes haben ein fragiles Trümmerfeld zurückgelassen, auf dem selbst kleine Veränderungen zu Destabilisierungen und Zusammenbrüchen führen können, die umfangreiche (und teure) Stütz- und Reparaturmassnahmen notwendig machen.

Was vielen nicht bewusst ist: in grösseren und älteren Organisationen (Banken, Behörden, etc.) sind Brownfield-Umgebungen der Normalfall und Blackfield-Umgebungen keine Seltenheit, da IT-Systeme hier z.T. seit Jahrzehnten unter hohem Spardruck entwickelt wurden. Das hat zur Folge, dass bei jedem neuen Vorhaben mit ungeplanten Mehrarbeiten von nicht genau vorhersagbarem Umfang zu rechnen ist, im Extremfall bis hin zu einer Vervielfachung des ursprünglich angenommenen Arbeitsaufwandes.

Um nicht in diese Situation zu geraten, macht es Sinn, die alten Relikte und Ruinen von Zeit zu Zeit zu abzureissen, den Untergrund wieder zu verfestigen und schädliche Rückstände zu entsorgen. Refactoring, wie man in der Softwareentwicklung sagt. Um die Metapher auf die Spitze zu treiben: dabei kann ein Revierpark entstehen, also eine renaturisierte Industriebrache, auf der dann wieder erneut mit einem Greenfield-Ansatz begonnen werden kann.

Conceptual Knowledge vs Procedural Knowledge

Grafik: CCNull / Marco Verch - CC BY 2.0

Beim Lesen von David Epsteins Buch Range sind verschiedene Konzepte aus meinem Psychologie-Studium wieder emporgestiegen, unter anderem die Prozeduralen und Konzeptionellen Probleme, bzw. der zu ihrer Lösung notwendigen Wissensgebiete des Prozeduralen und Konzeptionellen Wissens. Es handelt sich dabei um universell anwendbare Ansätze, die aber in meinem beruflichen Umfeld noch einmal besondere Implikationen haben.

Prozedurales Wissen (umgangssprachlich auch als Know-How bezeichnet) umfasst Informationen, die unmittelbar anwendbar sind, seien es mathematische Rechenwege, Navigationsanweisungen oder Kochrezepte. Die Prozeduralen Probleme, für deren Lösung sie gedacht sind, treten regelmässig und in immer vergleichbarer Form auf, so dass die Problemlösung im Wesentlichen aus der Wiederholung früherer Lösungen bestehen kann.

Konzeptionelles Wissen umfasst dagegen Informationen über abstrakte aber universell gültige Wirkungszusammenhänge, etwa Grundrechenarten, die Bedeutung von Strassenschild-Formen und die geschmacklichen und chemischen Eigenheiten und (In)Kompatibilitäten von Kochzutaten. Die Konzeptionellen Probleme, für deren Lösung sie gedacht sind, sind komplex, dynamisch oder neuartig, so dass die Problemlösung jeweils neu gefunden und validiert werden muss.

In der Welt der Organisation von Arbeitsabläufen lassen sich diese beiden Wissensgebiete im Wesentlichen auf zwei bekannte Vorgehensmodelle mappen: Prozedurales Wissen findet sich vor allem im Lean Management, mit dem Fertigungsstrassen, Callcenter und ähnliche Einrichtungen optimiert werden können, während sich Konzeptionelles Wissen vor allem in agilen Arbeitsweisen wiederfindet, die in Produkt-Neuentwicklungen innovative Wege finden müssen.

Was Epstein nun in seinem Buch schreibt (und durch wissenschaftliche Studien belegt) ist aber, dass die Menschen eine grundsätzliche Neigung zu Prozeduralem Wissen haben, da es einfache Verständlichkeit, sofort nachvollziehbare Lösungswege und schnelle Fortschritte ermöglicht. Diese verzerrten Präferenzen gehen so weit, dass oft selbst bei der Lösung Konzeptioneller Probleme versucht wird, diese mit Prozeduralem Wissen zu lösen - selbst dann, wenn das gar keinen Sinn macht.

Auf die moderne Arbeitswelt übertragen: selbst für die Lösung neuartiger Probleme, für die eigentlich Systems Thinking, Mustererkennung, Inspect & Adapt und ähnliche abstrakte Ansätze die Richtigen wären, versuchen viele Menschen und Organisationen zunächst reflexartig auf Best Practices, Industrie-Standards, Playbooks und ähnliche Anleitungen zurückzugreifen. Das Scheitern vieler digitalen, agilen und sonstigen Transformationen dürfte darin begründet sein.

Um noch tiefer zu bohren: auch den Grund für die Bevorzugung Prozeduralen Wissens fasst Epstein zusammen, und es ist auch ein ganz einfacher - im Gegensatz zum anspruchsvolleren und vergleichsweise schwer zu durchdringenden Konzeptionellen Wissen erfordert das Prozedurale Wissen weniger gedankliche Anstrengung und weniger Lernaufwand. Dass es bevorzugt wird, liegt also schlicht an der geistigen Bequemlichkeit vieler Menschen.

Für das Innovations- und Change Management beutet das, dass seine Vertreter bereit sein müssen, auch als unbequem wahrgenommen zu werden, zumindest so lange bis im jeweiligen Einzelfall beweisbar ist, dass Konzeptionelles Wissen auch tatsächlich der passende Weg zur Lösung Konzeptioneller Probleme ist. Und als Schlusspointe: auch die Kategorisierung von Wissen und Problemen in Konzeptionell und Prozedural ist Konzeptionelles Wissen. Hilfreich, aber nicht für jeden sofort zugänglich.

Project Manager of my Heart (A Programmer Love Song)

Was wäre die Welt ohne KI? Zumindest wäre sie ärmer an Liedern wie diesem hier, das herrlich durchgeknallt die Zuneigung eines Softwareentwicklers zu seinem (in agilen Methoden bewanderten) Projektmanager besingt.

Und als wäre das nicht bereits genug, sind im Text ausserdem noch zahlreiche IT-Fachbegriffe untergebracht. Ein wahres Nerd-Feuerwerk.

Make Meetings great again

Manche Erkenntnisse hat man unbewusst bereits seit langem, man muss aber einmal darauf hingewiesen werden, damit sie es explizit ins Bewusstsein schaffen. Einen derartigen Aha-Effekt habe ich vor kurzem während des Auftritts der Psychologin Rebecca Hinds im Unsiloed Podcast gehabt, in dem sie ein verbreitetes Problem auf den Punkt brachte: die meisten Menschen werden unbewusst darauf konditioniert Meetings schlimm zu finden und abzulehnen.

Die Art auf die das stattfindet dürfte jeder schon irgendwann erlebt haben. Wenn (aus welchem Grund auch immer) das Gespräch auf das Thema Meetings kommt, werden Augen verdreht und es wird gestöhnt. Nur noch Meetings habe man im Kalender, heisst es dann in der Regel, man käme zu nichts anderem mehr. Und sinnlos seien sie auch, eine einzige Zeitverschwendung. Und früher oder später kommt der Spruch, dass statt des Meetings auch eine Email gereicht hätte, darauf kann man wetten.

Natürlich sind diese Klagen in dieser Absolutheit nicht gerechtfertigt. Es ist zwar sicher ein grosser Teil aller Meetings hinterfragbar, viele haben aber einen sinnvollen oder sogar unverzichtbaren Zweck (mehr dazu hier). Was aber durch die Dauerbeschwerden entsteht, ist schlimmstenfalls sogar ein starker Konformitätsdruck, Meetings in der Öffentlichkeit ebenfalls kategorisch schlecht zu finden - selbst wenn man das selbst gar nicht so sieht.

Rebecca Hinds stellte im Podcast dazu ein bemerkenswertes Forschungsergebnis vor: wenn Personen sowohl einzeln als auch Gruppen gefragt wurden, was sie von Meetings hielten, gingen die Antworten deutlich auseinander. In der Gruppe waren die Bewertungen signifikant negativer als in Einzelbefragungen, was ein klarer Indikator dafür ist, dass diese Aussagen nicht auf Fakten zurückzuführen waren, sondern auf die (angenommenen) Erwartungshaltungen der Gruppe.

Um das Ganze ins Positive zu drehen: wenn die weit verbreitete und für die Zusammenarbeit letztendlich schädliche übertriebene Ablehnung von Meetings jeglicher Art im Wesentlichen auf fehlgeleitete Gruppendynamiken zurückgeht, dann können wir selbst dafür sorgen, dass sich diese Dynamiken umdrehen. Das Einzige was wird dafür tun müssen ist, positiv über Meetings zu reden, selbst wenn uns das aus den genannten Gründen zu Beginn schwerfällt.

Das heisst natürlich nicht, dass die zweifellos in vielen Meetings vorhandenen Missstände beschönigt oder verschwiegen werden sollen. Es heisst aber, dass durch ein Gegenüberstellen der unzweifelhaft ebenfalls vorhandenen sinnvollen Effekte ein differenziertes Bild entsteht, und dass es auch den anderen Gruppenmitgliedern ermöglicht wird, dieses differenzierte Bild zu haben oder zurückzugewinnen. In diesem Sinne: Make Meetings great again!

Cost of Delay (III)

Nochmal zum Thema Cost of Delay, also zu den Verzögerungskosten, die auftreten, wenn ein Produkt oder Feature zu langsam fertig wird. Diese Kosten werden gemessen in (ungefähren) Geldbeträgen, die verpassten oder verzögerten Gewinnen entsprechen. Auf den ersten Blick erscheint das Zwangsläufig und nicht weiter erwähnenswert, bei näherer Betrachtung ist darin aber eine eigentlich offensichtliche Implikationen enthalten, die aber manchmal vergessen wird.

Um Verspätungskosten finanziell messen oder schätzen zu können, ist etwas ganz Grundlegendes nötig: ein Business Case des Produkts oder Features nämlich, für das diese Kosten ermittelt werden sollen. Das ist in vielen Fällen auch gut möglich, etwa bei neuen Autos oder Computerspielen, bei neuen Funktionen komplexer und abstrakter Produkten wie z.B. Betriebssystemen oder Online-Portalen ist es dagegen deutlich schwieriger und ggf. sogar unmöglich.

Noch am Einfachsten ist es in Fällen, in denen diese Funktionen kostenpflichtig gekauft oder abonniert werden können. In derartigen Konstellationen lassen sich nach Fertigstellung die Gewinne rückwirkend auf die "verpassten" Monate übertragen, oder alternativ kann bereits während der Planung von einem voraussichtlichen Gewinn ausgegangen werden, dessen drohendes Verpassen ggf. kurzfristige Mehraufwände rechtfertigen kann.

Schwieriger wird es, wenn neu erstellte Features nicht separat monetarisierbar sind. Ein Umweg den man hier gehen kann, ist der über die Marktforschung: wenn eine Neuerung ein Differenzierungsmerkmal ist (oder ein Differenzierungsmerkmal eines Wettbewerbers egalisiert) kann man annehmen, dass Umsätze (und damit Gewinne) ganz oder teilweise auf sie zurückzuführen sind, was sich dann annäherungsweise in Geld quantifizieren lässt.

Praktisch unmöglich wird die Ermittlung von Cost of Delay, wenn die jeweilige Funktionalität weder separat vermarktet wird, noch von Kunden als Differenzierungsmerkmal wahrgenommen wird (oder überhaupt separat wahrgenommen wird). Ein internes Diagnose-Programm wäre ein Beispiel dafür. Natürlich ist es aus Produktsicht sinnvoll und mehrwertstiftend, es ist aber nichts, das man einem Kunden in Rechnung stellen oder ihm gegenüber vermarkten könnte.

Für derartige Funktionen ist eine separate Ermittlung von Verspätungskosten schlicht nicht machbar, was eigentlich auch kein Problem ist - schliesslich müssen sie nicht zwanghaft für jedes Feature gemessen werden. Entweder fallen sie ganz aus derartigen Betrachtungen heraus, oder sie entsprechen der kompletten Verspätungskostensumme des Gesamtprodukts - dann nämlich, wenn dieses ohne die einzelne Funktion nicht verkauft werden kann oder darf.

Der Vollständigkeit halber: Wird in überregulierten Umgebungen versucht, eine kategorische Anwendung dort zu erzwingen, wo das eigentlich nicht geht, ist meistens Cargo Cult die Folge. Dann kann es z.B. sein, dass für Funktionen ohne Business Case einer "nach Bauchgefühl" ermittelt wird, z.B. mit Planning Poker. Diesen Wert kann man dann in die Dokumentation schreiben um den Vorganben gerecht zu werden, es ist aber nicht mehr als Business-Theater, das man auch sein lassen kann.

Modular Monoliths and Other Facepalms

 Eines der folgenschwersten Missverständnisse der Softwareentwicklung ist, dass die Rolle des Architekten eine rein technische ist. Ich glaube, dass es sich um eine zutiefst soziale Rolle handelt, eine bei der man sowohl in der Lage sein muss, komplexe Inhalte an Andere zu vermitteln, als auch zu extrahieren, was Andere meinen, wenn sie bestimmte Schlagworte benutzen. Kevlin Henney gelingt hier beides gleichzeitig.

Was er ausserdem dankenswerterweise herausstreicht ist, dass diese Rolle Geduld und Nachsicht erfordert. Sein André Gide-Zitat bringt es auf den Punkt: "Alles wurde bereits gesagt, aber da niemand zuhört müssen wir es ständig wiederholen." Ein Architekt der dazu nicht bereit ist, wird es schwer haben seinen Job gut auszuüben. Im übrigen eine bemerkenswerte Parallele zu allen Methodiker-Berufen.

Soziotechnische Systeme

Ein kurzer Ausflug auf die Meta-Ebene. Sowohl die Entwicklung von Software als auch die Fertigung von Hardware-Produkten finden im Überschneidungsbereich von zwei Systemen statt: einem sozialen System, bestehend aus den beteiligten Menschen und den zwischen ihnen stattfindenden Interaktionen und einem technischen System, bestehend aus verschiedenen miteinander verbundenen Geräten und IT-Programmen. Beide zusammen bilden dann so genannte Soziotechnische Systeme.

Das soziale (Teil-)System bilden im engeren Sinn alle an der Produkterzeugung beteiligten Menschen, egal ob sie planen, konzipieren, programmieren, montieren, testen, dokumentieren, absichern oder sonstige Tätigkeiten durchführen. Im weiteren Sinn können noch weitere Gruppen dazugehören, etwa Anwender, Auftraggeber oder Regulierer. In beiden Fällen bestehen diese Systeme aber nicht nur aus den beteiligten Menschen, sondern auch aus den sie verbindenden Interaktionen (z.B. der Kommunikation).

Das technische (Teil-)System hat ebenfall zwei Dimensionen: zunächst umfasst es alle Werkzeuge, die von den Angehörigen der sozialen Systeme benutzt werden; im Fall der Software-Programmierung etwa Computer und Build Pipelines, im Fall der Hardware-Fertigung können es Fliessbänder und Stanz-Maschinen sein. Als zweite Dimension kommen Elemente dazu, die die beteiligten Menschen steuern und anleiten, z.B. Ticket-Tools oder akkustische Signale, die auf durchzuführende Tätigkeiten hinweisen.

Aufbauend darauf kann man diskutieren, ob in letzter Konsequenz nicht alle Arbeit in soziotechnischen Systemen stattfindet (selbst in der Manufaktur gibt es Werkzeuge und selbst einen Vollautomaten muss irgendjemand anschalten), es gibt aber Vorgehensweisen, die zwingend soziotechnisch sind - die, bei denen es um hohe Reaktions- oder Liefer-Geschwindigkeit geht (Agile und Lean), wären ohne Automatisierung einfacher Arbeiten und menschliche Eingriffe bei Technikversagen schlicht zu langsam.

Und um auch das noch stärker herauszustreichen: hohe Reaktions- oder Liefer-Geschwindigkeit kann in vielen Fällen bedeuten, dass die Abläufe im Wortsinn rasend schnell werden, etwa dann, wenn in einer Lean-optimierten Fabrik pro Minute hunderte von Nägeln oder Bleistiften erzeugt werden oder neue Software in Sekunden auf tausende Geräte geladen wird. Es kann aber auch bedeuten, dass die Anfertigung einzelner Prototypen "nur noch" Wochen dauert, statt Jahre (siehe hier).

Zu guter Letzt: wenn man sich darauf einlässt, dass nach Agile, Lean oder verwandten Ansätzen arbeitende Organisationen soziotechnische Systeme sind, erledigen sich auch auch schnell die Diskussionen, ob sie aufgrund des technischen Fortschritts nicht obsolet werden. Agiles Arbeiten kann genauso wenig durch Künstliche Intelligenz abgelöst werden wie Lean durch 3D-Druck, denn das sind lediglich technische (Teil-)Systeme. Was dagegen möglich ist, ist diese in Agile und Lean zu integrieren.

Kommentierte Links (CXXXVII)

Bild: Pexels / Ekam Juneja - 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.

Jim Highsmith: The Agile Manifesto at 25

In diesem Monat ist das Manifest für agile Softwareentwicklung fünfundzwanzig Jahre alt geworden, und unter den vielen Menschen, die darüber geschrieben haben, möchte ich Jim Highsmith hervorheben, der es auf den Punkt gebracht hat: die agile Bewegung hat seitdem gleichzeitig gewonnen und verloren. Gewonnen, weil viele ihrer Ideen zu Standards geworden sind, verloren, weil viele ihrer Praktiken zu sinnentleerten Ritualen erstarrt sind. Beides ist wahr.

Jeff Gothelf: Technical systems will continue to succumb to culture

Dass die Begeisterung für neue Tools den Blick für Realitäten vernebeln kann, ist ein Phänomen das es schon vor der KI-Welle gegeben hat, das jetzt aber noch einmal verstärkt wurde. Jeff Gothelf bringt es auf den Punkt - Tems die bisher bei der Arbeit nur das absolut nötige Minimum geleistet haben, werden durch KI nicht produktiver - aber sie erreichen dieses absolut nötige Minimum jetzt mit noch weniger Anstrengung. Das Ergebnis bleibt gleich.

Braden Kelley: Three Myths That Kill Change and Transformation

Um ein bekanntes Sprichwort zu paraphrasieren: die bekannten Regelmässigkeiten, denen das Change Management unterliegt, sind einfach, schnell zu verstehen - und falsch. Braden Kelley nennt drei dieser scheinbar naheliegenden aber meistens falschen Faustregeln. 1. Wenn Menschen verstehen, warum Änderungen angestossen werden, werden sie sie mittragen; 2. Skeptische Minderheiten sollten so lange bearbeitet werden, bis sie überzeugt sind; 3. Erste kleine Erfolge ziehen automatisch grössere nach sich. Klingt alles wünschenswert, ist aber in der Realität meistens falsch.

Liam Kane: When Work Ages - Block It or Remove It from WIP?

Ein sehr praktisches Problem, vor dem viele nach Kanban arbeitende Teams regelmässig stehen: wie visualisiert man Arbeit, an der es gerade aus irgendeinem Grund nicht weitergeht? Die Antwort ist natürlich "Es kommt darauf an", da das aber zu generisch ist, formuliert Liam Kane das Ganze weiter auf und zeigt anhand einiger Wenn-Dann-Bedingungen, welche Arten von Blockaden welche Arten von Visualisierung nach sich ziehen können.

Lorin Hochstein: Poor Deming never stood a chance

Manchmal hilft Vereinfachung bei der Kommunikation von komplexen Sachverhalten. Dieser Text von Lorin Hochstein ist so ein Fall, denn er komprimiert die jüngere Management-Geschichte auf den Gegensatz der Lehren von Peter Drucker und W. Edwards Deming. Lässt man sich darauf ein, wird man auf einen ähnlichen Schluss kommen - die Ideen von Drucker haben gewonnen, zumindest in der westlichen Welt. Ob das gut oder schlecht ist, kann jeder für sich bewerten.

Pseudo-Wissenschaft im Projektmanagement

Viel zu häufig werden in Projektmanagement und Organisationsdesign Entscheidungen aufgrund von Bauchgefühl, anekdotischer Evidenz oder unvalidierten Annahmen getroffen. Die Gegenbewegung dazu ist das evidenz- oder empiriebasierte Arbeiten, das entweder auf selbst erhobenen Zahlen oder auf wissenschaftlichen Erkenntnissen beruht. Besonders das Zweite kann aber erneut zu einem Problem werden, denn nicht Alles, was auf den ersten Blick wissenschaftlich erscheint, ist es auch.

Die offensichtlichste Form derartiger unwissenschaftlicher Annahmen sind solche, die oft mit Aussagen wie "es ist allgemein bekannt" begründet werden, bei denen es sich aber eher um Truthinesses handelt, also um Aussagen von eher geringer Richtigkeit, die man aber als so naheliegend empfindet, dass man es für unnötig hält, sie zu überprüfen. "Bei großen und komplexen Aufgaben muss man mehr und detaillierter planen, damit alles funktioniert" wäre ein Beispiel dafür.

Wesentlich schwerer zu erkennen sind Behauptungen, die zwar auf echten wissenschaftlichen Erkenntnissen beruhen, diese aber aus ihrem ursprünglichen Kontext herausreissen, sinnentstellend zitieren oder selektiv verkürzen. Eine flüchtige Recherche kann in solchen Fällen den Eindruck einer soliden wissenschaftlichen Fundierung hervorbringen, ein genaueres Betrachten der Quellen findet nur selten statt. Hier sind einige der häufigsten derartigen Fälle

Der Ringelmann-Effekt

Der Ringelmann-Effekt unterstellt, dass Mitglieder einer Gruppe an gemeinsamen Aufgaben nicht mit ganzer Kraft mitarbeiten, und so versuchen, Arbeit auf ihre Kollegen abzuwälzen (was häufig als Rechtfertigung für Arbeits- und Leistungskontrollen dient). Seinen Ursprung hatte er 1913 in der Forschung zu körperlicher Arbeit in der Landwirtschaft und "bewiesen" wurde er in Tauzieh-Wettbewerben. Eine Übertragbarkeit auf die moderne Arbeitswelt ist hochgradig fraglich.

Die Sieben als ideale Teamgrösse

Die häufig zu hörende Aussage, dass die ideale Grösse eines Teams Sieben Mitglieder wäre, wird meistens mit der Psychologie-Studie The Magical Number Seven, Plus or Minus Two von 1956 belegt. Macht man sich die Mühe diese zu lesen, findet man aber heraus, dass es in ihr um etwas völlig anderes geht - um die Anzahl der Informationsquellen nämlich, deren Input ein Mensch gleichzeitig verarbeiten kann. Daraus eine Teamgrösse abzuleiten ist gewagt (Mensch ≠ Informationsquelle).

Die Dunbar-Zahl

Wenn man so will ist die Dunbar-Zahl die grössere Variante der magischen Sieben, es ist die maximale Anzahl an Menschen, mit denen man soziale Beziehungen unterhalten können soll. Auch hier ist der Ursprung bemerkenswert: es ist die Forschung aus den 90ern an Affen, Naturvölkern und vorindustriellen Gesellschaften, welche die in den letzten 200 Jahren erzielten technischen und sozialen Optimierungen zwischenmenschlicher Kommunikation und Zusammenarbeit weitgehend ausblendet.

Die Tuckman-Phasen

Auch als das Forming–Storming–Norming–Performing-Modell bekannt, geht das Tuckman-Entwicklungsmodell von 1965 davon aus, dass Teams nacheinander die vier genannten Phasen durchlaufen. Der wissenschaftliche Unterbau ist dünn, da es sich nur um eine Meta-Studie von Arbeiten aus verschiedenen, nur schwer miteinander vergleichbaren Fachgebieten handelt. Und: in einer Folge-Studie von 2007 durchliefen nur zwei Prozent (!) von 321 Teams die Tuckman-Phasen.

Man könnte die Liste noch länger machen, bereits jetzt dürfte aber klar sein, wie wenig viele der scheinbar gesichert wissenschaftlichen Erkenntnisse auf die moderne Arbeitswelt übertragbar sind. Bereits durch ein einfaches Querlesen der Originalquellen wird schnell klar, dass deren Forschungs-Gegenstand ein völlig anderer war und er kaum Rückschlüsse auf in Projektmanagement und Organisationsdesign zu beachtende Regelmässigkeiten zulässt.

Das soll übrigens nicht heissen, dass evidenz- oder empiriebasiertes Arbeiten eine schlechte Idee wäre, ganz im Gegenteil. Es heisst aber, dass man die "wissenschaftlichen Erkenntnisse", auf die man sich beruft, zumindest bis zu einem gewissen Grad verstanden haben sollte. Wenn das nicht der Fall ist, ist der Übergang zur Truthiness fliessend.

Ein Bild sagt mehr als 1000 Worte (LV)

Moderne Hofnarren

Schon seit langem gibt es in den menschlichen Gesellschaften Bemühungen, in großen Organisationen Positionen zu schaffen, die (bis zu einem gewissen Grad) von Anstand und Hierarchie befreit sind, um unangenehme Wahrheiten aussprechen zu können. In der Antike war es der Diener, der den siegreichen römischen Kaiser an seine Sterblichkeit erinnerte, im Mittelalter waren es die Hofnarren und später die Kabarettisten, die herrschende Personen und vorherrschende Ideen ungestraft angreifen durften.

Die Grundidee hinter diesen Traditionen war, dass die für die unangenehmen Wahrheiten zuständige Person gleich doppelt frei von Bedenken sein konnte: zum einen war sie durch ihre Narren-Stellung von zukünftigen Führungspositionen ausgeschlossen, und musste sich daher keine Sorgen darum machen, durch zu grosse Offenheit ihre Karriere zu gefährden. Zum anderen war sie durch die sprichwörtliche Narrenfreiheit vor Sanktionen durch die von ihr blossgestellten Mächtigen geschützt.

Auch in der Welt der moderenen Wirtschaft gibt es immer wieder Bemühungen, vergleichbare Rollen zu schaffen, die den Finger in die Wunde legen und ungestraft Group Think, Hierarchiegläubigkeit, Methodismus und unrealistischen Planungsoptimismus beim Namen nennen dürfen. Der amerikanische Ökonom Russell Ackoff prägte dafür in einem 1993 erschienenen Artikel den Begriff des "Corporate Jester", ungefähr übersetzbar mit dem "Unternehmens-Hofnarren".

Derartige Positionen hat es tatsächlich immer wieder gegeben (am vermutlich bekanntesten in Person von Paul Birch, dessen Position bei British Airways tatsächlich den Namen Corporate Jester trug), und auch im Rahmen der agilen Frameworks ist sie immer wieder als anzustrebende Positionierung genannt worden. Gerade für die Rollen des Scrum Masters und des Agile Coaches, denen so die Möglichkeit gegeben werden soll, Missstände in der Organisation zu thematisieren, ohne sich selbst zu beschädigen.

Dieser Ansatz kann auch tatsächlich funktionieren, ich habe in verschiedenen Unternehmen Menschen kennengelernt, die in der modernen Hofnarren-Rolle ihre Erfüllung gefunden haben, in ihr aufgegangen sind und für sie geschätzt wurden - bis hin zu dem Punkt, dass sie bewusst in Entscheidungsrunden eingeladen wurden, um dort durch das Infragestellen scheinbarer Gewissheiten die Diskussionen offener und kritischer zu gestalten.

Was aber auch klar sein muss: diese Positionierung kommt häufig mit einem Preis. Genau wie im Mittelalter werden auch vielen modernen Hofnarren ihre schmerzhaften Wahrheiten vor allem dann verziehen, wenn sie aus einer Position der tatsächlichen Machtlosigkeit heraus erfolgen. und nicht selten wird dafür gesorgt, dass sie in dieser auch verbleiben müssen - nicht einmal zwangsläufig aus Rache, oft einfach dadurch, dass für diese Rollen keine weiteren Aufstiegsmöglichkeiten vorgesehen sind.

Eine Möglichkeit um diesem Dilemma zu entgehen, ist der gezielte Einsatz in bestimmten Kontexten (gewissermassen als "situativer Corporate Jester"), während das Auftreten in anderen Zusammenhängen zurückhaltender und seriöser ist. In gewisser Weise ist man dann eher der Karnevalist als der Hofnarr - zu bestimmten Zeiten respektlos und rebellisch, im restlichen (Berufs-)Leben eine respektierte Stütze der Gesellschaft. Funktioniert besonders gut im Rheinland, aber nicht nur dort.

Die agile Schleife

Die ikonische Schleife, die fast durchgehend zur Visualisierung der verschiedenen agilen Vorgehensmodelle genutzt wird, ist immer wieder zum Gegenstand von Spott und Kritik geworden. Dadurch, dass sie sich nach kurzer Aufwärtsbewegung nach hinten wölbt, kommt man am Ende wieder da an, wo man gestartet ist. Für viele Kritiker ist das auch die tragische aber treffende Beschreibung der agilen Bewegung, 25 Jahre nachdem sie im Februar 2001 auf einer Skihütte gestartet wurde.

Tatsächlich sind Projektmanagement und Softwareentwicklung in vieler Hinsicht wieder dort angekommen, wo sie damals bereits waren: schwergewichtige, bürokratische Prozessvorgaben werden an der Spitze grosser Organisationen definiert und den auf Effizienz statt auf Effektivität getrimmten Einheiten übergestülpt, Abhängigkeiten werden gemanaged statt aufgelöst und innerhalb der so gebildeten Prozess-Schicht bestehen prozesszentrierte, von der eigentlichen Arbeit entkoppelte Berufe.

Die Pointe: all das geschieht mittlerweile unter dem Label "Agile", also ausgerechnet jener Begrifflichkeit, die ursprünglich als Gegenwurf zu all dem gerade Gesagten entwickelt wurde. Die schwergewichtigen Prozessvorgabwn sind die Skalierungsframeworks, innerhalb derer die Effizienz der Teams an der Velocity ihres Outputs gemessen wird, koordiniert von einer Prozessschicht aus (Proxy-) Product Ownern, Scrum Mastern, Agile Coaches, Solution Managern und Release Train Engineers.

War also alles umsonst? Nicht unbedingt. Der Spott über die im Rahmen ihrer Schleifenform stehts zum Ausgangspunkt zurückkehrenden agilen Iterationen übersieht nämlich etwas Zentrales: jede einzelne Wiederholung führt zu Lerneffekten, und jeder neue Durchlauf ist dadurch anders (und oft besser) als die davor - was auch bedeuten kann, dass man dafür zurück auf Los gehen muss. Das gilt in der digitalen Produktentwicklung, es gilt aber genauso in der Weiterentwicklung der agilen Vorgehensmodelle selbst.

In dem Vierteljahrhundert seit der Erfindung des Begriffs der Agilität in den schneebedeckten Bergen haben zahlreiche derartige Lernschleifen stattgefunden. Reine Teamzentrierung führt zu Machtlosigkeit, zu grosse Management-Nähe dagegen zu Entkoppelung von der Praxis. Zu grosse Technik-Nähe führt zurück in organisatorische Silos, ein zu grosser Abstand zur Technik dagegen zu Meeting-Theater und Machbarkeitsphantasien. Jede dieser Schleifen hat geschmerzt, jede war wertvoll.

Denn auch das gehört zum Gesamtbild - vorgegebene Prozesse, Effizienzfixierung und umfangreiches Abhängigkeitsmanagement sind zwar wieder (oder immer noch) da, aber sie werden anders gesehen: nicht mehr als zwangsläufig richtig, sondern als notwendiges Übel, das es immer wieder zurückzuschneiden gilt. Und bei aller Problematik, die in der Aussage steckt, dass der Scrum Master sich selbst überflüssig machen soll - diese Sicht ist ein Paradigmenwechsel.

Und sogar sich selbst stellt die agile Bewegung in Frage. Der sich gerade vollziehende Abschied von Zertifizierungs-Kommerzialisierung, formalisierten Meeting-Ritualen und sich jeglicher Verantwortung verweigernden Methoden-Coaches mag sich oberflächlich betrachtet wie die Trennung von einem gescheiterten methodischen Ansatz anfühlen, man kann ihn aber auch als Teil des agilen Lernschleifen-Durchlaufs sehen. Wir haben dazugelernt, trennen uns von Fehlentwicklungen und starten neu.

Natürlich wird auch das wieder mit Skepsis und Ablehnung begleitet werden, mit Appellen, doch stattdessen auf "bewährte" Methoden zu setzen und mit dem Verweis darauf, dass dezentrale Selbstorganisation angeblich noch nie funktioniert hätte, was mittlerweile ja bewiesen wäre. Mit anderen Worten: die agile Bewegung ist zurück in der Rolle des Underdogs, dem man die Wirksamkeit seiner Ideen erst glaubt, wenn es sie beweisen kann. Sollte uns das Sorgen machen?

Ganz im Gegenteil: eine idealere Startbedingung für ihre nächste Iteration, die basierend auf evidenzgetriebenem Lernen besser sein kann als die davor, gibt es nicht. 

Ziv’s Law

Die meisten "Gesetze" der Softwareentwicklung oder des Projektmanagement gehen auf Zitate ihrer Urheber zurück (Conway's Law, Hofstadter's Law, Brooks's Law, etc.) und spiegeln daher deren Auffassungen wieder. Ziv's Law, benannt nach Hadar Ziv, Professor der University of California, ist in dieser Hinsicht ein Sonderfall, da es seine ursprünglichen Aussagen verfremdend verkürzt. Bevor wir auf seine eigentliche Form schauen, ist aber hier zunächst die verkürzte:

Software specifications and requirements will never be fully understood

frei nach Hadar Ziv, ca. 1996

Zurückgeführt wird Ziv's Law auf seine im Jahr 1996 zusammen mit Debra J. Richardson veröffentlichte Studie The Uncertainty Principle in Software Engineering. Diese beschäftigte sich trotz ihres Namens allerdings nicht mit der Softwareentwicklung im Allgemeinen, sondern nur mit einem ihrer Teilgebiete: dem Software-Testen. Und in diesem Kontext sollte die Aussage der niemals vollständig verstehbaren Anforderungen und Spezifikationen auch gesehen werden.

Ziv und Richardson legten in ihrer Studie dar, dass sämtliche Anforderungen, und damit auch sämtliche Versuche, durch Tests sicherzustellen, dass sie korrekt umgesetzt wurden, Unsicherheits-fördernden Faktoren unterliegen: die Problembeschreibung muss Umgebungsfaktoren ausblenden um nicht zu ausufernd zu werden, die Lösungsbeschreibung kann nur bekannte mögliche Implikationen enthalten und keine noch unbekannten, und ihre menschlichen Verfasser sind fehlbar und können sich irren.

Bedingt durch diese Faktoren sind praktisch sämtliche Versuche, eine zu erstellende Software zu beschreiben, unvollständig, weshalb sowohl in Bezug auf die Umsetzung als auch in Bezug auf den Test unklar sein muss, ob die zugrunde liegenden Anforderungen wirklich im Sinne ihrer Verfasser verstanden wurden. Diese Unklarheit und ihre Folgen werden bereits auf einer der ersten Seiten von The Uncertainty Principle in Software Engineering adressiert:

Software systems under test include, among others, requirements specications, design representations, source code modules, and the relationships among them. These software artifacts are produced by requirements analysis, architectural design, and coding processes, respectively. Following UPSE [the Uncertainty Principles in Software Engineering], uncertainty permeates those development processes and, consequently, the resulting software artifacts. Plans to test them, therefore, will carry these uncertainties forward

Ziv & Richardson, The Uncertainty Principle in Software Engineering , S.4

Diese Darlegungen wird jeder, der sich schon einmal mit Softwareentwicklung beschäftigt hat, bestätigen können. Ihre grosse Schwäche ist aber, dass sie relativ langatmig und kompliziert formuliert wurden, so dass man sie sich kaum merken kann. Der Versuch, sie auf eine gut zu behaltende Zeile zu verkürzen, ist nachvollziehbar, allerdings kam diese Prägnanz mit einem Preis - der ursprüngliche Bezug zum Software-Test ging verloren, genau wie der Verweis zu den erforschten Unsicherheits-Faktoren.

Die verfälschend verkürzte Version von Ziv's Gesetz, die nur noch besagt, dass Anforderungen und Spezifikationen nie zur Gänze verstanden werden, ist übrigens nicht zwingend unzutreffend. Praxis-Beobachtungen sprechen sogar dafür. Anders als Zivs und Richardsons differenziertere Aussagen ist sie aber nicht mehr durch wissenschaftliche Forschungsergebnisse belegt. Sie ist damit lediglich eine durch anekdotische Evidenz belegte starke Meinung, dessen sollte man sich bewusst sein.

Cost of Delay (II)

Manchmal hilft bei der Vermittlung komplexer Sachverhalte ein Video ungemein, so auch in diesem Fall. Erklärt wird die Idee der Verspätungskosten, bzw. der Cost of Delay. Gut verständlich und kompakt zusammengefasst, in nur wenigen Minuten.

Cost of Delay – An Introduction from Joshua Arnold on Vimeo.

Bemerkenswert ist, dass das Video bereits mehr als ein Jahrzehnt als ist. Was seine Erstellung damals für einen Aufwand bedeutet hat mag man sich kaum vorstellen. Heute mit KI ginge es sicher in einem Bruchteil der Zeit.

Definition of Done (IV)

Bis zur Überarbeitung des Scrum Guide im Jahr 2020 enthielt er in Bezug auf die Definition of Done (DoD), sein zentrales Quality Gate, durch das alle neu erstellten Funktionalitäten passieren müssen, eine Formulierung, die zumindest aus meiner Sicht hochgradig kontrovers war. Sinngemäss stand in ihr, dass die Qualität des erzeugten Produkt oder Service sich verbessern liesse, indem der Umfang der DoD vergrössert würde. Oder im englischen Original:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Scrum Guide, 2017 Version

Nun ist dieser Passus wie gesagt seit dem Jahr 2020 Geschichte, er ist aber in vielen Teams und Organisationen noch immer im expliziten oder impliziten Verständnis von Scrum hängengeblieben. Daher lohnt sich eine nähere Betrachtung - warum kann die Idee einer "expandierenden Definition of Done" problematisch sein, und unter welchen Umständen ist es möglich, diese negativen Aspekte zu vermeiden oder sogar ins Vorteilhafte zu drehen?

Um mit dem problematischen Teil zu beginnen: eine DoD, die versucht, umfassend alle Eventualitäten zu regeln, wird zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen sind. Das ist eine Falle, in die viele Teams tappen. Vor allem in Wikis oder shared Docs mit ihrem unbegrenzten Platz kann es zu einem wuchenden Wachstum von manchmal geradezu absurdem Ausmass kommen.¹

Derartig aufgeblähte Dokumente sorgen dafür, dass die von ihnen betroffenen Teams und Projekte in einer Zwickmühle sitzen. Entweder stellen sie sicher, dass alles was dort steht befolgt und eingehalten wird, verbunden mit einem erheblichen Verwaltungs- und Dokumentationsaufwand. Oder sie riskieren, dass sie einzelne Elemente vergessen und übersehen und damit nicht einhalten (oder die Unübersichtlichkeit führt versehentlich dazu, dass einzelne Teile sich gegenseitig widersprechen).

Jetzt zum positiven Fall, bzw. zu der Frage, wie dieser aussehen kann. Die (vor allem für IT-Produkte naheliegende) Antwort - automatisiert. Genauer gesagt, die Einhaltungs-Überprüfung der DoD findet automatisiert statt. Vorgaben wie Testabdeckung, Lastfähigkeit, maximale Verschachtelungstiefe des Code, das Nichtvorhandensein von auskommentierten oder ausgetoggleten Features oder sogar korrekte Rechtschreibung lassen sich durch automatisierte Tests schnell validieren - auch in grossem Umfang.

Für Teams und Organisationen die so vorgehen wollen, ergibt sich dadurch die folgende Richtlinie: eine Definition of Done wird nur dann durch einen zunehmenden Umfang besser, wenn die enthaltenen Vorgaben zum Grossteil automatisiert validierbar sind.² Die nicht automatisiert überprüfbaren Teile können zwar ihre Berechtigung haben, um Unübersichtlichkeit und Bürokratie zu vermeiden, sollten sie aber regelmässig überprüft und ggf. verschlankt werden.

¹Ein Extremfall: ein Kunde unserer Firma hatte einmal alle gültigen Rundschreiben, Merkblätter Auslegungsentscheidungen der BaFin zu Teilen seiner DoD erklärt
²Und nicht zu vergessen: wenn diese Automatisierung mit überschaubarem Aufwand wartbar und weiter modifizierbar ist

Kommentierte Links (CXXXVI)

Bild: Pexels / Ekam Juneja - 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.

Stefan Kühl: Die Komplexitätsreduktion durch Managementmoden

Die (scheinbaren) Vorteile von Management-Moden lassen sich für Stefan Kühl einfach zusammenfassen: Jede Problemlösung bringt zwangsläufig auch „Lösungsprobleme“ mit sich, also Seitenauswirkungen, unbedachte Konsequenzen und Ähnliches. Managementmoden mit ihren häufig stark vereinfachenden Vorgehensanleitungen helfen dabei, diese „Lösungsprobleme“ auszublenden. Zumindest für eine gewisse Zeit.

Stefan Norrvall: Three Axes — Now What?

Für Stefan Norrvall scheitern Veränderungsvorhaben Richtung Agilität in grossen Organisationen deshalb, weil es gegenläufige "Achsen" gibt, die die Veränderungskräfte in unterschiedliche Richtungen lenken: nicht delegierbare zentrale Verantwortlichkeiten, externe Regulierungen und fehlende formale Legitimierungen emergenter Praktiken. Dabei ist das Scheitern nicht zwangsläufig, wird aber wahrscheinlich, wenn man diese Achsen ignoriert.

Stephanie Ockerman: Self-Managing Teams - From Compliance to Collaboration

In gewisser Weise eine Fortsetzung des letzten verlinkten Artikels. Stephanie Ockerman beschreibt hier nicht nur die notwendigen "Bausteine" für selbstorganisierte Teams, sondern auch die Hindernisse, die grosse Organisationen ihnen (z.T. unbewusst) in den Weg legen. Und in denen findet sich einiges, was man den Auswirkungen der drei oben genannten Achsen zuordnen könnte. Ein schönes Beispiel dafür, wie systemisch alles zusammenhängt.

Maarten Dalmijn: Red Vs Blue Roadmaps - Why Most Roadmaps Suck

Ein neuer Blick auf Output-orientierte und Outcome-orientierte Roadmaps. Die ersten (Output-orientiert, bzw. Rot) sind für Maarten Dalmijn das Ergebnis von Angst vor den Folgen eines möglichen Scheiterns, während die zweiten (Outcome-orientiert, bzw. Blau) Fehlentwicklungen als unvermeidbar betrachten, und ihren Focus daher nicht auf Fehlervermeidung sondern auf Fehlerbehebung legen. Wie er richtig sagt: das muss man sich bewusst trauen.

Mike Fisher: Culture Debt

Es gibt technische Schulden, es gibt organisatorische Schulden und für Mike Fisher gibt es auch kulturelle Schulden. Ähnlich wie die beiden anderen Typen werden sie bewusst aufgenommen, um zu Beginn schneller zu Ergebnissen zu kommen, vor allem durch Inkaufnahme von ruppigen Umgangsformen und von toleriertem unmoralischem Verhalten von Leistungsträgern. Und genau wie die anderen beiden Typen sind einmal aufgenommene kulturelle Schulden nur mit einem erheblichen Mehraufwand wieder zu tilgen.

Getting Buy-In And Overcoming Larman's Law

Ich sage es schon seit langem: eine der Hauptzielgruppen von Change-Vorhaben sind Manager, und im Sinn eines zielgruppenorientierten Vorgehens sollte man daher seine Botschaft so verfassen können, dass sie für Manager Sinn ergibt. Alan Holub hat da einige schöne Ideen.

Eine gewisse Ironie der Geschichte ist übrigens, dass Holub plötzlich aus einem unerwarteten Grund zusätzlich Management-kompatibel ist: durch seine Ablehnung des Begriffs "Agile". Die Gründe dafür sind unterschiedliche (bei ihm die mit der Zeit stattgefundene Kommerzialisierug und Formalisierung der agilen Frameworks, bei vielen Managern die enttäuschte Hoffnung auf ein Wundermittel), in der grundsätzlichen Abwehrhaltung kommen sie aber zusammen.

Was Führungsrollen (un)attraktiv macht

Bild: Unsplash / Vitaly Gariev - Lizenz

Eine der interessanteren Studien der letzten Zeit trägt den schönen Namen Führungsetage leer?¹ und kommt vom Kompetenzzentrum Fachkräftesicherung des Instituts der deutschen Wirtschaft. Ihr zufolge sind in deutschen Unternehmen fast 30.000 Führungskräfte-Positionen unbesetzt, gleichzeitig können sich aber nur wenige Nicht-Führungskräfte vorstellen, dorthin nachzurücken - nur 14 Prozent aller Angestellten wären ohne Vorbehalte bereit. Wir laufen damit in eine Art von Führungsproblem hinein.

Auch die Gründe dafür hat die Studie unter 5000 Teilnehmern abgefragt. Es sind hohe Arbeitsbelastung, zu grosse Verantwortung, zu grosse Einschnitte ins Privatleben, zu geringe finanzielle Anreize, der Kontaktverlust zur eigentlichen Arbeit (bzw. den dort arbeitenden Kollegen) und eine zu geringe Unterstützung von mittleren Führungspositionen durch das Topmanagement. Das sagt viel aus über die befragten Menschen, aber noch mehr über ihre Unternehmen.

Als jemand der seit 15 Jahren als externer Berater in zig Unternehmen unterwegs war muss ich leider sagen, dass diese Befürchtungen in vielen Fällen berechtigt sind, da es systemische Ursachen gibt, die zu genau diesen Ergebnissen führen. Zu grosse Aufgabenteilung und die Delegation von Verantwortung ohne Gestaltungsspielraum führen zu ständigen Abstimmungen und Eskalationen, wodurch die Rollen immer politischer werden und sich immer stärker von der eigentlichen Arbeit entfremden.

In diesen Zusammenhängen liegt aber auch die Chance es besser zu machen. Durch eine auf Produkte oder Kunden (statt auf Ressouceneffizienz) ausgerichtete Organisation lässt sich der Abstimmungs- und Eskalationsaufwand reduzieren, durch ein Konnexitätsprinzig kann Verantwortung an Gestaltungsspielraum gekoppelt werden und durch beides geht der Politik- und Bürokratie-Anteil der Arbeit zurück, wodurch wieder mehr Zeit für Fachlichkeit und Technikbezug bleibt.

Das ist natürlich in der Umsetzung eine alles andere als einfache Aufgabe, und die in diesen Ansätzen enthaltenen Ideen von dezentraler Autonomie und bewusstem Verzicht auf (temporäre) finanzielle Optimierung sind genau gegenläufig zur mehrheitlich gelebten Praxis grosser Organisationen. Eine Umgestaltung in diese Richtung wird daher in vielen Fällen auf Skepsis und Widerstände stossen. Stattfinden sollten sie aber trotzdem.

Ist das nämlich nicht der Fall, drohen sich die Tendenzen aus der Studie des Kompetenzzentrum Fachkräftesicherung zu verstärken. Dann wird (oder bleibt) die Arbeit als Führungskraft so unattraktiv, dass zu wenige sie ausüben wollen. Die zwangsläufige Konsequenz ist, dass Führungspositionen gar nicht besetzt werden, oder in Ermangelung geeigneter Kandidaten durch ungeeignete Personen. Und da kann ich wieder aus eigener Beratererfahrung sprechen: beides ist etwas, das man besser vermeiden sollte.

¹Füh0le nur ich mich an Giovanni Trapattoni erinnert?

Agile Compliance (II)

Seit kurzem kann ich einen weiteren Punkt in meiner grossen, ständig nachwachsenden To Do-Liste abhaken: ich habe einen Beitrag in einem juristischen Fachbuch veröffentlicht, und zwar in Product Compliance, Herausgegeben von Chibanguza und Steege im Nomos Verlag. Damit habe ich jetzt einen zweiten Grund um mich Autor zu nennen, aber auch darüber hinaus ist das Thema eines, das für mich schon seit längerer Zeit wichtig ist.

Wie ich schon einmal geschrieben habe, wird in einem agilen Vorgehen Compliance sichergestellt, indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden. Das bedeutet zwar, dass mehr (und unterschiedlichere) Arbeit parallel stattfinden muss, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell (denn: ohne Compliance keine Auslieferung). Und die Nachdokumentations-Aufwände am Ende fallen weg.

Um sicherzustellen, dass es so kommt, kann mit zweien der klassischsten unter den agilen Praktiken gearbeitet werden: der Definition of Ready (DoR) und der Definition of Done (DoD) bezw. mit ähnlich funktionierenden aber abweichend benannten Policies, Quality Gates oder vergleichbaren Ansätzen. Unanhängig vom Namen ist dabei wichtig, dass im Voraus klar ist, wie mit Compliance-Themen umgegangen wird, und dass bei jeder einzelnen Auslieferung eine Konformität gegeben ist.

Zunächst zur im Voraus nötigen Klarheit. Die bedeutet nicht, dass schon vor Beginn der Arbeit feststehen muss, welche Normen erfüllt werden müssen. Bei einem Vorgehensmodell, das die Art der Umsetzung möglichst lange offen lässt wäre das auch schwierig. Es kann aber in der DoR im Voraus festgelegt werden, welche Vorgaben zu prüfen oder welche Experten zu konsultieren sind, um das aktuelle Increment für compliant erklären zu können (zum Increment gleich mehr).

Die Art auf die das geschieht, kann dann Teil der DoD sein. Je nach Kontext kann die Ausgestaltung unterschiedlich sein, mögliche Varianten sind aber wie oben gesagt der Abgleich mit bestehenden Regeln und Gesetzen, die Freigabe durch einen Juristen, Datenschützer, o.Ä. und wenn erforderlich die Erstellung der dazugehörigen Dokumentation. Das kann natürlich bedeuten, dass z.B. ein Jurist Teil eines Softwareentwicklungsteams werden muss - aber das ist eben Crossfunktionalität.

Um sich dabei nicht zu verzetteln ist es schliesslich wichtig, sich darüber im Klaren zu sein, welcher Arbeits- oder Funktionsumfang denn jeweils Compliance-konform sein muss. Es ist das Increment, ein Begriff mit sehr spezifischem Inhalt: zu ihm gehört nicht nur der Umfang des letzten Sprints oder Arbeitspakets, sondern ausserdem die Summe aller bereits vorher erstellten Arbeitsergebnisse. Nur als Ganzes kann ein Increment compliant sein, und nicht lediglich in Teilen.

Glue People

Wer ein bisschen Zeit in grossen Organisationen verbracht hat, dem wird früher oder später ein bemerkenswertes Phänomen aufgefallen sein - neben den offiziellen Führungs- und Koordinations-Positionen (Teamleiter, Projektmanager, etc.) gibt es auch inoffizielle Positionen, die für das Funktionieren der Zusammenarbeit mindestens genauso wichtig sind, wenn nicht sogar wichtiger. Eine dieser inoffiziellen Positionen sind die so genannten Glue People.

Hintergrund dieser Benennung ist, dass diese Menschen (deren Rolle sich im Deutschen wörtlich mit "Klebe-Personen" übersetzen lässt, sinngemäss aber eher Verbindungsperson bedeutet) dafür sorgen, dass bei Bedarf verschiedene Organisationseinheiten oder Prozessabläufe zusammengebracht und zusammengehalten werden. Wichtig ist dabei, dass das eben nicht im Rahmen der oft bürokratischen formalen Rollen und Beauftragungen erfolgt, sondern im Rahmen von Eigeninitiative.

Was für das Funktionieren einer Glue Personen-Rolle wichtig ist, ist aber nicht nur die Bereitschaft, sie einzunehmen, sondern auch das Vorhandensein eines bereits bestehenden Netzwerks in der Organisation. Erst dadurch, dass potentielle Ansprechpartner und Wissensträger (und deren Bereitschaft zur inoffiziellen Kooperation) schon bekannt sind, ist es möglich, vorbei an den offiziellen Abläufen Klärungen und Absprachen direkt vorzunehmen.

Wie dieses Netzwerk entstanden ist, kann dabei sehr unterschiedlich sein, sehr verbreitete Hintergründe sind aber eine lange Betriebszugehörigkeit, eine Versetzungsgeschichte durch verschiedene Abteilungen oder Projekte, ein Engagement in firmenübergreifenden Einrichtungen (Betriebsrat, Betriebssportverein, etc.) und dazu auf persönlicher Ebene die Fähigkeit und Bereitschaft zu Kommunikation, Informations-Weitergabe und gegenseitiger Unterstützung.

 

Ist all das gegeben, können Glue People zu einer spürbaren Erleichterung und Beschleunigung von Abläufen beitragen. Statt auf dem offiziellen Weg zuständige Personen ausfindig machen zu müssen, um dann an die Informations- oder Zusammenarbeits-Anfragen zu stellen und auf deren Beantwortung warten zu müssen, kann der notwendige Ansprechpartner direkt identifiziert und kontaktiert werden. Ggf. reduziert sich die Wartezeit dadurch von Wochen auf Stunden.

Zu beachten ist dabei aber auch, dass das Vorhandensein (und abhängig sein) von Glue People auch Probleme mit sich bringt. Durch ihre inoffizielle Natur sind sie in der Organisation häufig unsichtbar und unsteuerbar, ausserdem kann es dazu kommen, dass sie (wenn es nur wenige von ihnen gibt) Flaschenhälse oder Single Points of Failure bilden. Aus Systemsicht ist daher zwar nicht das Vorhanden sein von Glue People problematisch, aber die Abhängigkeit von ihnen.

Ein zusätzliches Thema kann sein, dass das Aufrecht-Erhalten des unternehmensweiten Netzwerks von Glue People Ressourcen kostet, allein dadurch, dass es auch ausserhalb konkreter Anlässe regelmässige Begegnungen und Austäusche erfordert, deren Dauer dann nicht mehr für die eigentliche Arbeit zur Verfügung steht (und die in Summe erstaunlich viel Zeit kosten können). Viele Firmen (wie z.B. Google) sehen Glue People daher eher kritisch und versuchen sie tendenziell unnötig zu machen.

Der Versuch, eine Organisation ganz ohne Glue People zu betreiben ist allerdings anspruchsvoll: um es zu können ist es notwendig, alle Prozess- und Zuständigkeitslücken zu schliessen, deren Vorhandensein sonst den Bedarf nach diesen Personen wieder erst entstehen lassen würde. Das wird nochmal erschwert dadurch, dass es nicht reicht, das nur einmal zu machen - in einer sich ständig ändernden Umwelt muss es vielmehr ein dauerhaftes anpassungsgetriebenes Vorgehen sein, das niemals aufhören kann.

Ein Bild sagt mehr als 1000 Worte (LIV)

Entweder ein Remix des Klassikers von Geek & Poke, oder jemand hat die gleiche tragikomische Idee nochmal gehabt. Sie ist aber auch (leider) zu naheliegend.

Continuos Coordination

Unter den vielen verschiedenen agilen Frameworks dieser Welt ist Continuous Coordination in einer Hinsicht etwas Besonderes: es ist nicht als abstraktes Konzept aus Rollen und Regeln entstanden, die man dann später versucht hat, durch prozessunterstützende Software zu formalisieren (so wie es mit Scrum und Jira passiert ist), sondern am Anfang stand eine prozessunterstützende Software (Steady), aus deren Anwendungs-Erfahrungen irgendwann ein eigenständiges methodisches Vorgehen entstanden ist.

Die Idee dahinter dürfte gewesen sein, dass eine Koordinations-Software (genau wie jedes andere Tool) auch missbräuchlich oder versehentlich falsch genutzt werden kann. Um dem entgegenzuwirken entwickelten mehrere Entwickler und Nutzer mit der Zeit ein Set von Prinzipien und Praktiken, die eine Anwendung im ursprünglichen Sinn sicherstellen sollen. Und da diese auch mit jeder anderen Software umsetzbar sind, wurde Continuous Coordination zu etwas Eigenständigem.

Bedingt durch diese Entstehungsgeschichte finden sich in diesem Framework einige Besonderheiten. Zum einen ist es (genau wie die Software aus der es entstanden ist) für asynchrone Zusammenarbeit gedacht, also für eine in der die Kommunikation in Textform die meisten Meetings ersetzt. Zum anderen besteht es vor allem aus relativ abstrakten Prinzipien, die weniger einen Anleitungs-Charakter haben und eher die zugrundeliegenden Ideen klar machen sollen. Es sind die folgenden:

01: Keep a steady beat

Im Grunde eine Abwandlung des Constant Pace aus dem Manifest für agile Software-Entwicklung. In regelmässigen Abständen (meistens täglich) schreibt jeder in gemeinsame Chat-Gruppen oder Kanäle woran er arbeitet, wo Abhängigkeiten sind, wie der Fortschritt ist, etc. Teamübergreifend sind die Frequenzen seltener, z.B. wöchentlich.

02: Lead with context

Führung in diesem Zusammenhang ist nicht nur disziplinarische Führung, es kann auch hierarchiefreie fachliche oder technische Führung sein. Wichtig ist in allen diesen Fällen, dass schriftlich explizit gemacht wird, welches Ziel, welche Abhängigkeiten und welche Rahmenbedingungen oder eine Anforderung hat. Die Umsetzung soll dann selbstorganisiert erfolgen, ohne Anleitung und Kontrolle.

03: Work in the open

Aufbauend auf dem letzten Punkt stellt sich die Frage, wie Fehler, falsche Annahmen und Ähnliches in diesem Modus entdeckt werden können. Die Antwort: durch maximale Transparenz der eigenen Arbeit. Alle Anforderungen, alle fachlichen Diskussionen, Deployments und Dokumentationen stehen allen anderen in Schriftform in Wikis, gemeinsamen Laufwerken oder Versionshistorien zur Verfügung.

04: Tell the future

Entlehnt von der Intent-based Leadership aus David Marquets Buch Turn the Ship around kann jeder durch regelmässige Absichtserklärungen transparent machen, wie und woran er als nächstes arbeiten wil. Wer Fragen, Ergänzungen oder Einwände hat kann die dann äussern und klären, und so ggf. Konflikte vermeiden bevor sie überhaupt entstehen.

05: Spare the meetings

Bevor falsche Ideen aufkommen: Continuos Coordination legt Wert darauf, dass Meetings existenziell wichtig sind, aber eben nicht alle. Während z.B. Retrospektiven, Kreativ-Sessions oder Wissenstransfer-Termine auf jeden Fall stattfinden sollten, können Dailies, Status-Meetings, Feedback-Sammlungen oder Informationsveranstaltungen auch asynchron in Schriftform stattfinden.

06: Write it down

Gemeint ist hier nicht etwa ein Ergebnis-Protokoll, sondern im Gegenteil ein im Voraus stattfindendes Aufschreiben von Zielen, Erfolgsfaktoren, Zusammenhängen und angestrebten Effekten. Das hilft zum einen bei der Strukturierung der eigenen Gedanken und hilft zum anderen bei der Erfolgsmessung. Übernommen ist es von Amazons Press Releases.

07: Track output, not input

Zuletzt ein klarer Bruch mit vielen klassischen Management-Praktiken. Statt zu messen und steuern zu wollen, wie viel Arbeitszeit und Ressourcen in eine Aufgabe hineingehen soll der Focus von Messungen das erzeugte Ergebnis sein, und das nicht etwa in Form von des Zählens von Features oder Code-Zeilen, sondern von Ergebnissen wie Kundenzufriedenheit, Nutzungsintensität oder Profitabilität.

Trotz ihrer Abstraktheit haben diese Prinzipien bei Befolgung deutlich spürbare Auswirkungen, und sorgen dafür, dass eine Organisation die sie befolgt sich deutlich von anderen unterscheidet - sowohl von agilen als auch von nicht-agilen. Kern-Element ist dabei die möglichst intensive Nutzung von asynchroner, schriftlicher Kommunikation und die Beschränkung von synchroner Kommunikation auf der Tonspur auf wenige, dafür aber zentrale Formate.

Für jeden, der sich von zu vielen Meetings von der Arbeit abgehalten sieht wird dieser Arbeitsmodus sofort attraktiv erscheinen, und er kann auch sehr gut funktionieren, er kommt aber mit einem Preis - die Arbeit wird auf diese Weise unpersönlicher, abstrakter und für viele Menschen gefühlt einsamer. Dessen sollte man sich zu Beginn bewusst sein, und man sollte in regelmässigen Abständen überprüfen ob und wie die Beteiligten damit klarkommen. 

Und zuletzt: dieser Modus benötigt einfach bedienbare, für alle zugängliche, wenig reglementierte digitale Tools. Auch die müssen erst mal da sein.

Brooks’s Law

Bild: Wikimedia Commons / David.Monniaux - CC BY-SA 3.0

Von den so genannten "Gesetzen der Softwareentwicklung" oder "Gesetzen des Projektmanagement" gibt es mittlerweile unübersehbar viele, allerdings stehen einzelne deutlich aus dieser Menge heraus. Eines davon ist Brooks's Law, benannt nach seinem Verfasser, dem amerikanischen Informatiker Frederick Brooks¹, der es 1975 im Essay The Mythical Man-Month in seinem gleich benannten Buch zum ersten mal veröffentlichte. Es lautet:

Adding manpower to a late software project makes it later / Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt sorgt für noch mehr Verspätung

Frederick Brooks, The Mythical Man-Month, S.25

Der Grund dafür, dass Brooks diese Gesetzmässigkeit verfasste war der, dass das übliche Management-Verhalten in Software-Projekten damals genau gegenläufig war.² Tatsächlich erscheint es auf den ersten Blick auch naheliegend - jede einzelne Person kann eine bestimmte Menge Arbeit pro Zeiteinheit erledigen, wenn man also weitere Personen hinzufügt könnte man davon ausgehen, dass in der selben Zeit mehr Arbeit erledigt werden kann. Aber so einfach ist es nicht.

Brooks nannte gleich mehrere Gründe, die dafür sorgen, dass statt einer Beschleunigung eine zusätzliche Verspätung auftritt. Der erste und offensichtlichste: neue Kollegen müssen zuerst eingearbeitet werden um arbeitsfähig zu sein, und das kann in der Regel niemand anderes tun als eine der Personen, die bereits länger mitarbeiten. Für die Dauer der Einarbeitungszeit kann er daher selbst nur eingeschränkt produktiv sein, die Arbeitskapazität nimmt also zunächst ab.

Selbst wenn die Einarbeitung abgeschlossen ist, gehen die verzögernden Effekte aber weiter. Wenn ein Vorhaben ursprünglich für eine geringere Umsetzungsmannschaft ausgelegt war, müssen als nächstes die Umsetzungsplanung und Aufgabenteilung überarbeitet werden, um sicherzustellen, dass synchrone und sequenzielle Abhängigkeiten berücksichtigt werden. Auch das benötigt wieder Arbeitskapazität, die dann bei der Umsetzung fehlt und diese dadurch verzögert.

Nun könnte man davon ausgehen, dass diese Verlangsamungs-Faktoren nur temporär sind. Irgendwann sind Einarbeitung und Umplanung abgeschlossen, und es kann mit erhöhter Geschwindigkeit weitergehen. Aber zum einen ist in den meisten verspäteten Projekten die dafür notwendige Zeit gar nicht gegeben, und zum anderen gibt es noch einen weiteren Faktor, der nicht temporär sondern dauerhaft sind, und der speziell mit den Abläufen der Softwareentwicklung zu tun hat.³

Wenn bei der Entwicklung einer Software neuer Code geschrieben wird, muss dieser danach in den bestehenden integriert werden. Um sicherzustellen, dass dieser danach noch immer funktioniert, sind Tests notwendig, und bei steigender Menge von Code schreibenden Entwicklern steigen auch Frequenz und Umfang der durchzuführenden Tests. Aufgrund dessen wird ein immer grösser werdender Teil der Arbeitskapazität dafür benötigt, die Tests aktuell zu halten, durchzuführen und auszuwerten.

Selbst wenn Softwareentwicklung heute etwas anders funktioniert als zu Brooks Zeit (sein Gesetz ist mittlerweile schon über 50 Jahre alt) haben sich die von ihm beschriebenen grundlegenden Zusammenhänge bis heute erhalten. Man kann daher noch immer davon ausgehen, dass das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt nicht für eine Beschleunigung sorgt, sondern für noch mehr Verspätung, und das nicht nur kurzfristig, sondern dauerhaft.

¹Daher Brooks's Law und nicht wie häufig geschrieben Brook's Law
²Was sich bis heute in weiten Teilen leider nicht geändert hat
³Brooks hat sein Gesetz auf Softwareentwicklungs-Projekte bezogen