Hilfreiche Agile Gesetze für Transformationen 🇩🇪

In Kürze: Agile Gesetze & verteilte Teams

Bei vielen Gelegenheiten hat die Arbeit mit agilen Teams die bestehenden organisatorischen, technischen und kulturellen Herausforderungen in vielen Organisationen verschärft. Der erfolgreiche Beginn von Veränderungen erfordert immer die Akzeptanz, dass es ein Problem gibt, das Aufmerksamkeit erfordert. Der folgende Artikel befasst sich mit typischen Hindernisse, die dem Erreichen von Agilität entgegenstehen, indem er mehrere agile Gesetze, die für alle agilen Teams besonders relevant sind, noch einmal beleuchtet.

The most popular discussion on LinkedIn last week was: The MinimumViableLibrary — #ProductOwner v2.0 edition!

📖 Meistern Sie Scrum mit Leichtigkeit; bestellen Sie jetzt das Scrum Anti-Patterns Guide Buch — es ist ab sofort verfügbar!

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 42.000 Abonnenten anschließen.

Agile Gesetze: Conway, Brooks, Hackman, Goodhart, Larman und Parkinson in der Praxis

Aus der langen Liste von Beobachtungen, Heuristiken und mentalen Modellen in der Psychologie, im Organisationsdesign oder in der Softwareentwicklung wähle ich acht „agile Gesetze“ aus, die im Bereich von agilen Teams besonders relevant sind:

Conways Gesetz

Mel Conway postulierte seine These erstmals 1968 in einer Arbeit, in der er feststellte:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” (Source.)

Mit anderen Worten: Wenn zwei Teams einen Teil einer Anwendung separat erstellen, wird dieses System wahrscheinlich zwei Komponenten haben, wodurch Abhängigkeiten und zusätzlicher Kommunikationsaufwand entstehen.

Dieser Effekt war schon immer eine Herausforderung. Wenn Teams gemeinsam an einem Ort arbeiten, kann man zumindest informell bei einem Kaffee oder in der Kantine verhandeln. Bei verteilten Teams hat sich dieser Ansatz angesichts des zusätzlichen Kommunikationsaufwands und der damit verbundenen Formalität, ein weiteres Zoom-Meeting zu organisieren, als weniger geeignet erwiesen.

Ein möglicher Weg, das Problem anzugehen, ist das inverse Conway-Manöver: “…you may want to begin by breaking down silos that constrain the team’s ability to collaborate effectively.” (Siehe auch: Torbjörn Gyllebring: The Reverse Conway — Organizational Hacking for Techies.)

Die Idee existiert bereits seit mehreren Jahren: Man forme die Teams entsprechend den Produktanforderungen und gebe ihnen die Autonomie, die bestmögliche Lösung sowohl unter dem Gesichtspunkt des Leistungsversprechens als auch der organisatorischen Nachhaltigkeit zu schaffen.

(Ein kostenloser Artikel über Conway von der Harvard Business School: Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis.)

Agile Gesetze: Brooks’sches Gesetz

Frederick Brooks konstatierte 1975 in seinem Buch The Mythical Man-Month: Essays on Software Engineering, dass “adding manpower to a late software project makes it later.”

Die typische Reaktion der mittleren Führungsebene, die von einer Neigung zum Handeln getrieben wird, um Initiative zu zeigen, die Krise eines verspäteten Projekts zu bekämpfen und einen vermeintlichen Kontrollverlust zu überwinden, besteht oftmals darin, mehr Leute einzusetzen, anstatt den Teams die Möglichkeit zu geben, sich an die neuen Gegebenheiten anzupassen und ihnen mehr Autonomie einzuräumen.

Hackmans Gesetz

Einem Team oder Projekt mehr Leute hinzuzufügen, um die Umsetzung zu beschleunigen, widerspricht auch einem anderen agilen Gesetz, dem Hackman’schen Gesetz: “The larger a group, the more process problems members encounter in carrying out their collective work […] worse, the vulnerability of a group to such difficulties increases sharply as size increases.”

In einer verteilten Arbeitssituation kommt erschwerend hinzu, dass es aufgrund des erhöhten Kommunikationsaufwands zu einem additiven Effekt kommt. Eine geeignete Strategie, um diesem Effekt entgegenzuwirken, wäre daher der Einsatz kleiner, agiler Teams und einer Organisation, die als Team von Teams konzipiert ist, die aufeinander abgestimmt und dennoch autonom sind.

Goodharts Gesetz

Bereits 1975 veröffentlichte der britische Ökonom Charles Goodhart erstmals die Idee, die seinen Namen tragen sollte, als er über Geldpolitik schrieb. Die Anthropologin Marilyn Strathern fasste sie später wie folgt zusammen: “When a measure becomes a target, it ceases to be a good measure.” (Doc Norton: “And the target therefore no longer means what you think it does.”)

Wendet man dies auf agile Teams an, so müssen wir auf das mittlere Management zurückkommen und auf den tatsächlichen oder wahrgenommenen Druck, den die Organisation ausübt. Ein empfundener Kontrollverlust aufgrund der verteilten und oft asynchronen Kommunikation und der Drang, dafür zu sorgen, dass man als Manager in den Kommunikationsartefakten sichtbar wird, kann dazu führen, das Vorgehen zu straffen: mehr Berichte, mehr Kennzahlen und mehr Meetings.

Auch hier ist eine solche Kursänderung inmitten einer komplexen Veränderung mit ungewissem Ausgang das Gegenteil einer angemessenen Maßnahme. Mehr Kontrolle auszuüben, um der Komplexität zu begegnen, funktioniert nicht, wie jede erfahrene Führungskraft festgestellt hat. (Eli Goldratt: “Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way […] do not complain about illogical behavior.”)

Die Alternative ist, Raum für Autonomie zu schaffen und Vertrauen in die Menschen zu setzen: “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”

(Curtis Carlson: “In a world where so many people now have access to education and cheap tools of innovation. Innovation that happens from the bottom up tends to be chaotic but smart. Innovation that happens from the top down tends to be orderly but dumb.”)

Agile Gesetze: Larmans Gesetz

Sie könnten sich nun fragen, wie es kommt, dass es Organisationen so oft nicht gelingt, Organisationsstrukturen zu schaffen, die flexibel und dennoch belastbar sind. Craig Larman formulierte einen Grund dafür: “Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.” (Quelle.)

Diese Beobachtung spiegelt den systemischen Ansatz zur Veränderung wider: Wenn man will, dass sich das Verhalten der Menschen ändert, muss sich zuerst das System ändern. Der Versuch, die Kultur einer Organisation zu ändern, ohne das zugrunde liegende System zu ändern, wird scheitern. Die derzeit auferlegte Notwendigkeit, sich zu ändern, um auf die Krise zu reagieren, wird daher auf das System selbst abzielen müssen, nicht nur auf die operativen oder taktischen Verfahren.

Parkinsons Gesetz

Der Grund, warum das Time-Boxing bei agilen Teams so geschätzt wird, ist einfach: “Work expands so as to fill the time available for its completion.” (Parkinson’s Law.)

Bei dem Versuch, wertvolle, nachhaltige und profitable Produkte in komplexen Umgebungen zu schaffen, ist eine schnelle Feedback-Schleife unerlässlich: Bauen, messen, lernen. Mit dem Release zu lange zu warten oder nach Perfektion zu streben, ist keine Option. Stattdessen sind Sprints, Zyklen, Iterationen sowie Inspektion und Adaption das A und O eines Produktteams. Unser Ziel ist es, schnell genug zu iterieren, um mit dem Markt synchron zu bleiben, und dennoch zu viel Overhead bei zu kurzen Sprints zu vermeiden.

Das Problem mit verteilten agilen Teams besteht darin, dass die Routine der Produktlieferung manchmal dazu führt, dass diese höher bewertet wird als der Lernteil der Gleichung. Aber wenn wir uns auf die Lieferung konzentrieren, um unsere Vorliebe für Aktionismus zur Bewältigung von Ungewissheit zu bedienen, so sind wir damit auf dem besten Wege eine „Feature Factory“ zu werden—was das Gegenteil der Bildung eines Teams von autonomen Teams ist, die Probleme im Namen unserer Kunden lösen.

Little’s Gesetz

Little’s Law ist ein wichtiger Wegweiser, da es ein zentrales Prinzip prägnant umreißt: Die in Arbeit befindlichen Aufgaben sind ein Produkt aus der Eingangsrate von Aufgaben und der Zeit, die sie für ihre Fertigstellung benötigen: Work in Progress = Throughput × Lead Time.

Dieses Verhältnis sorgt für ein Gleichgewicht der Arbeitsbelastung und verbessert die Vorhersagbarkeit der Lieferung, so dass die Teams effizient arbeiten können, ohne sich zu überlasten. Die Anwendung dieses Flussprinzips macht es zu einem unverzichtbaren Werkzeug für die Verwaltung von Arbeitsabläufen und die Aufrechterhaltung eines nachhaltigen Tempos in der Softwareentwicklung. Es befürwortet auch einen Schritt bei mangelnder Teameffektivität, der von vielen Managern als kontrovers empfunden wird: Um den Fluss und den Output von Teams zu verbessern, die sich schwer tun, reduziert man den Input. (Das ist der Ursprung des Sinns der Begrenzung von Work in Progress.)

Erfahren Sie mehr über Little’s Law in diesem kostenlosen Whitepaper von Scrum.org.

Occam’s Razor

In der Softwareentwicklung fördert Occam’s Razor die Einfachheit bei der Konzeption und Erstellung von Softwaresystemen. Es rät dazu, unter gleichwertigen Alternativen die unkomplizierteste Lösung zu wählen und so unnötige Komplexität zu vermeiden, was sich gut mit agilen Prinzipien wie der Minimierung von Over-Engineering deckt. Dieses Prinzip ist mit dem KISS-Ansatz (Keep It Simple, Stupid) verwandt, der ebenfalls für unkomplizierte Problemlösungen plädiert.

Die Verletzung von Occam’s Razor äußert sich in verschiedenen Anti-Mustern. Over-Engineering und Gold Plating fügen unnötige Komplexität und Funktionen hinzu, während Big Design Up Front dem iterativen Charakter von Agile durch übermäßige Planung im Vorfeld widerspricht. Feature Creep bringt den Projektumfang durch ständige ungeplante Ergänzungen aus dem Gleichgewicht. Die missbräuchliche Verwendung von Entwurfsmustern, das Ignorieren der Notwendigkeit eines regelmäßigen Refactorings und das Übersehen technischer Schulden führen zu einer unübersichtlichen, ineffizienten Codebasis. Darüber hinaus verkompliziert der übermäßige Rückgriff auf komplexe Tools und Technologien für einfache Probleme den Entwicklungsprozess.

Erfahren Sie mehr über Occam’s Razor.

Agile Gesetze — Fazit

Die Arbeit mit agilen Teams hat die bestehenden organisatorischen, technischen und kulturellen Herausforderungen in vielen Organisationen verstärkt. In dieser Hinsicht hat sich die Überprüfung der „agilen Gesetze“ als hilfreich bei der Bewältigung dieser Hindernisse erwiesen. Möglicherweise können Sie diese Probleme sogar zu Ihrem Vorteil nutzen. Wie das Sprichwort sagt: „Jedes Problem ist eine Chance.“

Haben Sie in letzter Zeit eines dieser agilen Gesetze in Aktion erlebt? Wenn ja, teilen Sie uns dies bitte in den Kommentaren mit.

Agile Gesetze — weitere Lektüre

Agile Failure Patterns in Organizations 2.0.

Verteiltes agiles Arbeiten (4): Anti-Patterns.

Verteiltes agiles Arbeiten (1): Praktiken & Werkzeuge für Scrum Master & agile Coaches.

Download the Scrum Anti-Patterns Guide for free.

✋ Nicht versäumen: Lernen Sie mehr über agile Gesetze in der 19.000-köpfigen „Hands-on Agile“ Slack-Community

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel Agile Gesetze: Von Conway über Goodhart bis Occam’s Razor wurde zunächst auf Berlin-Product-People.com veröffentlicht.