Sprint-Wahnsinn. Warum Sprints bei uns kein Standard sind
Scrum verspricht Agilität und liefert Theater. Den Rhythmus legen wir je nach Projekt fest: Demo-Zyklen, wo sie reichen, Sprints, wo sie tragen.
Ausgangslage
Was Scrum im Mittelstand wirklich kostet
Wir haben in zwanzig Jahren Mittelstand und Konzernen genug Scrum-Implementierungen begleitet, um eine unbequeme Beobachtung zu machen: In den allermeisten Fällen verkauft Scrum den Eindruck von Geschwindigkeit, ohne Geschwindigkeit zu liefern. Daily-Standups, Refinement-Sessions, Sprint-Plannings, Retros, Reviews - die Zeremonien fressen oft mehr Kapazität, als sie an Fokus zurückgeben.
Das Versprechen war einmal: schneller anpassen, früher liefern, ehrlicher messen. Was in vielen Teams ankommt: Burndown-Charts, die niemand liest, Velocity-Zahlen ohne Aussagekraft, und Story-Points, die in der Realität gegen Tagessätze umgerechnet werden.
Velocity ist keine Wahrheit
Velocity misst, wie viele Story-Points ein Team in zwei Wochen abgearbeitet hat. Das klingt nach einer Kennzahl. In der Praxis ist es eine Selbstbeobachtung, die das gemessene System verändert: Sobald Velocity zum Ziel wird, schätzen Teams optimistisch, splitten Stories unsinnig fein und vermeiden alles, was sich nicht in Punkte fassen lässt. Refactoring, Lasttests, Sicherheitsfixes fallen hinten runter.
Burndown-Charts erzählen das falsche Drama
Burndown-Charts zeigen die ideale Linie und die echte Linie. Sie erzählen aber nicht, ob das Produkt am Ende besser ist. Wir haben Teams gesehen, die jede Sprint-Box pünktlich zumachen, deren Software-Qualität trotzdem sinkt, weil das Format Geschwindigkeit belohnt, nicht Entscheidungen.
Unser Modell
Demo-zu-Demo statt Sprint-zu-Sprint
Wo es passt, takten wir Projekte in Demo-Zyklen. In einem Rhythmus je nach Projekt, etwa wöchentlich oder alle zwei Wochen, sehen Sie funktionierende Software, je nach Vertrag auf einer eigenen Staging-Umgebung, können klicken, Fragen stellen, Richtung korrigieren. Kein Burndown-Theater, keine Velocity-Folien. Was Sie sehen, ist auch das, was schon läuft.
Kadenz statt Kalender-Tetris
Ein fester Demo-Rhythmus, je nach Projekt wöchentlich oder alle zwei Wochen, gibt Ihnen genug Reaktionszeit, ohne den Build zu erdrücken. Wir splitten Vorhaben so, dass jeder Zyklus etwas Klickbares produziert - und sei es nur ein Endpoint mit echter Datenbankantwort. Demos sind nie eine Powerpoint. Wenn etwas „demnächst“ funktioniert, sagen wir es offen.
Das stellt Disziplin auf unsere Seite, nicht auf Ihre. Sie müssen nicht die Scrum-Mechanik verinnerlichen. Sie müssen nur einmal pro Zyklus 30 Minuten Zeit haben, durchzuklicken und ehrlich Rückmeldung zu geben.
Entscheidungen statt Tickets
Wir messen Fortschritt in getroffenen Entscheidungen, nicht in geschlossenen Tickets. Eine Architektur-Frage, die im Demo-Zyklus geklärt wird, ist mehr wert als zwanzig abgehakte Karten. Das passt in keine Velocity-Tabelle - bringt aber die Projekte über die Ziellinie.
Eine ehrliche Beobachtung
Sprint-Reviews werden zur Bühne, wenn niemand mehr eine ehrliche Demo sehen will. Demo-Zyklen funktionieren, weil sie ohne Vokabular auskommen, das Kunden lernen müssten.
Differenzierung
Wann Sprints trotzdem das richtige Werkzeug sind
Wir sind keine Scrum-Gegner. Wir sind gegen Scrum als Default, ohne Frage nach dem Kontext. Es gibt Projekte, in denen Sprints wirklich tragen.
Mehr als zehn Entwickler in einem Produkt
Sobald ein Team aus mehreren parallel arbeitenden Squads besteht, braucht es eine harte Taktung, um Abhängigkeiten zu synchronisieren. Da entfalten klassische Sprints ihre Stärke: gemeinsamer Rhythmus, harte Cut-offs, Planning als Synchronisationspunkt. In Konzern-Settings mit 30, 50 oder 100 Entwicklern an einem Produkt ist Demo-zu-Demo nicht genug.
Regulierte Branchen und Audit-Spuren
In Banking, MedTech oder Energie brauchen Sie eine lückenlose Audit-Spur über Entscheidungen, Reviews und Abnahmen. Sprint-Artefakte erfüllen das aus der Box: Sprint-Goals, Reviews, Definitions of Done werden zu Compliance-Belegen. Wir würden auch im B2B-Mittelstand kein KRITIS-Projekt ohne dieses Gerüst aufsetzen.
Harte externe Deadlines
Wenn ein Messeauftritt, eine Produkteinführung oder eine Gesetzes-Deadline das Datum fixiert, braucht es eine Taktung, die Restkapazität sichtbar macht. Sprints liefern hier echten Wert: Burndown-Charts werden plötzlich relevant, weil das Sprintziel kein Theater ist, sondern ein verbindliches Versprechen.
Scrum-Setup in der Kritik?
Wenn Ihr Team gerade in Velocity-Diskussionen feststeckt: Wir lesen Ihr Setup gegen und sagen Ihnen, wo wir ansetzen würden.
Zwischenstand
Methodik ist Kontext, nicht Marke
Die ehrliche Frage ist nicht „Scrum oder Kanban oder SAFe“, sondern „welcher Rhythmus passt zu Teamgröße, Risikoprofil und Außenstellen-Anforderungen“. Bei zwei bis sechs Entwicklern, ohne harte Audit-Spur, ohne externe Fix-Deadline funktionieren Demo-Zyklen schlicht besser. Bei großen Teams oder regulierten Umfeldern bauen wir Sprints auf. Mit dem gleichen Ziel: weniger Theater, mehr lieferbares Ergebnis.
Drei Fragen vor der Methoden-Wahl
Wie viele Entwickler arbeiten gleichzeitig am Produkt? Wie hart ist die nächste externe Deadline? Welche Audit-Spur müssen Sie nach außen vorweisen? Diese drei Antworten entscheiden, ob Demo-Zyklen ausreichen oder Sprints nötig werden - nicht das Lieblings-Framework Ihres Beraters.
Was wir nie tun: Scrum auf Marketing-Teams aufpfropfen
Scrum stammt aus der Softwareentwicklung und passt schlecht auf jedes andere Setting. Marketing-Sprints, HR-Sprints, Sales-Sprints sind in der Mehrheit der Fälle Buzzword-Kostüme. Wenn Ihnen eine Agentur das verkauft: holen Sie eine zweite Meinung ein.
Artikel teilen
Wie taktet Ihr aktuelles Projekt?
Erzählen Sie uns kurz, wie Sie heute arbeiten. Wir antworten mit einer ehrlichen Einschätzung, wo Demo-Zyklen Aufwand sparen würden - und wo Sprints das richtige Werkzeug bleiben.