Vor fünf Jahren wurde einem Entwickler gekündigt, weil er seinem CEO gegenüber behauptete, dass Daily Standups schlecht seien. Eine drastische Reaktion auf eine scheinbar harmlose Meinung über ein weitverbreitetes agiles Ritual. Doch diese Geschichte offenbart ein tieferliegendes Problem in der modernen Softwareentwicklung: den Widerspruch zwischen dem, was theoretisch funktionieren sollte, und dem, was in der Praxis tatsächlich passiert.
Die Mathematik des Zeitverlusts
Daily Standups verschlingen mehr Zeit, als die meisten Teams wahrhaben wollen. Ein zehnminütiges Meeting mit acht Teilnehmern kostet 80 Personenminuten – täglich. Das sind über sechs Stunden pro Woche, die für ein Ritual aufgewendet werden, dessen Nutzen oft fragwürdig ist. Doch das ist nur die Spitze des Eisbergs.
Der eigentliche Kostenfaktor liegt im Context Switching. Entwickler müssen ihre konzentrierte Arbeit unterbrechen, sich mental auf das Meeting einstellen, teilnehmen und anschließend wieder in den Flow zurückfinden. Dieser Prozess kann leicht 30 bis 45 Minuten verschlingen – für ein zehnminütiges Meeting. Bei einem fünfköpfigen Entwicklerteam sprechen wir von zweieinhalb bis vier Stunden verlorener Produktivität. Täglich.
Psychologie schlägt Ökonomie
Warum halten Führungskräfte trotz dieser offensichtlichen Ineffizienz an Daily Standups fest? Die Antwort liegt in der menschlichen Psychologie. CEOs und Manager bekommen durch diese Meetings ein Gefühl der Kontrolle und des Überblicks. Sie sehen, woran gearbeitet wird, identifizieren potenzielle Probleme und fühlen sich als aktiver Teil des Entwicklungsprozesses.
Diese psychologischen Vorteile sind real und nicht von der Hand zu weisen. Das Problem entsteht, wenn die emotionalen Bedürfnisse des Managements über die produktiven Bedürfnisse der Entwicklungsteams gestellt werden. Hier zeigt sich ein klassisches Beispiel dafür, wie Psychologie die Ökonomie übertrumpft – selbst wenn die Zahlen eindeutig gegen eine Praxis sprechen.
Das „Richtig machen“-Problem
Unvermeidlich wird jemand einwenden: „Ihr macht Standups falsch!“ oder „Es ist ein Anti-Pattern, wenn der CEO beim Standup dabei ist!“ Diese Argumente greifen jedoch zu kurz. Selbst wenn Standups „richtig“ durchgeführt werden, bleibt das fundamentale Problem des Context Switching bestehen. Die zeitlichen Kosten fallen an, unabhängig davon, ob das Meeting den agilen Prinzipien entspricht oder nicht.
Noch problematischer ist, dass niemand schlüssig erklären kann, was „richtig machen“ konkret bedeutet und wie das die Entwickler für den Overhead des Context Switching entschädigt. Diese Vagheit ist typisch für viele agile Praktiken: Wenn sie nicht funktionieren, liegt es angeblich an der falschen Umsetzung, nicht an den Methoden selbst.
Projekt- versus Produktentwicklung
Ein weiterer kritischer Punkt: Die meisten Startups und modernen Softwareunternehmen entwickeln Produkte, nicht Projekte. Standups entstammen jedoch einer Zeit, in der Softwareentwicklung noch stark projektbasiert gedacht wurde. In der Produktentwicklung geht es um kontinuierliche Wertschöpfung und die Optimierung des Lead Times vom Konzept bis zur Umsetzung.
Hier zeigen sich Pull-basierte Systeme als überlegen. Statt dass alle Teammitglieder täglich berichten, was sie gestern getan haben und heute tun werden, arbeiten sie selbstorganisiert an den wichtigsten Aufgaben und holen sich Unterstützung, wenn sie sie brauchen. Diese Arbeitsweise reduziert nicht nur den administrativen Overhead, sondern führt auch zu höherer Qualität, da die Aufmerksamkeit auf die Lösung von Problemen gerichtet ist, nicht auf deren Berichterstattung.
Alternative Ansätze
Was sind die Alternativen? Pull-basierte Systeme wie Kanban bieten eine elegante Lösung. Statt täglicher Meetings fokussieren sie auf den kontinuierlichen Fluss von Aufgaben durch das System. Probleme werden sichtbar, wenn sie auftreten, nicht erst beim nächsten Standup. Die Kommunikation erfolgt bedarfsgerecht und asynchron, was besonders in verteilten Teams effizienter ist.
Asynchrone Updates über Tools wie Slack oder leichtgewichtige Projektmanagement-Software können den Informationsaustausch ohne die Kosten des Context Switching ermöglichen, insofern man auch genug Zeit zur Antwort lässt. Sogar die altgedienten E-Mails sind hier nützlich. Lead Time-Tracking von der Konzeption bis zur Auslieferung gibt Managern die Kontrollinformationen, die sie brauchen, ohne die Entwicklerproduktivität zu beeinträchtigen.
Die Kultur der Rechtfertigung
Das tieferliegende Problem ist eine Kultur, in der agile Praktiken als unantastbar gelten. Kritik wird abgewehrt mit dem Argument, man verstehe die Methoden nicht richtig oder setze sie falsch um. Diese Haltung verhindert eine ehrliche Bewertung der Kosten und Nutzen etablierter Praktiken.
Erfolgreiche Teams stellen Ergebnisse über Prozesse. Sie fragen nicht „Machen wir Scrum richtig?“, sondern „Liefern wir schnell und qualitativ hochwertigen Code?“ Diese Fokussierung auf Outcomes statt auf die Einhaltung von Prozessen führt zu pragmatischeren und oft effektiveren Arbeitsweisen.
Fazit
Daily Standups sind ein Symptom für eine tieferliegendes Problem in der Art, wie wir über Softwareentwicklung denken und reden. Der Einsatz von Standups entsteht fast immer aus dem Bedürfnis nach Kontrolle und Vorhersagbarkeit in einem inhärent unvorhersagbaren Prozess. Statt diese Realität zu akzeptieren und Systeme zu schaffen, die mit Unsicherheit umgehen können, klammern wir uns an Rituale, die uns ein falsches Gefühl der Kontrolle geben.
Die Zukunft der Softwareentwicklung liegt in adaptiven, pull-basierten Systemen, die die Autonomie der Entwickler respektieren und gleichzeitig die Informationsbedürfnisse des Managements erfüllen. Es ist Zeit, Praktiken zu überdenken, die mehr kosten als sie bringen – auch wenn sie von „smarten Leuten“ vor Jahrzehnten erfunden wurden.
Der gefeuerte Entwickler hatte möglicherweise recht. Vielleicht sollten wir öfter den Mut haben, etablierte Praktiken zu hinterfragen, bevor sie uns mehr kosten, als wir uns leisten können.