Scrum oder die Kunst, mit Komplexität umzugehen

Ameisen und Software

Was haben Ameisenkolonien mit Scrum-Teams gemeinsam? Ameisenkolonien sind hochproduktiv, selbstorganisiert und cross-funktional: 50% beschaffen Nahrung, 25% bewachen die Kolonie, und 25% entfernen Dreck. Jede Ameise kann jede Aufgabe machen. Es gibt keine zentrale Vorgabe oder Planung, aus der die Ameisen ihre Aufgaben ablesen könnten. Sie erkennen anhand von chemischen Botenstoffen, was ihre Kollegen im unmittelbaren Umfeld machen - und passen sich entsprechend an. Gibt es schon genug Nahrungsbeschaffer, kann eine solche Ameise zum Wächter umsatteln.Es gibt noch mehr Parallelen: Ameisenkolonien sind komplexe Systeme, weil ihre Struktur nicht in Form von Ursache-Wirkung oder Vorgabe-Umsetzung verstanden werden kann. Sie entsteht vielmehr durch die Aggregation von vielen einzelnen, individuell getroffenen Entscheidungen (wer sich in die Ameisenwelt vertiefen will: hier eine sehr spannende Dokumentation).http://www.youtube.com/watch?v=z3qz84yqwds&feature=youtu.beSoftwareentwicklung ist ebenfalls komplex. Stellt ein Expertengremium zusammen, bestehend aus den besten Entwicklern, Testern und Fachleuten der Welt. Sperrt das Gremium drei Monate ein mit der Aufgabe, eine detaillierte Bauanleitung für ein mäßig anspruchsvolles Softwareprodukt zu entwerfen. Ich bin überzeugt: Die Experten würden grandios scheitern.Denn jede kleine Veränderung im technischen Entwicklungsprozess, jede minimale Abweichung von den fachlichen Anforderungen, jede noch so geringe Modifikation in den rechtlichen Rahmenbedingungen, kann eine Lawine an Veränderungen lostreten.Vor einem halben Jahr genau so erlebt: Das Entwicklungsteam versteht eine User Story ein wenig anders als vom Product Owner gewollt, setzt sie folglich mit Abweichungen um, stößt dabei auf einen bis dahin unbekannten Fehler in einer Kalenderfunktion, und entdeckt im Zuge des darauf folgenden Bugfixing eine neue Implementationsmöglichkeit für Timestamps, die auch fachlich höchst interessant ist, weil sie für den Kunden mehr Komfort bei der Bearbeitung von Personalfällen bietet. In der Folge wird das Product Backlog in wesentlichen Zügen umgeschrieben, um von dieser neu entdeckten Möglichkeit Gebrauch zu machen.Übrigens muss nicht alles, was schwierig zu verstehen ist, deshalb auch gleich komplex sein. Ein mechanisches Uhrwerk mit ewigem Kalender ist ein hochkompliziertes Gebilde - es braucht jede Menge Wissen, um seine Funktionsweise zu verstehen. Haben wir jedoch das Wissen, können wir das Verhalten des Uhrwerks und seiner Teile durch Beschreibung von Ursache-Wirkung sehr genau vorhersagen und eine taugliche, reproduzierbare Bauanleitung schreiben.

Planung ade?

Die Erkenntnis, dass es für Softwareprodukte keine solche Schritt-für-Schritt-Bauanleitung geben kann, wird bisweilen als Vorwand für eine "anything goes"-Philosophie verwendet. Dort heißt es dann, planmäßiges Arbeiten mache keinen Sinn, weil wir eben keinerlei Gewissheiten mehr haben. Das aber ist ein Trugschluss. Wenn ich keine sicheren Voraussagen machen kann, heißt das noch lange nicht, dass ich im Dunkeln tappe. Es bedeutet nur, dass meine Annahmen oder Hypothesen mit einer (nicht unbeträchtlichen) Wahrscheinlichkeit falsch sein können.Wie ist damit umzugehen? Indem Hypothesen so konstruiert werden, dass sie sich in möglichst kurzen Zeitintervallen durch die Praxis verifizieren und validieren lassen. Und indem wir dazu bereit sind, unsere Annahmen über Bord zu werfen, sobald sie sich als unhaltbar erweisen. In Scrum nennen wir solche Annahmen User Stories. Wir gehen davon aus, dass der Nutzer des Produktes eine Funktionalität haben will, weil er davon einen bestimmten Nutzen haben wird. Und fragen ihn regelmäßig, indem wir ihn die neue Funktionalität zum Ausprobieren geben, ob dieser Nutzen tatsächlich eintritt.Neulich herrschte bei einem unserer Projekte große Aufregung: Verbunden mit einem neuen Großkunden hatten sich die Anfragen auf eine Datenbank vervielfacht und zu erheblichen Performance-Problemen geführt, die der Kunde deutlich zu spüren bekommen hatte. Infolgedessen wurde das zuständige Scrum-Team zusammengetrommelt und gefragt, was es innerhalb des nächsten, zweiwöchigen Sprints an Lösungen bereitstellen könne. Manche Teammitglieder empfanden diesen Auftrag als Zumutung, denn es gab zu jenem Zeitpunkt keine produktionsnahe Testumgebung, auf der die Fehler auf der Datenbank zuverlässig hätten reproduziert werden können. "Wir können so nichts beweisen, sondern müssen wild vermuten, was die Performance-Probleme verursacht", lautete der Einwand.Aus den wilden Vermutungen entstand ein gemeinsames Brainstorming, und daraus wiederum ergaben sich Arbeitshypothesen in Form von kurzfristigen Lösungsansätzen. Das Team setzte sich für die Dauer eines zweiwöchigen Sprints zusammen, probierte seine Hypothese durch Umsetzung aus. Am Ende der zwei Wochen gab es eine Review: Was hatte funktioniert, was nicht, worauf sollte aufgebaut werden? Die akuten Probleme konnten in diesen zwei Wochen tatsächlich gelöst werden - der Kunde bekam von den Performance-Problemen nichts mehr zu spüren. Zugleich hatte die beinahe-Katastrophe das Bewusstsein für ein vorbeugendes Handeln geweckt. Am Ende dieses Reviews hingen über 100 weitere Lösungsansätze an der Wand. Auch hier galt es zu klären: Was davon wollen wir in den nächsten Wochen umsetzen und was lassen wir erstmal stehen?Softwareentwicklung ist in der Tat eine Zumutung. Es geht immer wieder um das Gleiche: Die Unwägbarkeiten des Alltags irgendwie in den Griff zu bekommen. Wer versucht, alles im Vorhinein zu klären, der investiert viel Zeit und Denken in etwas, das am Ende sowieso anders kommen wird. Wer im Gegenteil ganz auf das Planen verzichtet und unreflektiert loslegt, der wird am Ende überall ankommen - nur nicht dort, wo er sein möchte. Der gangbare Weg liegt dazwischen: Planen ja, aber in Form von klar formulierten, verifizierbaren Annahmen, die in kurzen Intervallen bestätigt oder eben enttäuscht werden. Das, zusammen mit der Bereitschaft zum ständigen Überdenken des eigenen Standpunktes, macht den Umgang mit Komplexität beherrschbar. Nicht nur für Ameisen.

Agile Toolbox
Scrum
Product Owner
Team
bgloger-redakteur
July 25, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4