Ein Kunde fragte mich letztens, ob er „endlich Scrum einführen" solle. Meine Gegenfrage: Was genau soll dadurch besser werden? Darauf hatte er keine klare Antwort – und das ist typisch. Scrum-Literatur wird meist für Teams geschrieben, die komplett anders aufgestellt sind als ein Mittelständler mit zwei Entwicklern und einer Agentur im Boot. Der Unterschied zwischen beiden Welten ist größer, als die meisten Bücher zugeben.
Warum Scrum nach Lehrbuch im Mittelstand oft scheitert
Scrum wurde für Teams entwickelt, die sich vollständig einem Produkt widmen können: ein dedizierter Product Owner, ein stabiles Entwicklungsteam, feste Sprints, ein Scrum Master der nichts anderes tut. Im Mittelstand trifft das selten zu. Der „Product Owner" ist oft die Geschäftsführerin, die nebenbei noch den Vertrieb verantwortet. Das „Entwicklungsteam" besteht aus zwei internen Entwicklern und einer externen Agentur, die nicht im selben Daily sitzt. Und ein Sprint von zwei Wochen wirkt lang, wenn ein Kunde morgen eine Antwort braucht.
Wird Scrum trotzdem 1:1 übernommen, entsteht ein Ritual-Theater: Dailys, bei denen niemand wirklich blockiert ist, weil ohnehin alle den ganzen Tag im selben Büro sitzen. Sprint Reviews ohne echte Stakeholder, weil die Geschäftsführung gerade beim Kunden ist. Retrospektiven, die dieselben drei Punkte wiederholen, weil niemand die Kapazität hat, sie umzusetzen. Das Framework wird zur Pflichtübung – und verliert genau den Nutzen, für den es eigentlich gedacht war.
Was im Mittelstand tatsächlich funktioniert
Die Unternehmen, bei denen Agilität wirklich trägt, haben sich das Framework angepasst – umgekehrt habe ich es selten erlebt. Vier Elemente sehe ich dabei immer wieder, egal ob am Ende Scrum draufsteht oder gar kein Name:
Ein sichtbarer, priorisierter Backlog
Nicht zwingend in Jira – auch ein gepflegtes Kanban-Board reicht. Entscheidend ist: Es gibt eine einzige Quelle der Wahrheit, was als Nächstes kommt, und jemand trifft diese Priorisierung verbindlich.
Kurze, verlässliche Feedback-Zyklen
Wöchentliches Review, rollierendes Kanban statt fixer Sprints, was auch immer – die Taktung nach Lehrbuch ist zweitrangig. Ergebnisse müssen regelmäßig sichtbar und abnehmbar sein, mehr nicht.
Eine klar benannte Entscheidungsinstanz
Wenn Anforderungen widersprüchlich sind, muss eine Person entscheiden dürfen – nicht das ganze Führungsteam per E-Mail-Kette. Diese Rolle ist wichtiger als jeder Zeremonien-Kalender.
Retrospektiven mit echten Konsequenzen
Seltener, dafür mit verbindlichen Maßnahmen. Eine Retro alle vier Wochen mit zwei umgesetzten Verbesserungen bringt mehr als zehn Retros ohne Wirkung.
Scrum, Kanban oder Hybrid – was passt wann?
Scrum eignet sich, wenn ein Team über längere Zeit an einem klar abgegrenzten Produkt arbeitet und genug Kapazität hat, die Rollen (Product Owner, Scrum Master, Entwicklungsteam) tatsächlich zu besetzen – etwa bei einer internen App-Entwicklung mit festem Team.
Kanban passt besser, wenn Anfragen unregelmäßig eintreffen und Prioritäten sich häufig verschieben – typisch für IT-Teams im Mittelstand, die parallel Support, kleine Projekte und strategische Vorhaben stemmen. Der Flow-Fokus von Kanban bildet diese Realität ehrlicher ab als starre Sprints.
Hybrid-Modelle sind in der Praxis am häufigsten: ein Kanban-Board für den laufenden Betrieb, kombiniert mit Sprint-artigen Zyklen für klar abgegrenzte Projektphasen. Kein Framework aus dem Lehrbuch, aber meist das, was tatsächlich funktioniert.
Bei einem Telekommunikationskonzern habe ich Scrum in einem international verteilten Team mit klar getrennten Rollen erlebt – funktionierte, weil Kapazität und Struktur dafür da waren. In einem Mittelstandsprojekt mit zwei internen Entwicklern und einer Agentur wäre dasselbe Setup gescheitert: Ich habe stattdessen ein einfaches Kanban-Board mit wöchentlichem Review eingeführt, ohne Sprint-Zwang, mit einer klar benannten Entscheiderin. Ergebnis: Die Priorisierung wurde erstmals für alle sichtbar, und Entscheidungen fielen innerhalb von Tagen statt Wochen.
Die drei häufigsten Fehler bei der Einführung
-
Framework vor Problem „Wir führen jetzt Scrum ein" ist die falsche Reihenfolge. Die richtige Frage lautet: Welches konkrete Problem soll Agilität lösen – unklare Prioritäten, fehlende Transparenz, zu langsame Entscheidungen? Erst danach folgt die Methode.
-
Rollen ohne Kapazität besetzen Ein Product Owner, der die Rolle „nebenbei" ausfüllt, priorisiert nicht – er reagiert nur noch. Ohne echte Kapazität für Backlog-Pflege und Entscheidungen bleibt jedes Framework Theater.
-
Zeremonien ohne Anpassung übernehmen Nicht jedes Team braucht ein tägliches 15-Minuten-Standup oder zweiwöchige Sprints. Wenn eine Zeremonie nach drei Monaten noch immer wie eine Pflichtübung wirkt, ist sie falsch dimensioniert – nicht das Team.
Wie eine agile Einführung im Mittelstand realistisch gelingt
Was in der Praxis am besten funktioniert: klein anfangen, mit einem einzigen Element. Ein sichtbarer Backlog und eine klar benannte Entscheidungsinstanz lösen oft schon den Großteil der eigentlichen Probleme, lange bevor die erste Retrospektive stattfindet. Erst wenn dieses Fundament trägt, lohnt es sich, weitere Elemente wie feste Zyklen oder Schätzverfahren zu ergänzen.
Bei einem Digital Assessment ist das oft der erste Befund: nicht ein fehlendes Framework ist das Problem, sondern ein einzelnes fehlendes Element darin – meistens die Priorisierung oder die Entscheidungsinstanz.
Fazit
Agile Methoden funktionieren im Mittelstand – nur selten in der Form, wie sie in Konzernen oder Lehrbüchern beschrieben werden. Wie nah eine Organisation am Scrum Guide arbeitet, sagt wenig darüber aus, ob sie gut aufgestellt ist. Was zählt, ist ob Backlog, Priorisierung und Entscheidungswege tatsächlich funktionieren. Das schafft ein Zwei-Personen-Team mit einem Kanban-Board genauso wie ein vollständiges Scrum-Setup.
Wenn Sie unsicher sind, welches Modell zu Ihrem Team passt – oder ob eine bestehende agile Einführung gerade zum Ritual-Theater wird, ohne dass jemand es ausspricht: Das ist eine Frage, die sich in einem Erstgespräch meist schnell einordnen lässt.
Scrum, Kanban oder Hybrid – welches Modell zu Ihrem Team passt, lässt sich in 30 Minuten klären. Ohne Verkaufsdruck, mit einer ehrlichen Einschätzung.