The agile Bookshelf: Making Organizational Culture Great - Moving Beyond Popular Beliefs

Bücher zum Thema Unternehmenskultur gibt es mittlerweile unübersehbar viele, und wer einige davon gelesen hat wird gemerkt haben, dass auch die Vorstellungen davon, was Kultur eigentlich ist, ebenfalls unübersehbar vielfältig sind. Das Schöne daran: es gibt immer wieder interessante neue Sichtweisen, so wie in- dem Buch Making Organizational Culture Great - Moving Beyond Popular Beliefs, geschrieben von den amerikanischen Wirtschaftswissenschaftlern Jennifer A. Chatman and Glenn R. Carroll.

Passend zum von ihnen gewählten Untertitel ist es das Ziel der beiden Autoren, die Diskussion über Unternehmenskulturen zu versachlichen, weshalb der Aufbau um fünf populäre Annahmen kreist, die anhand realer und bekannter Beispiele validiert und in diesem Rahmen bestätig oder widerlegt werden (oder differenziert betrachtet, wenn das Ergebnis nicht eindeutig ist). Bei diesen fünf untersuchten Annahmen handelt es sich um die folgenden:

Unternehmenskultur entsteht irgendwie, existiert einfach so wie sie ist und kann nicht geändert werden

Diese Annahme ist in den Augen von Chatman und Carroll nicht völlig falsch, aber auch nicht zwangsläufig richtig. Während z.B. bei Kodak und PanAm ein Kulturwandel scheiterte war er bei Ford und Roche erfolgreich. Und bei Apple scheiterte er zunächst, um unter später unter neuer Führung (der von Steve Jobs) zu gelingen. Entscheidend ist jeweils der Kontext.

Unternehmenskultur kann verändert werden, aber nut Top-Down durch das Management

Auch hier ist die Antwort differenziert. Auf der einen Seite wird an Beispielen wie dem Southwest Airlines-CEO Herb Kelleher gezeigt, wie gross die Gestaltungsmöglichkeiten hoher Manager sein können, auf der anderen Seite wird an Firmen wie Boeing (vor der Fusion mit McDonnell Douglas) gezeigt, dass Kultur (in diesem Fall Ingenieur-Kultur) auch dezentral entstehen kann.

Unternehmenskultur ist etwas Weiches und Amorphes und kann nicht konkretisiert oder quantifiziert werden

Vermutlich das kontroverseste Kapitel des Buches. In ihm wir klar davon ausgegangen, dass Kultur konkretisierbar und messbar ist, und dass nicht nur qualitativ (etwa durch Zufriedenheits-Erhebungen) sondern auch quantitativ (etwa durch Umfang und Geschwindigkeit der Aneignung von Insider-Sprache). Praxisbelege gibt es auch hier, über deren Repräsentativität kann man aber diskutieren.

Unternehmenskultur erfordert, dass Mitarbeiter sich an sie anpassen, wenn sie Wirksamkeit entfalten oder keine Nachteile erfahren wollen

Für Chatman und Carroll ist das zu einfach gedacht. Zum einen erfordern viele Unternehmenskulturen (z.B. in innovativen Umfeldern) eine gewisse Nonkonformität, was im Widerspruch zum angepasst Sein steht, zum anderen ist Kultur oft implizit oder dynamisch, was Anpassungen erschwert. Sehr deutliche Kulturunterschiede sind aber meistens nachteilig, wie anhand von Disney und Netflix gezeigt wird.

Unternehmenskultur kann zu Mitarbeiterzufriedenheit beitragen, aber nicht zu wirtschaftlichem Unternehmenserfolg

Diese Annahme drehen die beiden Autoren zunächst um. Was eine (schlechte) Unternehmenskultur definitiv bewirken kann, ist ein wirtschaftlicher Schaden, wie sie u.a. am Beispiel Volkswagen zeigen. Darüber hinaus können eine Leistungs- oder Innovationskultur erkennbar zu wirtschaftlichem Erfolg beitragen, wofür Walmart und SpaceX als Belege genannt werden.

Nach diesen zentralen Kapiteln endet Making Organizational Culture Great mit einem weiteren, in dem konkrete Ratschläge zur Kulturgestaltung gegeben werden, auch hier wieder basierend auf vielen Praxisbeispielen. Vieles davon ist naheliegend, etwa die gezielte Personalauswahl oder Weiterbildung. Andere, wie das Verfassen von kulturellen Leitbildern oder das oben genannte Messen von Kultur sind kontrovers. Und einige, wie das Feuern kulturell unpassender Mitarbeiter, wären in Deutschland illegal.

Am Ende spiegelt sich aber in dieser Mischung, warum das Buch lesenswert ist. Es verbindet das Hinterfragen scheinbarer Gewissheiten mit konkreten Praxiserfahrungen und -anleitungen sowie kontroversen Standpunkten, an denen man sich Reiben kann. Das regt an zum Nachdenken, Hinterfragen und Ausprobieren - was passenderweise auch ein erfolgsversprechender Ansatz für die Erforschung und Gestaltung von Unternehmenskulturen ist. 

Agile Success Stories: Quartals- statt Jahresplanung

Bild: Unsplash / Chase Chappell - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich 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.

Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.

In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.

Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.

Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.

Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.

Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.

Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.

Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.

We doubled engineering productivity at eBay, but couldn't change culture

Das was Randy Shoup hier abliefert ist ein bemerkenswerter Einblick in die Welt grosser (IT-)Organisationen. Seine zentrale Botschaft, die er mit zahlreichen Beispielen aus seiner Zeit bei Ebay unterlegt: wenn ein Unternehmen eine dysfunktionale Unternehmenskultur hat, dann wird eine Modernisierung der Prozesse, Tools und IT-Systeme nur in begrenztem Ausmass zu Verbesserungen führen. Keine neue Erkenntnis, aber sehr anschaulich an einem bekannten Beispiel erklärt.

Eine zweite von ihm erzählte Geschichte, die in der oben genannten Enthalten ist, ist die der bei Ebay vorgenommenen Prozess-, Tool- und System-Modernisierungen, die trotz des letztendlichen Scheiterns an kulturellen Mustern zwischenzeitlich zu deutlichen Verbesserungen geführt haben. Shoup zufolge ist das mit einem geradezu minimalistischen Vorgehensmodell gelungen: der kontinuierlichen Identifikation von verlangsamenden Faktoren und deren sequentieller Abarbeitung durch ein die Entwicklungsteams unterstützendes Plattform-Team. Geradezu das Gegenmodell zu SAFe & Co.

Die Retrospektive als Workshop

Es gibt für Retrospektiven kein kategorisch richtiges oder für alle Situationen passendes Format, jedes Team kann seine eigene Variante entwickeln. Umgekehrt gibt es aber Verhaltensmuster, die besser zu vermeiden sind. Ein leider immer wieder anzutreffendes besteht daraus, Probleme nur zu identifizieren, für ihre Lösung aber später stattfindende Folgetermine einzurichten (oder noch schlimmer: sich lediglich vorzunehmen, derartige Termine zu planen).

Dabei ist es natürlich nicht so, dass es gar keine Konstellationen gäbe, in denen dieses Vorgehen Sinn macht. Wenn für eine Problemlösung z.B. Fachexperten oder Kooperationspartner anwesend sein müssen, die nicht zum Team gehören, dann muss man selbstverständlich vorher deren Verfügbarkeit und Bereitschaft in Erfahrung bringen. Aber bei Team-internen Themen, wie z.B. der Überarbeitung der eigenen Definition of Done, ist diese Sinnhaftigkeit nicht gegeben.

Dass trotzdem immer wieder so vorgegangen wird hat verschiedene Gründe. Ein häufiger ist der, dass auf diese Weise (scheinbar) mehr Themen erledigt werden können: nur Fünf Folgetermine zu planen geht schneller als Fünf Themen zu besprechen und zu Ergebnissen zu kommen. Auch dass das Thema für einen Teil der Anwesenden von nur wenig Interesse ist, ist ein  häufiger Grund. Und ein ebenfalls häufiger (wenn auch keineswegs Guter) ist der, dass man schon immer so vorgegangen ist.

Die Folgen dieser Vorgehensweise sind zum einen, dass die Kalender immer voller werden, und zum anderen, dass die angestrebten Lösungen und Ergebnisse immer später entstehen. Diese Phänomene stehen sogar in Beziehung zueinander. Weil für zusätzliche Meeting nicht unbegrenzt Zeit (und Lust) vorhanden sind, kann nur eine begrenzte Zahl zeitnah stattfinden. Schlimmstenfalls können sie sogar erst so weit in der Zukunft stattfinden, dass bis dahin schon die nächste Retrospektive stattgefunden hat.¹

Ein deutlich besseres Vorgehen ist es, die aufgekommenen Themen direkt in dem Termin zu behandeln, in dem sie zum ersten Mal thematisiert wurden. Um beim oben genannten Beispiel zu bleiben: wenn eine Überarbeitung der eigenen Definition of Done nötig ist, dann ist das etwas, was sofort angegangen und erledigt werden kann. Das Gleiche gilt auch für zahlreiche weitere Themen, von Coding Standards über zwischenmenschliche Unstimmigkeiten bis zur Planung des nächsten Team-Events.

Bleiben noch die gerade genannten Einwände. Einfach zu entkräften ist der Erste: mehrere Themen nur kurz anzudiskutieren und dann Folgetermine zu vereinbaren, sorgt eben nicht dafür, dass insgesamt mehr erledigt werden können. Es führt nur dazu, dass die Arbeit an mehreren parallel begonnen wird (ein wichtiger Unterschied). Nur an wenigen zu arbeiten, dafür aber richtig, lässt natürlich andere Themen unbehandelt - aber wenn sie wichtig bleiben, können sie nächstes Mal erneut eingebracht werden.

Dass bei manchen Themen nicht alle Mitglieder eines Teams nicht alle bei allen Themen in gleicher Tiefe mitreden können ist schon ein besseres Argument, aber auch kein wirklich Gutes. Zum einen bietet ein sofortiges und gemeinsames Angehen die Möglichkeit, neue Themen kennenzulernen und in ihnen besser zu werden. Und sollte der Extremfall zweier extrem unterschiedlicher Teilteams gegeben sein, lassen sich ggf. auch zwei Arbeitsgruppen bilden, von denen jede an jeweils einem Thema arbeitet.

So oder so sollten die Vorteile einer sofortigen Problembehandlung durch eine Workshop-artige Retrospektive klar sein. Schnelle Ergebnisse, kein Aufschieben der Lösungsfindung auf zukünftige Zeitpunkte, keine zusätzlichen Meetings, kein paralleles Herumwerkeln an mehreren Themen. Warum nicht alle Teams das so sehen ist mir schleierhaft, aber immerhin ist es meine Erfahrung, dass die meisten sich darauf hinweisen lassen und diesen Impuls dann auch verstehen und annehmen.

¹In der dann wortreich beklagt werden kann, dass Retrospektiven ja offensichtlich folgenlos sind.

Der Keeper-Test

Wenn die Aussenwahrnehmung eines Arbeitgebers sehr stark durch einen einzigen HR-Aspekt geprägt ist, dann muss das schon ein ganz besonderer sein. Dementsprechend sind solche Fälle zwar selten, aber es gibt sie immer wieder. Die Side Project Time bei Google ist ein bekanntes Beispiel oder die freie Vorgesetzten-Wahl bei Uber. Das vermutlich kontroverseste dieser Beispiele dürfte aber der so genannte "Keeper Test" von Netflix sein.

Besagter Test wurde in dieser Firma bereits 2001 als Praktik eingeführt, 2009 im so genannten Culture Deck offiziell gemacht und 2020 im Buch No Rules Rules einer breiteren Öffentlichkeit vorgestellt. Es gibt ihn in verschiedenen (inhaltlich gleichen) Varianten, die im besagten Buch vorgestellte ist diese hier:

If a person in your team were to quit tomorrow, would you try to change their mind? Or would you accept their resignation, perhaps with a little relief? If the latter, you should give them a severance package now, and look for a star, someone you would fight to keep.

Zu Deutsch: jeder Manager sollte sich bei jedem seiner Untergebenen fragen, ob er ihm eine Kündigung ausreden würde - und wenn nicht, dann soll er ihm eine Abfindung zahlen, damit er geht, und sich einen besseren Ersatz suchen. Das klingt zunächst einmal extrem hart und hat tatsächlich auch dazu geführt, dass Netflix in den Medien das Schaffen einer Angstkultur vorgeworfen wurde. Aber wie so oft in derartigen Fällen: ganz so einfach ist es nicht.

Zunächst muss man die wichtige Kontext-Information kennen, dass in der IT-Industrie im Allgemeinen und im Silicon Valley im Besonderen kurze Firmenzugehörigkeiten von jeweils wenige Jahren nichts Ungewöhnliches sind, bei vielen Unternehmen sind sie sogar der Normalfall. Den Menschen, die den Keeper Test nicht bestanden haben, wird also keine Job weggenommen den sie bis zur Rente behalten wollten, es fällt lediglich eine von vielen Stationen etwas kürzer aus.

Ebenfalls wichtig ist, dass die Angestellten von Netflix keineswegs in ständiger Ungewissheit über die Meinung ihrer Vorgesetzten leben müssen. Es gibt sogar ein fest definiertes Auskunftsverfahren, den so genannten "Keeper Test Prompt", mit dem man sein aktuelles Ergebnis erfragen kann. Und da dieses Ergebnis nicht nur aus den Extremwerten Bleiben und Gehen besteht, sondern auch aus vielen Zwischenstufen, hat jeder die Gelegenheit, an sich zu arbeiten um das Testergebnis wieder zu ändern.

Auch ist in der Realität auch das Scheitern an einem Keeper-Test nicht automatisch mit einer Kündigung verbunden (selbst wenn auch das natürlich oft genug vorkommt). In No Rules Rules werden auch Fälle beschrieben, in denen stattdessen eine Versetzung in andere Abteilungen stattfand, in denen die Betroffenen für sie passendere Rahmenbedingungen vorfanden. In Einzelfällen kann die Überlegung, wo der durch den Test gefallene Kollege einen Mehrwert stiften kann, sogar zu Beförderungen führen.

Zuletzt sollte man nicht aus den Augen verlieren, dass der Keeper-Test auch eine sehr positive Seite haben kann. Elizabeth Stone, der Chief Product and Technology Officer (CPTO) von Netflix, hat beispielsweise in einem Podcast erzählt, dass sie in den Personalgesprächen mit ihren Untergebenen regelmässig hervorhebt, was diese so gut machen, dass sie darum kämpfen würde, sie in jedem Fall bei sich zu behalten. Denn auch das gehört dazu: in vielen Einheiten bestehen alle den Test.

Trotz allem bleibt aber die Kernaussage aber natürlich bestehen - die Mitarbeiter, um die man nicht kämpfen würde, sollen bitte gehen. Auch das wird in No Rules Rules detaillierter erklärt: zu denen, von denen man sich trennt, gehören nicht nur die, die schlechte Arbeit leisten, sondern auch die, die sich technischen Innovationen verweigern, die strategische Entscheidungen und organisatorische Veränderungen nicht mittragen wollen, oder die einfach ständig für schlechte Stimmung sorgen.

Aber führt das am Ende nicht doch zu einer Angst- und Ellenbogen-Kultur? Nicht unbedingt. Das Buch zitiert Forschungsergebnisse der amerikanischen Business School-Professorin Erin Meyer, die folgende Zahlen ermittelt hat: Netflix kündigt jährlich im Schnitt 8% seiner Angestellten, und liegt damit nur leicht über dem Branchenschnitt von 6% - gleichzeitig liegt aber die Kündigungsrate der Mitarbeiter bei nur 4%, während diese im Branchenschnitt bei 12% liegt. Eine Angstkultur sähe anders aus.

Was hinter diesen Zahlen steckt ist die Erkenntnis, dass mit den Angestellten, die den Keeper Test nicht bestehen, nicht nur menschlich geschätzte Kollegen die Firma verlassen, sondern vor allem solche, die durch konstant schlechte Arbeitsergebnisse oder durchgehend grenzwertige Verhaltensweisen auf alle anderen demotivierend wirken. Vielleicht ist das der eigentlich kontroverse Gedanke - dass das humane Verhalten gegenüber denen, die die Erwartungen nicht erfüllen, inhuman gegenüber allen anderen ist.

Ein Bild sagt mehr als 1000 Worte (LX)

The new development cycle in one image. pic.twitter.com/18bBgKPQF2

— Kr$na (@krishdotdev) July 16, 2026

Der Vollständigkeit halber sollte man sagen: die neue Form eines schlechten Softwareentwicklungs-Zyklus. Leider trotzdem eine Häufige.

Kommentierte Links (CXXXXII)

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.

Lucas F. Costa: Lucas' Laws of Project Management

"Gesetze" des Projekt- oder Produktmanagement gibt es mittlerweile viele, aber Lucas Costa hat das ganze noch einen Schritt weiter getrieben und sogar ein kleines Gesetzbuch verfasst. Die 10 darin enthaltenen Regeln beziehen sich nicht explizit auf ein agiles Vorgehen, entsprechen ihm aber weitgehend, und das mit einer systemis Sicht, also unter Berücksichtigung nicht nur eines Projektteams, sondern auch der Unternehmens- und Marktumgebung.

Nigel Thurlow: The Toyota Production System (TPS) - What the House Actually Represents

Wer Nigel Thurlow in den sozialen Medien folgt, kennt seine (berechtigte) Beschwerde, dass ein Grossteil der Menschen, die sich auf das Toyota Production System (TPS) berufen, dieses nur aus zweiter oder dritter Hand kennen, und noch nie eine Fabrik von innen gesehen haben. Um die dadurch entstehenden Missverständnisse zu beseitigen holt er weit aus und fasst das Konzept mit allen seinen Aspekten zusammen. Wirklich lesenswert.

Chris Chinchilla: Nokia’s 14 Years of Mobile-Phone Supremacy Ended in an Afternoon

Die Geschichte des Aufstiegs und Niedergangs von Nokia ist seit einem Jahrzehnt zu einer immer wieder bemühten Metapher für die potentiell verheerenden Folgen von fehlender Innovation und Anpassungsfähigkeit geworden. Chris Chinchilla hat das Ganze in einem ausführlichen Longread zusammengefasst, der aber nicht nur aufzeigt, was damals schiefgelaufen ist, sondern mit mit einer oft übersehenen Pointe endet: Nokia hat sich danach neu erfunden und ist noch immer da - und erfolgreich.

Rahul Singal: Prefactoring - Clear the Way for Your New Feature

Die selbstorganisierte hedonistische Tretmühle

Selten in der Geschichte der organisierten Arbeit haben angestellte Menschen ein solches Ausmass an Freiheit und Mitbestimmung gehabt wie in agilen (Software-)Entwicklungsteams. Sie können selbst entscheiden wie viel Arbeit sie in nächster Zeit beginnen wollen, wie viel Beschreibungsumfang die Anforderungen haben müssen, wie sie sich die Arbeit intern aufteilen und noch Vieles mehr. Aber paradoxerweise sind viele von ihnen hochgradig unzufrieden.

Wie immer in komplexen Konstellationen gibt es nicht einen einzigen Grund, der das abschliessend erklärt, und auch keinen (Teil-)Grund der in allen Fällen vorliegt, meiner Erfahrung nach gibt es aber einen der in sehr vielen Fällen zu beobachten ist. Es ist die so genannte hedonistische Tretmühle, womit das Phänomen beschrieben wird, dass Menschen auch nach deutlichen Verbesserungen ihrer Situation mittelfristig wieder auf ihr vorheriges Zufriedenheits-Niveau zurückkehren.

Um es an einem konkreten und häufig zu beobachtenden Beispiel festzumachen: wenn einem Team nicht mehr die Aufwandsschätzungen und Umsetzungswege der Anforderungen von Aussen vorgegeben werden, führt das kurzzeitig zu Erleichterung, Aufbruchsstimmung und ähnlichen positiven Emotionen. Mittelfristig entstehen aber neue Demotivations-Ursachen, z.B. Unzufriedenheit mit der Anforderungs-Priorisierung oder der Feedback-Frequenz. Am Ende ist die schlechte Stimmung wieder da.

Die Erklärung, die in verschiedenen psychologischen Studien postuliert wurde, ist die, dass ein Grossteil der Menschen (viele, aber nicht alle) ein stabiles Niveau an Zufriedenheit und Glück hat, von dem zwar situationsbedingt Abweichungen nach unten oder oben möglich sind, zu dem aber immer wieder zurückgekehrt wird. Unwissenschaftlich formuliert: manche Menschen sind halt Miesepeter, während andere durchgehend gute Laune haben.

In der Aussenbetrachtung werden Teams, die auch bei spürbaren Verbesserungen ihrer Situation immer wieder auf ihr ursprüngliches Zufriedenheitslevel zurückfallen, in der Regel kritisch gesehen, oft mit Urteilen oder Vorwürfen wie Undankbarkeit und Destruktivität bedacht, und in Extremfällen sogar mit "Diagnosen" wie Dysphorie pathologisiert. Sich des Phänomens der hedonistischen Tretmühle bewusst zu sein, kann dabei helfen, derartigen (in der Regel vorschnellen) Annahmen nicht zu verfallen.

Eine konstruktive Möglichkeit des Umgangs mit derartigen Situationen ist es, den Teams kontinuierlich Erfolgserlebnisse zu ermöglichen, wodurch eine Gegendynamik gegen das Zurückfallen auf das ursprüngliche Zufriedenheitslevel entstehen kann. Die Schaffung derartiger Erlebnisse ist einer der Hintergründe für Sprint Reviews, Kaizen Boards und ähnliche Events und Tools, in denen Verbesserungen und Erfolge sichtbar gemacht werden.

Idealerweise geschieht das übrigens nicht mit verdeckter und manipulativer Absicht (selbst dann nicht wenn es gut gemeint ist), sondern den Teams gegenüber offen und transparent, um ihnen diesen zusätzlichen Mehrwert der jeweiligen Events und Tools bewusst zu machen. Natürlich kann das dann zu einer Ablehnung führen, aber letztendlich ist auch das Selbstorganisation: wer dauerhaft unzufrieden sein will, den kann man nicht abhalten - aber zum Glück ist das eher selten der Fall.

The agile Bookshelf: Uncertain

Der Begriff der Ungewissheit (Uncertainty) wird mit grosser Zuverlässigkeit immer wieder herangezogen wenn es zu begründen gilt, warum agile Vorgehensweisen Sinn machen. Was dabei in der Regel stattfindet ist allerdings eine Verengung dieses Begriffs - fast immer geht es lediglich um die Unsicherheit in Bezug auf die Planbarkeit von (wirtschaftlichen) Vorhaben. Dabei gibt es noch eine weitere Dimension der Ungewissheit: die psychologische.

Wer mehr darüber erfahren möchte, kann das in dem Buch Uncertain - The Wisdom and Wonder of Being Unsure tun, verfasst von der amerikanischen Wissenschafts- und Tech-Journalistin Maggie Jackson. Genau wie einige ihrer vorherigen Werke befasst es sich mit der Frage, was es mit dem menschlichen Geist macht, einer nicht enden wollenden Abfolge von technischen Innovationen, sozialen Umbrüchen und wirtschaftlichen Disruptionen ausgesetzt zu sein.

Die überraschende zentrale Botschaft ist dabei, dass Ungewissheit für die Menschen keineswegs etwas Schlechtes ist. Tatsächlich kann umgekehrt eine (scheinbare) Gewissheit ein wesentlich grösserer Risikofaktor sein, da sie zu der Annahme verleitet, Antworten und Lösungen bereits parat zu haben, so dass eine genauere Beschäftigung mit anliegenden Fragen und Problemen vernachlässigbar erscheint. Mit eher schlechten Ergebnissen als Folge.

Ungewissheit dagegen führt meistens zu genaueren Ursachen- und Einfluss-Analysen, zu einer Erwägung verschiedener Lösungsoptionen und in vielen Fällen (wenn keine von ihnen die offensichtlich Richtige zu sein scheint) zu einer parallelen Erprobung und einem Vergleich der Ergebnisse. Die dadurch gewonnenen Erkenntnisse tragen deutlich mehr zu Innovationen und Entdeckungen bei als die auf Gewissheiten begründeten schnellen Massnahmen.

Und auch auf das zwischenmenschliche Miteinander hat Ungewissheit positive Auswirkungen. Während die Überzeugung, Gewissheit über die Richtigkeit der eigenen Ansichten zu haben, zu Abwertung anderer Ansichten und damit zu gesellschaftlicher Polarisierung führen kann, führt die Ungewissheit eher dazu, dass auch andere Standpunkte als potentiell zutreffend akzeptiert werden, wodurch Konflikte seltener und Diskussionen fruchtbarer werden.

Letzteres zeigt sich auch in einem speziellen Teilbereich des zwischenmenschlichen Miteinanders - der Arbeitswelt. Maggie Jackson nennt in ihrem Buch zahlreiche Beispiele von Teams, die von der Auseinandersetzung mit Ungewissheiten stärker profitieren konnten als von den aus scheinbaren Gewissheiten abgeleiteten Best Practices, von Operations-Teams in Krankenhäusern über Bergsteiger, Wissenschaftler und Astronauten bis hin zu Gerichts-Jurys und Erziehern.

Was in diesem Buch nicht geschrieben steht, sich aber aus ihm ableiten lässt, ist deshalb ein Leitprinzip für das Change Management. Anders als oft behauptet ist es weder notwendig noch zielführend, den von Veränderungsvorhaben betroffenen Personen Ungewissheiten zu ersparen. Ganz unabhängig von der Frage ob das überhaupt möglich ist, zeigt Uncertain auf, dass Menschen Ungewissheit nicht nur ertragen, sondern sogar von ihr profitieren können.

Forward Deployed Engineering at Cursor

Zu den neuen Rollen, die in den letzten Jahren in der Softwareentwicklung entstanden sind, gehört die des so genannten Forward-deployed Engineers (FDE), eines Softwareentwicklers, der zusammen mit Mitarbeitern der Kunden seines Unternehmens in deren Systemen arbeitet, häufig auch vor Ort in deren Büros. Wie das konkret aussehen kann beschreibt Pauline Brunet hier am Beispiel der FDEs ihrer eigenen Firma Cursor.

Zu den verschiedenen interessanten Punkten ihrer Ausführungen gehören nicht nur die Aufgaben-Beschreibung, das Skill-Profil und das Persönlichkeitsprofil der Forward-deployed Engineers bei Cursor, sondern auch die Beschreibung des Kontextes in denen ihr Einsatz überhaupt Sinn macht. Denn wie so oft gilt auch hier: es ist keine Universallösung für alle Situationen, sondern nur eine für bestimmte Herausforderungen.

Ein Bild sagt mehr als 1000 Worte (LIX)

Was wäre die Welt ohne unsinnige Metriken, bzw. die missbräuchliche Verwendung von Kennzahlen? Sicher, ein besserer Ort. Aber auch einer mit weniger sarkastischen Cartoons. Es ist also nicht alles daran schlecht.

Estuarine Mapping (II)

Noch einmal zurück zum Estuarine Mapping. Dieser Prozess kategorisiert Elemente eines Veränderungsvorhabens anhand von zwei Dimensionen: der voraussichtlich zu investierenden Zeit und der voraussichtlich zu investierenden Energie (im Sinn von Stress und persönlicher Anstrengung). Je nachdem wie die Einordnung erfolgt, können die Vorhaben einfach und schnell, anstrengend und schnell, einfach und langsam oder anstrengend und langsam sein (oder etwas dazwischen).

Über diese auf den ersten Blick einfache Zuordnung hinaus gibt es aber noch weitere Kategorien, in denen eine Einordnung möglich ist: im Bereich des negativen Energieaufwands, oder anders formuliert dort, wo Veränderungen keine Energie binden, sondern freisetzen. Um sie abbilden zu können wird die Energie-Achse der Estuarine Map nach unten verlängert (sie Abbildung oben). Da das nicht intuitiv verständlich ist, eine kurze Erklärung.

In der Change Management-Praxis bedeutet Veränderung in einem Grossteil der Fälle, dass Prozesse oder Strukturen eingeführt, erweitert, modifiziert oder stabilisiert werden. Das bringt sowohl einen kurzfristigen Energieaufwand für Konzeption und Implementierung mit sich, daneben aber häufig auch einen dauerhaften Energieaufwand für die Überwachung der Einhaltung und die Sanktionierung von Abweichungen. Die häufige Folge: Change Fatigue (Veränderungs-Ermüdung).

Was seltener zu sehen, aber ebenfalls möglich ist, ist Veränderung durch das Weglassen von etwas, etwa von Vorschriften oder Berechtigungen. Ggf. kann der kurzfristige Energieaufwand für Konzeption und Implementierung auch hier auftreten, der bis zu diesem Punkt dauerhaft aufzubringende Energieaufwand für Überwachung und Sanktionierung entfällt für die weitere Zukunft aber. Diese "Nicht mehr-Bindung" von Energie lässt das Veränderungs-Element auf der Estuarine Map nach unten rutschen.

Dass im Rahmen des Estuarine Mapping überhaupt sichtbar gemacht wird, dass bestimmte Veränderungen Energie nicht etwa binden, sondern freisetzen, ist bereits für sich genommen ein Mehrwert. Alleine durch diese Visualisierung können Widerstände reduziert und Unterstützung erzeugt werden. Darüber hinaus kann diese Information auch in die Priorisierung der anstehenden Vorhaben einfliessen - mit dem zu beginnen, was Energie freisetzt, kann hochgradig sinnvoll sein.

Ein Hoch auf die Wissenschaft (II)

Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.

Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und habe irgendwann mal angefangen, einige davon vorzustellen. Hier sind die nächsten fünf, die mir erwähnenswert erscheinen (und sollte ich das noch ein drittes mal machen, wäre es eine Serie). Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine, die ich jedem empfehlen möchte, der bereit ist, sich auf wissenschaftliche Publikationen einzulassen. Hier sind sie:

Flyvbjerg, Bent; Budzier, Alexander; Christodoulou, Maria: Explaining Superscaling, China's Greatest Innovation Yet

Wer Bent Flyvbjergs Bestseller How Big Things get Done gelesen hat wird wissen, dass er Modularität als einen zentralen Erfolgsfaktor für Grossvorhaben identifiziert hat. Aufbauend auf Forschung zu derartigen Vorhaben in China formuliert und validiert er zusammen mit anderen Forschern die Theory of Modular Natives, die das weiter untermauert. Als kurze Erklärung: ein "Modular Native" ist ein immer identisches Bauteil (z.B. ein Solar Panel), das aber in verschiedenen Kontexten eingebaut werden kann.

Bernstein, Ethan S.; Turban, Stephen: The impact of the ‘open’ workspace on human collaboration

Dieses Forschungsvorhaben wäre in Europa wohl an den Datenschutzvorschriften gescheitert. Die Interaktions-Frequenz von Büroarbeitern wurde gemessen, und zwar sowohl die digitale, als auch (über Sensoren) die direkte Kommunikation. Die Ergebnisse widerlegen eine häufige Annahme: das Zusammensitzen in Grossraumbüros führt nicht zu mehr direktem Austausch unter den Mitarbeitern, sondern lässt ihn sogar deutlich zurückgehen. 

Patil, Rajeshwari; Raheja, Deepali K.; Nair, Lakshmi; Deshpande, Amruta; Mittal, Amit: The Power of Psychological Safety - Investigating its Impact on Team Learning, Team Efficacy, and Team Productivity

Dazu, dass Psychologische Sicherheit ein zentraler Faktor für die Produktivität von Team ist, gibt es bereits umfassende Forschungsergebnisse, am bekanntesten aus dem Aristotle-Projekt von Google. Eine häufige Frage dazu ist aber, ob diese Ergebnisse universal reproduzierbar sind, oder vor allem auf den europäisch/nordamerikanischen Kulturraum zutreffen (oder noch spitzer - vor allem auf dessen Tech-Industrie). Dieses Paper der Universität Pune in Indien zeigt: sie sind reproduzierbar.

Demirer, Mert; Musolff, Leon; Yang, Liyuan: Writing Code vs. Shipping Code - Productivity Effects Across Generations of AI Coding Tools

Nicht nur die emotionale Intelligenz, auch die künstliche Intelligenz ist ein Produktivitätsfaktor. Dass dabei allerdings eine massive Diskrepanz zwischen Output und Outcome entstehen kann zeigt diese Studie. Einer Steigerung der erzeugten Code-Menge um bis zu 741 % (!) steht nur eine Steigerung der Feature Releases um 20% gegenüber. Die Schluss-Pointe: ein Grossteil der neuen, schnell erzeugten Programme hatte keinen Product-Market-Fit. Es wurde mit Vollgas am Markt vorbei gebaut.

Jané, Joan; Hill, Holly Anne: Agile Manufacturing

Eines der grossen Kuriosa der agilen Bewegung ist, dass sie sich irgendwann in zwei Varianten aufgespalten hat, die kaum noch verbunden sind, Agile Produktentwicklung und Agile Manufacturing. Zwei Wissenschaftler der Universität von Navarra haben sich mit Agile Manufacturing der weniger bekannten Variante angenommen und erforscht, wie ihr aktueller Anwendungsstand in Europa ist.

AI-Driven Development Lifecycle (AI-DLC)

Einer der spannenden Nebeneffekte des Einzugs von Künstilcher Intelligenz (AI/KI) in die Softwareentwicklung ist, dass auch das methodische Vorgehen sich weiterentwickelt. Ob dabei ein weiteres Vorgehensmodell entstehen wird, das ähnliche Popularität erlangt wie Scrum und SAFe muss sich noch zeigen - es gibt aber einen ersten Kandidaten: Artificial Intelligence-Driven Software Development Lifecycle, oder abgekürzt AI-DLC.

Entwickelt wurde AI-DLC im Herbst 2025 im Developer Transformation Program von Amazon Webservices (AWS). Es wurde aber von Anfang an auch extern veröffentlicht, sowohl im AWS DevOps & Developer Productivity Blog (einschliesslich einer offiziellen Method Definition) als auch ausführlicher im privaten Blog des Programmleiters Dereck Chen (Teil I, Teil II, Teil III, Teil IV). Ein Menge Stoff also, aber wie genau sieht dieses Framework jetzt aus?

Auf den ersten Blick gibt es viele Elemente, die einen bekannten Eindruck machen. Im Mittelpunkt stehen autonome, crossfunktionale Teams aus 3 bis 6 Personen - so genannte Taxi Teams, da sie in ein einziges Taxi passen sollen (eine kleinere Variante von Amazons klassischen Two Pizza-Teams). Fest vorgegebene Rollen in diesem Teams gibt es nicht, empfohlen werden aber Product Manager, Full Stack Developers, QA Engineers und DevOps Engineers, sowie weitere bei Bedarf.

Auch der namensgebende Lifecycle ist in ähnlicher Form bereits bekannt. Es gibt die drei Phasen Inception (Anforderungen erfassen), Construction (die eigentliche Entwicklung) und Operation (Betrieb und Monitoring), die aber nicht nur einmal durchlaufen werden, sondern in sich ständig wiederholenden Iterationen. Diese werden Bolt (sinngemäss "Blitzstrahl") genannt, wodurch klar gemacht wird, dass sie kürzer sind als die klassischen Sprints (nur wenige Stunden oder Tage).

Dass derartig kleine Teams in derartig kurzen Zeiträumen funktionierende Incremente erzeugen, integrieren und betreiben können, liegt schliesslich am Einsatz einer Entwicklungs-KI. In allen drei Phasen erledigt sie den Grossteil der Arbeit, die menschlichen Teammitglieder sind als Human in the Loop nur noch für den initialen Input, die Qualitätssicherung und für Edge Cases zuständig, in denen die KI an Grenzen gerät und Hilfe braucht.

In der konkreten Umsetzung sieht das so aus, dass die KI in der Inception-Phase den Ist-Stand der Systeme, den Entstehungskontext (Architektur, Coding Standards, etc) und die grossen anstehenden Anforderungspakete, die Epics, bereits kennt. Aus einem dieser Epics wird eine mittelgrosse High-Level-Anforderung (eine so genannte Unit) definiert, aus der die KI User Stories und Akzeptanzkriterien erstellt. Die werden vom ganzen Team in einer so genannten Mob Elaboration geprüft und freigegeben.

Die freigegeben (und ggf. vorher nochmal in einer weiteren Verbesserungsschleife angepassten) User Stories werden als nächstes in der Construction-Phase durch die KI umgesetzt, was je nach Umfang unterschiedlich lange dauern kann. Sobald das abgeschlossen ist, erfolgt erneut eine Prüfung und Freigabe durch das gesamte Team, dieses mal unter dem Namen Mob Construction. Das kann nochmal in Unterphasen für Entwicklung und Test unterteilt werden (muss es aber nicht).

Die freigegebenen (und auch hier ggf. in einer weiteren Verbesserungsschleife angepassten) Incremente werden schliesslich durch die KI selbstständig auf Produktion deployt, einschliesslich der dabei durchzuführenden Tests und des anschliessenden Monitorings. Auch Bugs und Incidents werden (soweit möglich) von der KI selbstständig behoben. Der menschliche Anteil besteht hier aus der regelmässigen Kontrolle der dabei entstehenden Metriken und regelmässigen Sicherheits-Audits, Penetrationstests, o.Ä.

Soviel zur Beschreibung, jetzt zur Einordnung. Was auf den ersten Blick auffällt, sind die starken Parallelen zu Extreme Programming, sowohl in Bezug auf übernommene Elemente (iterativ-incrementelle Entwicklung, Epics, User Stories, Akzeptanzkriterien, Mob Programming) als auch in Bezug darauf, was nicht definiert wird (feste Rollen und Meetings, Backlogs, etc.). Selbst wenn es sich selbst nicht so nennt hat AI-DLC damit die Charakteristigen eines agilen Frameworks.

Auf den zweiten Blick fällt auf, dass der angestrebte intensive KI-Einsaz auf mehreren Vorbedingungen beruht. Sowohl das automatisierte Herunterbrechen der Anforderungen als auch das automatisierte Programmieren und Betreiben erfordern aktuelle Daten und Dokumentationen, klare und durchgehend eingehaltene Architektur- und Coding-Standards sowie ein nicht unwesentliches Token-Budget. AWS kann man zutrauen, das zu haben, andere Unternehmen müssten erst umfangreiche Vorarbeiten leisten.

Wenn das gegeben ist, kann man aber von einer deutlichen Beschleunigung der Entwicklungs-Geschwindigkeit ausgehen. AWS selbst nennt als Showcase sein Bedrock-Projekt, das von den ursprünglich geplanten 12 Monaten auf 11 Wochen beschleunigt wurde - mit Sechs Entwicklern, statt der ursprünglich eingeplanten 40. Derartige Dimensionen sind atemberaubend, und selbst wenn in anderen Vorhaben nur ein Teil davon erreicht würde, wäre es viel.

Entwickler-Produktivität

Für den Fall, dass es im eigenen Unternehmen gerade nicht aufregend genug ist - eine der sichersten Möglichkeiten das zu ändern ist, sich jemanden aus der IT-Abteilung (oder aus einer Abteilung, die die IT beauftragt) zu suchen und mit ihm oder ihr ein Gespräch zum Thema Entwickler-Produktivität zu beginnen. Was das ist, ob sie in ausreichendem Ausmass vorhanden ist und wie man sie messen kann. So lässt sich schnell Stimmung in die Firma bringen.

Aber Scherz beiseite, das Thema ist tatsächlich ein Klassiker. Und dass es seit Jahrzehnten in zahllosen Unternehmen immer wieder diskutiert wird, zeigt, dass bei ihm noch grundlegende Fragen ungeklärt sind - zum Beispiel, was das überhaupt ist, Entwickler-Produktivität. Eine allgemein anerkannte Definition gibt es bis heute nicht, und die existierenden Definitionsversuche haben alle ihre Schwächen. Daher zunächst ein Überblick: welche Versuche gibt es, Entwickler-Produktivität zu definieren?

I. Code-Output

Aus klassischer Management-Sicht der naheliegendste Ansatz. Wie viele Zeilen Code wurden in welcher Zeit geschrieben? Das ist einfach verständlich, gut messbar - und völlig unsinnig. Warum, habe ich hier aufgeschrieben. Eigentlich war das auch bereits allgemein anerkannt, seit dem Aufkommen von KI in der Softwareentwicklung hat die Zählung von Code-Zeilen (die auf einmal so schnell erzeugt werden können wie nie) aber ein unerwartetes und unschönes Revival erlebt.

II. Increment-Output

Schon besser als der erste Ansatz. Die Zählung von Incrementen (entwickelten, getesteten, integrierten und deployeten Features) geht mehr in Richtung der Zählung nutzbarer Funktionalitäten, und wird u.a, von McKinsey empfohlen. Schwierig dabei ist, dass es selbst in dem selben System massive Unterschiede beim Erstellungsaufwand verschiedener Incremente geben kann. Und das ist etwas, was auch über die Zeit nicht besser wird (bei Systemen mit geringer Degradability sogar eher schlechter).

III. Story Points (oder vergleichbare Werte)

Die vermutlich am weitesten verbreitete Metrik in agilen Entwicklungsteams, vor allem in Extreme Programming, Scrum und SAFe. Das Problem: wenn sie so benutzt werden wie ursprünglich gedacht, entsprechen sie keinen Zeiteinheiten und lassen sich nur rückwirkend und im langfristigen Durchschnitt auf solche umrechnen. Das Vorgeben einer festen Umrechnung in Zeit ist zwar möglich, beseitigt aber die Vorteile, wegen denen Story Points überhaupt erfunden wurden (siehe hier).

IV. Output-Flussmetriken

Die klassischen Lean-Metriken. Gemessen wird nicht mehr wie viele Arbeitspakete fertig werden, sondern wie lange die Fertigstellung im Schnitt braucht, ob von der Idee bis zum Endabnehmer (Lead Time) oder auf Teilstrecken dazwischen (Cycle Time). Je kürzer, desto besser. Wird auf Systemebene optimiert, etwa durch Abbau von Flaschenhälsen zwischen Anforderungsmanagement und Entwicklung, bessere Übergaben, etc. Daher auch eine System-Metrik, nicht nur eine auf Entwickler-Ebene. 

V. Outcome-Flussmetriken

Ähnlich wie der letzte Metriken-Typ, aber mit einem klareren Focus auf der Durchschnittszeit bis zur Erzielung eines angestrebten Geschäftswertes. Klassiker sind die Time to Market und die Feedback Loop Time, möglich sind aber auch andere, etwa die Durchführungsdauer eines A/B-Tests oder die Zeit bis zur Skalierung auf 10.000 Nutzer. Da daran neben den Entwicklern auch Produktmanagement, Marketing und andere Einheiten beteiligt sind, ebenfalls eher eine Metrik für das Gesamtsystem.

VI. Qualitäts-Metriken

Wieder eine reine Entwickler-Metrik. Kann sowohl unmittelbare Qualitätsmessungen enthalten (z.B. die Bug Rate oder Incident Rate) als auch Messungen der Qualitätssicherung (z.B. der Testabdeckung oder des Live-Monitorings). Anders als man zunächst denken könnte ein durchaus zweischneidiges Schwert, da hohe Qualitätsstandards zu unverhältnismässigen Aufwänden für die Durchführung von Experimenten oder die Erstellung von Prototypen und MVPs führen können.

VII. Betriebswirtschaftliche Metriken

Damit kann man die Augen vieler Controller zum Glänzen bringen. Return on Investment, Cost of Delay, Ressourcenaufwand pro Feature (z.B. in Form von Token-Verbrauch) oder Höhe von Betriebs- und Wartungskosten versprechen eine Steuerbarkeit anhand von Business Value, allerdings sind auch diese Zahlen sowohl stark vom jeweiligen System abhängig (siehen oben, Degradability) als auch von der Arbeit von verschiedenen Nicht-Entwicklungseinheiten wie Marketing oder Vertrieb.

VIII. Auslastungs-Metriken

Wieder ein Klassiker, aber diesesmal einer, der verheerende Auswirkungen haben kann. Jede Arbeitsstunde mit Tätigkeiten zu verplanen mag wie ein guter Weg zu hoher Produktivität erscheinen, da dadurch Leerlauf vermieden wird, allerdings reicht dann eine einzige Verzögerung aus um einen Domino-Effekt zu erzeugen, der alles nach hinten verschiebt (siehe hier). Und dazu kommen noch die Zusatzaufwände durch Umplanung, Informationsverteilung, Triage, Eskalation, etc.

IX. Kombinierte / gewichtete Metriken

Naheliegenderweise gibt es Versuche, mehrere Metriken zu verbinden oder miteinander zu verrechnen. Bekannt sind vor allem WSJF (Cost of Delay geteilt durch Durchlaufzeit) und das von McKinsey popularisierte inner Loop / outer Loop, das Entwicklungs- und Abstimmungs-Ergebnisse ins Verhältnis zueinander setzt. Das Problem daran ist, das sie leicht zu mechanistischen oder über-vereinfachten Betrachtungen komplexer Systeme führen können, die der Realität nicht mehr gerecht werden.

***

Was man an all diesen Versuchen, Entwickler-Produktivität zu messen, merken kann, ist, dass man bei ihrer Anwendung relativ schnell auf Probleme stösst. Zum Teil (v.A. bei Output- und Qualitätsmetriken) können versehentlich falsche Anreize gesetzt werden, zum Teil (bei Outcome- und Betriebswirtschafts-Metriken) lässt sich nur die Produktivität einer Gesamt-Organisation messen, nicht hingegen die von einzelnen Teilbereichen wie der Software-Entwicklung.

Bedingt dadurch führt der Wunsch, Entwickler-Produktivität zu messen meistens in einen nicht auflösbaren Konflikt. Auf der einen Seite stehen dabei Management und Controlling, die ein berechtigtes Interesse daran haben, die eigene Produktivität empirisch nachvollziehbar und auf Datenbasis optimierbar zu machen, auf der anderen Seite die Entwickler, die ebenfalls zu Recht anmerken, dass das durch die Erhebung und Auswertung von Metriken nur sehr eingeschränkt möglich ist.

Am Ende kann in genau diesem Konflikt aber auch die Lösung liegen. Wenn es gelingt, ihn sachlich, fallbezogen und lösungsorientiert auszutragen, kann das zu Produktivitätsmessungen führen, die dem jeweils einzelnen Fall eher gerecht werden als eine Einheitslösung, die in jedem Fall zwar zum Teil passend, zum Teil aber auch unpassend ist. Man hat dann nicht mehr ein zentrales Dashboard für alle IT-Teams, dafür aber das Potential für echte Verbesserungen. Und darum geht es doch eigentlich.

Kommentierte Links (CXXXXI)

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.

Sean Goedecke: Working with product managers

Eines der grossen Probleme rund um die Zusammenarbeit mit Softwareentwicklern, bzw. Softwareentwicklungs-Teams ist, dass ein Grossteil der Literatur zu diesem Thema aus einer Aussenperspektive geschrieben ist, also von Leuten, die keine Entwickler sind, sondern nur mit Entwicklern zusammenarbeiten. Sean Goedecke ist eine der bekannteren Ausnahmen, und auch hier ist ihm oein guter Blick aus der Innenperspektive der Softwareentwicklung gelungen.

Fagner Brack: Degradability

Es gibt Begriffe, deren Bedeutung sich erst erschliesst, wenn man sie einmal erklärt bekommt. Fagner Brack stellt hier einen solchen vor, die Degradability. Hinter diesem Begriff steckt vereinfacht gesagt das Ausmass des Verfalls der technischen Kompatibilität, dem eine Software alleine durch die Entwicklung neuer Tools und Standards ausgesetzt ist. Ist die Degradability einer Anwendung hoch, erzeugt sie ständig neue Arbeit, nur um weiterhin benutzbar zu bleiben. 

Jeff Gothelf: What “done” means when you’re shipping AI features

Die meisten Aussagen über die Veränderung der Softwareentwicklung durch KI focussieren sich auf ein (sehr kontroverses) Thema - die Erzeugung von mehr Quellcode in kürzerer Zeit. Nach Beiträgen zu anderen Aspekten muss man mitunter suchen, aber man findet sie. Z.B. hier bei Jeff Gothelf, der die interessante Idee aufwirft, in die Definition of Done einer Entwicklungs-KI auch Distributionen, Varianzen, Szenarien und Entscheidungsbäume einzubauen. 

Beth Smith: The Copenhagen Fallacy - complexity science and the organisations that keep changing without ever changing

Agile Indentity Politics

Eine steile These: eines der vermutlich grössten Probleme der gegenwärtigen Arbeitswelt trägt einen Namen - es ist die Identitäts-Politik (englisch Indentity Politics). Viele Schwierigkeiten auf die man in der Organisationsentwicklung, im Change Management oder in der technischen Modernisierung vorfindet, lassen sich darauf zurückführen. Wie immer bei steilen Thesen ist sie bewusst kontrovers. Um wieder sachlich zu werden folgt daher eine kurze Einführung. Was ist das überhaupt, Identitäts-Politik?

In der aktuellen Debatte versteht man darunter die (Selbst-)Zuschreibung bestimmter Ziele, Probleme oder Privilegien auf bestimmte soziale Gruppen, etwa soziale Schichten, Subkulturen, Menschen mit gleicher (ggf. von der Mehrheit abweichender) sexueller Orientierung, Angehörige von bestimmten ethnischen Gruppen, o.Ä. Diese Ziele, Probleme und Privilegien sichtbar zu machen und an ihnen zu arbeiten, um die Lage der davon betroffenen Gruppen zu verbessern, nennt man Identitäts-Politik.

Während zur Zeit im Mittelpunkt dieser Debatten eher der zweite Teil steht, also die Arbeit für die Interessen der eigenen Gruppe, ist aus einer Systemsicht der erste Teil mindestens genauso interessant, und vielleicht sogar interessanter: das feste Verknüpfen bestimmter Ziele, Programme, etc. mit einer sozialen Gruppe, bzw. deren Identität. In dem Moment in dem das passiert, wird sie nämlich fast zwangsläufig alle gegenläufigen Bemühungen auch als Angriff auf sich selbst wahrnehmen.

Um es noch einmal zu betonen - es geht  bei dieser These um die Arbeitswelt, nicht um das gesamtgesellschaftliche Problem, dass Menschen wegen ihrer Religion, Sprache, äusseren Erscheinung oder sexuellen Orientierung diskriminiert werden und sich zu Recht dagegen wehren. In der Arbeitswelt äussert sich Identitäts-Politik so, dass es zu einer (Selbst-)Zuschreibung bestimmter Arten zu arbeiten auf bestimmte Personengruppen kommt, mit der genannten Personalisierung von Konflikten als Folge.

Um das zu konkretisieren: wenn für ein Entwicklungsteam Praktiken wie Pair Programming oder gemeinsame Code Reviews konstituierende Elemente der eigenen Identität sind, dann wird es Ansätze wie AI-DLC, in denen das an eine KI ausgelagert wird, als bedrohlich für sich selbst empfinden. Und noch offensichtlicher: ein Scrum Master der seinen Job nicht als Beruf sondern als Berufung sieht, wird in eine Krise und Abwehrhaltung geraten, wenn sein Team ein anderes Arbeitsvorgehen haben möchte.

Mit derartigen Überlegungen im Hinterkopf lässt sich der häufig zu beobachtende Widerstand gegen Veränderungsinitiativen anders einordnen: sind die Menschen wirklich gegen Veränderungen (wie es dann häufig unterstellt wird), oder empfinden sie diese angestrebten Veränderungen als einen direkten Angriff auf sich selbst, ihre Überzeugungen, Werte, Prinzipien und Errungenschaften - also auf ihre Identität? Dann wären Zögerlichkeit und Widerstand viel nachvollziehbarer.

Da in einem sich stark und schnell wandelnden Arbeitsumfeld wie der IT Veränderungen nicht vermeiden lassen, muss Identitäts-Politik in diesem Kontext eine abgewandelte Bedeutung bekommen. Ihr Ziel sollte zwar noch immer sein, persönliche und soziale Identitäten in grösstmöglichem Ausmass zu schützen, gleichzeitig aber auch allen aufzuzeigen, wo das Verknüpfen der eigenen Identität mit zu spezifischen (und vergänglichen) Sachverhalten in eine berufliche Sackgasse führen kann. 

Im Idealfall baut am Ende die berufliche Identität nicht mehr (oder zumindest nicht zur Gänze) auf derartigem auf, sondern auch darauf, besser zu werden, dazuzulernen und neue Herausforderungen anzunehmen. Eine solche Identität würde nicht mehr dazu führen, dass Veränderungsinitiativen als persönliche Angriffe wahrgenommen werden können. In nahezu jeder grösseren Organisation würde das zu deutlich weniger Konfliktpotential führen.

It AI-n't What You Think!

Ein sehr lebhafter und unterhaltsamer Vortrag, den Venkat Subramaniam hier abliefert. Er versucht sich an einem neuen Blick auf das Thema AI, also Artificial Intelligence, und kommt dabei zu einem schönen Backronym: AI bedeutet für ihn Accelerate Inference, also die Beschleunigung von Schlussfolgerungen. Das ist für ihn nicht notwendigerweise etwas Schlechtes, sondern gibt nur Rahmenbedingungen für die Nutzung vor - er rät dazu, AI für die Generierung von Ideen zu nutzen, die Lösungs-Umsetzung aber selbst vorzunehmen, um nicht Kontrolle über Inhalt und Qualität zu verlieren.

Was seine Ausführung unterhaltsam macht sind neben dem Vortragsstil die zahlreichen Analogien, mit denen er seine Ideen erklärt, u.a. mit Bezügen zu Mahatma Ghandi, Franklin D. Roosevelt, Arthur C. Clarke, Henry Ford und Charles Darwin.

The Agile Bookshelf: Incorruptible

Für alle, die vom Silicon-Valley-Entrepreneur Eric Ries nur seine bisherige Bücher kennen, dürfte sein neues Buch Incorruptible ein eher überraschendes Thema haben. The Lean Startup gab einem ganzen Vorgehensmodell einen Namen und gilt heute als Standard-Werk für Startup-Gründer und The Startup Way übertrug das auf etablierte Unternehmen. Incorruptible geht dagegen in eine andere Richtung: es will dabei helfen, (junge) Unternehmen gegen feindliche Übernahmen zu schützen.

Um Incorruptible (zu Deutsch etwa: nicht korrumpierbar) zu verstehen, muss man zuerst erkennen, was Ries unter einer solchen feindlichen Übernahme (meiner sehr freien Übersetzung seines Begriffs Corruption, der eine grössere Bedeutung hat als das deutsche Wort Korruption) versteht. Verkürzt gesagt: eine Entmachtung des Gründers durch Investoren, die derartig auf kurzfristige Gewinnsteigerungen fixiert sind, dass sie bereit sind, dem alles zu opfern, was die Firma bisher ausgemacht hat.

Wichtig ist für ihn dabei, dass für ihn derartige Aktionen nicht durch Bösartigkeit, Partikularinteressen oder sonstige individuelle Motivationen entstehen, sondern systemische Ursachen haben. Da die Angestellten von Investment- und Kapitalverwaltungsgesellschaften in kurzen Zyklen an der Vermehrung des von ihnen verwalteten Kapitals gemessen werden, orientieren sie ihr Handeln vor allem daran, und geben dieses Ziel an die Firmen weiter, an denen sie Anteile halten.

Diese Zielsetzung der kurzfristigen Gewinn-Erzeugung gelangt in diesen Firmen zuerst zum Top-Management, dass darauf aufbauend die Aufgabe erhält, Gewinne möglichst früh abzuführen, Kosten zu senken und Auslastungen zu optimieren. Langfristige Effekte werden im Vergleich als nachrangig behandelt. Dieses herabreichen vom Investor über die Manager in alle Bereiche nennt Ries die "finanzielle Schwerkraft", da sie im Geschäftskontext quasi ein Naturgesetz ist.

Nun kann es vorkommen, dass ein Gründer oder Manager andere Ziele hat. Dass er z.B. seine Mitarbeiter stärker am Firmenerfolg beteiligen will oder dass er eher langfristig und strategisch investieren will, statt kurzfristige Gewinne zu realisieren. Das würde den Zielen seiner Investoren und institutionellen Anteilseigner aber derartig zuwiderlaufen, dass sie allein aufgrund ihrer eigenen formalen Ziele ein Interesse daran haben, ihn zu ersetzen - und damit eine feindliche Übernahme zu versuchen.

Ries listet zahlreiche Firmen auf, denen es genau so ergangen ist, gibt aber auch zahlreiche Gegenbeispiele, die diesem Schicksal entkommen konnten. Und er zeigt auf, wie ihnen das gelungen ist. Und an dieser Stelle taucht er in ein gleichzeitig langweiles und spannendes Thema ein: Governance, also den rechtlichen und internen prozeduralen Ordnungsrahmen für die Leitung und Überwachung einer Firma. Den hier liegt der grosse Hebel.

Wenn etwa in den internen Vorschriften festgelegt ist, dass ein Manager unter mehreren Optionen immer die wählen muss, die der Firma das meiste Geld bringt, ist er manchmal rechtlich verpflichtet, Entscheidungen zu treffen, die er moralisch für falsch hält. Wenn dort dagegen Mitbestimmung, Nachhaltigkeit oder gesellschaftliche Verantwortlichkeit definiert werden, können unverantwortliche Management-Entscheidungen dadurch unterbunden werden.

Was an den in dem Buch gesammelten Beispielen für derartige Firmen bemerkenswert ist, ist, dass viele von ihnen (Norvo Nordisk, Carl Zeiss, 3M, Hershey und viele mehr) überdurchschnittlichen geschäftlichen Erfolg haben. Im Grunde ist das die krönende Pointe seiner Ausführungen: werden Investoren und Anteilseigner daran gehindert, ihre Firmen kurzfristig auszupressen, sind ihre Gewinne in der langfristigen Betrachtung deutlich höher.

Was zum Schluss noch erwähnenswert ist, ist die von dem in Kalifornien lebenden Eric Ries aus offensichtlichen Gründen eingenommene US-amerikanische Perspektive. Durch sie befindet sich das in Europa und Asien verbreitete, in Amerika aber eher seltene Konstrukt des Familienunternehmens ausserhalb seiner Betrachtungen, auch wenn es die von ihm beschriebenen Ziele ebenfalls anstrebt und meistens auch erreicht. Vielleicht ein Thema für die nächste Auflage.

Estuarine Mapping

Bild: Rawpixel - CC0 1.0

Wer in Workshops oder Unterlagen die Dynamik und Veränderbarkeit seiner Arbeitsumgebung übersichtlich visualisieren wollte, der wird bisher mit grosser Wahrscheinlichkeit eines von zwei popolären Werkzeugen benutzt haben: die Stacey Matrix von Ralph Stacey oder das Cynefin Framework von Dave Snowden. Seit dem Jahr 2022 ist noch ein drittes dazugekommen: die Estuarine Map (ins Deutsche übersetzt die Flussmündungs-Karte), ebenfalls von Dave Snowden.

Die Estuarine Map, die ihren Namen bekommen hat, weil sie der Landkarte einer Ästuar-Flussmündung ähnlich sieht, ist grundsätzlich eine Übersicht über drei Objekt-Typen, aus denen das sozio-technische System einer Arbeitsumgebung zusammengesetzt ist. Constructors (Bausteine) sind die vorgegebenen Strukturen, etwa Gesetze, Bauwerke oder eingesetzte Software. Constraints (Beschränkungen) sind einengende Faktoren wie Geld oder Prozessvorgaben, Actors (Akteure) sind Menschen oder Gruppen.

Diese Objekte, die je nach Einzelfall sehr unterschiedlich sein können, werden in eine Matrix aus zwei Dimensionen eingeordnet: die erste, die Zeit, zeigt an, wie lange es vermutlich dauern würde, den Zustand oder die Zielsetzung eines Objektes zu verändern, während die zweite, die Energie, darüber Auskunft gibt, wie anstrengend oder ressourcenverbrauchend diese Bemühungen sein würden. Diese Einordnung entspricht nicht konkreten Werten wie Stunden oder Kilojoule sondern ist relativ zueinander.

Sobald die Objekt-Einordnung stattgefunden hat, kann durch das Ziehen von Linien eine Gruppierung stattfinden. Was mit wenig Zeit und Energie zu verändern ist, ist volatil (was auch heisst, dass Änderungen hier oft nur flüchtig sind), was nicht mit vertretbarer Kraft und Dauer zu ändern ist, ist kontrafaktisch (d.h. der Glaube, dass hier etwas zu verändern wäre, widerspricht den Fakten). In der Mitte trennt schliesslich die Liminal Line (Grenzlinie) die selbst veränderbaren und die nur beeinflussbaren Objekte.

Bis zu diesem Punkt ist die Estuarine Map noch eine reine Zustandsbeschreibung, sie lässt sich aber auch als Werkzeug für das Veränderungsmanagement nutzen. Zum Einen dadurch, dass bereits zu beobachtende Tendenzen mit Hilfe von Pfeilen als Bewegungen innerhalb der Matrix dargestellt werden, zum Anderen dadurch, dass mit Hilfe von verändernden Eingriffen versucht wird, derartige Tendenzen selbst einzuleiten oder anzuhalten (auch das lässt sich dann mit Pfeilen visualisieren).

Wer schon einmal mit Stacey Matrix oder Cynefin Framework gearbeitet hat wird sich auch im Estuarine Mapping schnell zurechtfinden, das Ergebnis sieht ähnlich aus und funktioniert ähnlich. Der wesentliche Unterschied ist die Erarbeitung: wärend in den beiden anderen Ansätzen eine Einordnung der Objekte in vordefinierte Felder erfolgt, werden die Grenzlienien hier erst relativ spät definiert und gezogen. Auch die Vordefinition der drei Objekt-Kategorien ist neu.

Eine bereits im Fall des Cynefin Frameworks zu beobachtende Eigenheit der Cynefin Company (der hinter beidem stehenden Organisation) ist schliesslich auch bei den Estuarine Maps wiederzufinden: eine Neigung zu leicht schrulligen Begriffen. Neben Constructor, kontrafaktisch und Liminal Line gehören dazu auch noch einige weitere, die ich hier der Einfachheit halber weggelassen habe. Aber die geben dem Ganzen auch einen Teil seines Charmes.

Ein Bild sagt mehr als 1000 Worte (LVIII)

Das Exit Ramp-Meme. Ein unverwüstlicher Klassiker.

Der agil-industrielle Komplex (III)

Bild: Pexels / Fauxel - Lizenz

Wenn die Rede vom agil-industriellen Komplex ist, ist damit in der Regel das über-kommerzialisierte Geschäft mit (weitgehend wirkungslosen) Zertifizierungen und Schnell-Schulungen gemeint, die in grossen Mengen nachgefragt, angeboten und verkauft werden (siehe hier). Abseits der öffentlichen Aufmerksamkeit hat sich aber noch ein weiteres kritisch zu sehendes Geschäftsfeld etabliert: die Vermittlung unpassender (!) externer Scrum Master und Agile Coaches in großem Ausmass.

Entstanden ist dieses Geschäftsfeld aufgrund des Fachkräftemangels, durch den Positionen lange nicht intern besetzt werden konnten, durch die in vielen Firmen fehlenden Karrierepfade dieser Rollen (die bei Beförderung einen Wechsel in andere Rollen notwendig machen) und aufgrund eines verbreiteten Unwillens, sie dauerhaft zu etablieren - oft getrieben von dem Missverständnis, dass der Scrum Master daran arbeiten würde, sich selbst abzuschaffen, und daher nicht dauerhaft benötigt würde (siehe hier).

Alleine diese Ursprünge sind bereits problematisch, darüber hinaus ist mittlerweile aber auch das darauf aufbauende Vermittlungsgeschäft hochgradig dysfunktional geworden. Und das nicht etwa, weil die Vermittler durchgehend unprofessionell oder böswillig wären, sondern wegen schwerer Systemfehler des ganzen Vermittlungsmarktes für agile Methoden-Rollen, die unpassende Stellenbesetzungen hochwahrscheinlich machen und häufig sogar (unbeabsichtigt) erzwingen.

Der erste dieser Fehler im System ist ein extrem ungesundes Verhältnis von Vermittlern zu den zu Vermittelnden. In den Datenbanken verfügbarer Scrum Master und Agile Coaches finden sich hunderte, bei grossen Vermittlungsfirmen sogar tausende von Profilen, dagegen steht bei den meisten dieser Firmen eine höchstens zweistelligen Anzahl von Vermittlern. Bereits eine Sichtung aller verfügbaren Profile scheitert bereits an fehlender Kapazität, eine Qualitätssicherung erst recht.

Als nächster Faktor kommt ein in fast allen Vermittlungsfällen gegebener hoher Zeitdruck dazu. Viele Vermittler warten nur wenige Tage oder sogar nur Stunden, bevor sie bei Ausschreibungen einige Profile einreichen und die Suche nach weiteren beenden. Zum einen, weil erfahrungsgemäss die ersten auch zuerst gesichtet werden und erhöhte Chancen haben, genommen zu werden, zum anderen um zu verhindern, sich selbst durch hunderte Profile arbeiten zu müssen.¹

Der dritte Fehler ist die Heranziehung eines möglichst niedrigen Preises (d.h. des aufgerufenen Stundensatzes) als zentrales Entscheidungskriterium, die vor allem grössere Unternehmen in ihren Richtlinien stehen haben. In der Theorie kann ein höherer Preis zwar durch Erfahrung und Expertise gerechtfertigt werden, da bei den meisten Vermittlern aber die Zeit zur gründlichen Sichtung der Profile fehlt (siehe oben) wird am Ende fast immer nur das eingereicht, was möglichst billig ist.

Ein Manager eines unserer Kunden hat diese Gesammtkonstellation einmal treffend zusammengefasst: "Wenn wir über die Vermittlungsagenturen nach externen Methodikern suchen, bekommen wir immer die billigsten unter denen, die gerade verfügbar sind, angeboten. Und dann merken wir schnell, warum die so billig sind, und warum die gerade keine Aufträge haben. Als nächstes fluchen dann alle über die Vermittler, dabei machen die das nur so, weil wir die so steuern."

Eine ausweglose Situation also? Natürlich nicht, Auswege gibt es immer, und hier sind sie sogar naheliegend: den grössten Hebel haben die Unternehmen, die externe Scrum Master und Agile Coaches suchen. Die müssen diejenigen Vermittlungsdienstleister anzählen, die ihnen nur spontan verfügbare Billigkräfte anbieten, und eher mit denen zusammenarbeiten, die nach ggf. längerer Suche gute Kandidaten bringen. Und sie müssen auch fair dafür bezahlen (beide, die Vermittler und die Externen).

Es gibt sogar Firmen, die genau das tun, allerdings sind es eher wenige im Vergleich zu denen, die die Systemfehler des Vermittlungsmarktes (unbewusst) verstärken, indem sie den Preis und die schnelle Verfügbarkeit immer wieder zu ihren Hauptentscheidungskriterien machen. Und solange sich diese Mengenverhältnisse nicht ändern, wird auch der Personalvermittlungs-Sektor des agil-industriellen Komplexes weiter dysfunktional vor sich hin florieren. Works as designed.

¹Dass bereits nach wenigen Tagen oder Stunden dreistellige Bewerberzahlen entstehen, ist nicht ungewöhnlich, und ist nochmal eine eigene Geschichte

Navigating Agile Transformations in a Crisis

Agile Transformationen hat es mittlerweile viele gegeben, und dementsprechend auch viele Erfahrungsberichte. Dieser hier gefällt mir, da er nicht nur eine der üblichen (und meistens geschönten) Erfolgsgeschichten ist, sondern klar benennt, dass es Probleme gegeben hat, und welche.

Darüber hinaus bietet die Referentin Polina Patsulda einen Blick in ihren Werkzeugkoffer, in dem sich vom Scarf Model über den Kübler Ross-Zyklus bis Radical Candor verschiedene Ansätze befinden, von denen man erfahren kann, wie sie hier eingesetzt wurden. 

Agile Success Stories: Teams Beyond Budgeting

Bild: Unsplash / Vitaly Gariev - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich 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.

Ich durfte vor einiger Zeit als externer Berater eine agile Transformation eines grossen Konzerns begleiten, zu welcher eine ganze Reihe von Massnahmen gehörte: Reorganisation von Spezialisten-Gruppen zu crossfunktionalen Teams, Delegation von Verantwortung nach unten, Abbau von Vorschriften, Einführung von Retrospektiven und vieles mehr - was aber nach Aussage fast aller Beteiligten die wichtigste Änderung war, war die der Budgetierung.

Bis zu diesem Zeitpunkt waren die Budgetierungsprozesse so verlaufen wie in den meisten Unternehmen. Ein Budget "gehörte" einer Fachabteilung oder Initiative, die mit den umsetzenden Einheiten aushandelte, was sie dafür erhalten würde. Ab da wurden die Arbeitsstunden den jeweiligen Budgetposten zugeordnet - und nur an Arbeitspaketen für die noch Budget vorhanden war, durfte auch gearbeitet werden. Arbeit an nicht budgetierten Aufgaben war nicht erlaubt.

Dieses Vorgehen hatte ursprünglich einen sinnvollen Kern gehabt, so sollte sichergestellt werden, dass nur an den aus Unternehmenssicht wirklich wichtigen Aufgaben gearbeitet wurde, denn nur die hatten ein Budget erhalten. Für eine Welt sich schnell ändernder Märkte und Technologien war es aber zu langsam und zu bürokratisch - wer den Umsetzungsplan ändern wollte, musste bis zur nächsten (jährlichen) Budgetierung warten oder ausufernde Change Request-Dokumente ausfüllen.

Da das dazu geführt hatte, dass selbst offensichtlich notwendige Planungs-Änderungen nicht stattgefunden hatten, war die Trennung von Arbeitsplanung und Budgetierung eines der Hauptziele der agilen Transformation gewesen. Und glücklicherweise liess sich das Management auch von einem alternativen Ansatz überzeugen: von Beyond Budgeting, das bereits in den 70er und 80er Jahren in Skandinavien entwickelt worden war.

Im Rahmen seiner Umsetzung wurde die harte Verdrahtung von Budgets und Fachbereichs-Anforderungen aufgehoben, stattdessen wurden den Entwicklungsteams jeweils Budgets für ganze Jahre zugewiesen, die lediglich mit groben Themengebieten wie z.B. Zahlungsabwicklung oder Kundenkommunikation verbunden waren. Dass an den wichtigsten Dingen gearbeitet wurde, wurde nicht mehr über die Budgets, sondern durch eine übergreifende Priorisierung sichergestellt.

Wenn sich jetzt während der budgetierten Zeiträume Notwendigkeiten oder Prioritäten änderten, war es nicht mehr nötig, die ganze Finanzplanung anzupassen, es musste nur die übergreifende Priorisierung geändert werden. Natürlich war auch das mit Arbeit verbunden, im Vergleich zum alten Vorgehen war der Aufwand aber deutlich geringer. Dass notwendige Planungs-Änderungen aus Abneigung gegen den damit verbundenen Arbeitsaufwand verschoben wurden, kam ab da kaum noch vor.

Auch die budgetierten Zeiträume selbst wurden flexibler gestaltet. Es gab zwar weiterhin Jahrespläne, diese fanden aber auf einem eher hohen Abstraktionsgrad statt. Das Herunterbrechen erfolgte jeweils zum Beginn der Quartale, wodurch ein längeres Auseinanderlaufen aus (Budget-)Planung und Arbeits-Fortschritt vermieden werden konnte. In einer späteren Phase der agilen Transition wurde diese Quartalsplanung als Ressort-übergreifendes Big Room Planning durchgeführt.

Zur ganzen Geschichte gehört auch, dass diese Umstellungen nicht ohne Konflikt abgelaufen sind. Den Verlust der Kontrolle über die Detail-Budgetierung empfanden manche Fachbereichs-Manager auch als Verlust von Status und von Druckmitteln, die bisher zur Durchsetzung eigener Ziele gegen andere Interessen genutzt werden konnten. Am Ende konnte Beyond Budgeting deshalb auch nicht überall umgesetzt werden. Dort wo es gelungen war, führte es allerdings zu deutlich effektiverem Arbeiten.