Agile Softwareentwicklung: Scrum, Kanban & Co. erklärt
Wer Software beauftragt, trifft unweigerlich auf Sprints, Backlogs und Dailys. Die Begriffe klingen nach Methodenfolklore, dahinter steckt aber eine schlichte Frage: Legen Sie den gesamten Umfang vorab fest und bekommen ihn am Ende – oder arbeiten Sie in kurzen Abständen und entscheiden unterwegs nach, was als Nächstes entsteht? Dieser Artikel erklärt, wie die gängigen Verfahren funktionieren, wann das klassische Vorgehen trotzdem die bessere Wahl ist und was agile Zusammenarbeit konkret für Ihr Budget und Ihren Vertrag bedeutet.
Der Kern: warum es Agilität überhaupt gibt
Das klassische Vorgehen – erst alles spezifizieren, dann bauen, dann testen, dann abnehmen – setzt eine Annahme voraus: dass am Anfang bekannt ist, was gebraucht wird. Bei einer Brücke trifft das zu. Bei Software fast nie.
Die Erfahrung dahinter ist banal und doch entscheidend: Anforderungen ändern sich, weil Menschen erst beim Benutzen merken, was sie wirklich brauchen. Eine Spezifikation, die acht Monate vor der Nutzung geschrieben wurde, beschreibt nicht das Produkt, sondern eine Vermutung darüber.
Das Agile Manifest von 2001 hat daraus vier Prioritäten formuliert. Es stellt nicht die eine Seite gegen die andere, sondern sagt, was im Konflikt vorgeht:
Der am häufigsten überlesene Satz: Im Original steht ausdrücklich, dass die Punkte auf der rechten Seite Wert haben – Dokumentation, Verträge und Pläne also nicht abgeschafft, sondern nachgeordnet werden. Wer Agilität als Erlaubnis liest, ohne Plan zu arbeiten, hat das Gegenteil verstanden. Das ist in der Praxis die verbreitetste Fehldeutung und die Hauptquelle für gescheiterte agile Projekte.
Scrum im Detail
Scrum ist das verbreitetste Rahmenwerk – in Umfragen nutzen es rund 87 Prozent der Unternehmen, die überhaupt agil arbeiten. Es besteht aus drei Rollen, fünf Terminen und drei Artefakten. Mehr nicht; alles andere sind Ergänzungen.
Die drei Rollen
| Rolle | Verantwortet | Entscheidet über |
|---|---|---|
| Product Owner | den Wert des Produkts | Reihenfolge und Inhalt des Backlogs |
| Scrum Master | dass das Verfahren wirkt und Hindernisse wegkommen | nichts fachlich, alles prozessual |
| Entwicklungsteam | das fertige Ergebnis pro Sprint | Umsetzung, Technik, Aufwand |
Die wichtigste Eigenschaft dieser Aufteilung: Der Product Owner entscheidet, was gebaut wird, das Team entscheidet, wie viel in einen Sprint passt. Wer beides in einer Hand bündelt, hat kein Scrum, sondern Projektleitung mit anderen Begriffen.
Für Sie als Auftraggeber ist die Rolle des Product Owners die entscheidende. Sie gehört auf Ihre Seite – es ist die Person, die Prioritäten setzen und fachliche Fragen innerhalb von Stunden beantworten darf. Diese Besetzung ist der häufigste Grund, warum agile Projekte mit externen Dienstleistern stocken: nicht fehlende Methodenkenntnis, sondern ein Product Owner, der nur einen halben Tag pro Woche Zeit hat.
Die Termine
Die Artefakte
Woran Scrum in der Praxis scheitert: Nicht an den Terminen, sondern an drei Punkten – ein Product Owner ohne Entscheidungsbefugnis, Sprints, in die laufend Dringendes hineingedrückt wird, und eine Definition of Done, die Tests und Dokumentation auslässt. Alle drei erzeugen das Muster, das als „wir machen Scrum, aber es funktioniert nicht“ bekannt ist.
Kanban im Vergleich
Kanban stammt aus der Fertigung und verfolgt ein anderes Prinzip: kein Takt, sondern kontinuierlicher Fluss. Es gibt keine Sprints, keine festen Rollen und keine Schätzungen als Pflichtbestandteil. Stattdessen drei Regeln:
| Scrum | Kanban | |
|---|---|---|
| Takt | feste Sprints, 1 bis 4 Wochen | kontinuierlich, kein Takt |
| Rollen | drei definierte Rollen | keine vorgeschrieben |
| Planung | pro Sprint, Umfang festgelegt | laufend, Priorität beim Nachziehen |
| Änderungen mitten im Lauf | gehen in den nächsten Sprint | jederzeit möglich |
| Zentrale Kennzahl | Velocity pro Sprint | Durchlaufzeit und Work in Progress |
| Passt für | Produktentwicklung mit planbarem Umfang | Wartung, Support, Betrieb, unregelmäßiger Eingang |
Die praktische Entscheidungsregel: Scrum, wenn Sie etwas aufbauen. Kanban, wenn Sie etwas betreiben. Ein Team, das neue Funktionen entwickelt, profitiert vom Rhythmus und von geschützten Sprints. Ein Team, das Störungen bearbeitet und auf Zuruf reagiert, kann Sprints gar nicht einhalten – dort erzeugt Scrum nur Frust über gebrochene Zusagen.
In der Praxis sind Mischformen der Normalfall: Scrum als Grundgerüst, dazu Work-in-Progress-Limits und Durchlaufzeitmessung aus Kanban. Umfragen zufolge arbeiten rund drei Viertel der Organisationen bewusst hybrid – und das gilt inzwischen nicht mehr als Abweichung, sondern als die ausgereiftere, an den Kontext angepasste Form.
Wann Wasserfall die richtige Wahl bleibt
Agilität ist kein Selbstzweck, und es gibt Situationen, in denen das klassische Vorgehen klar besser passt:
Die ehrliche Zwischenform: Viele Projekte funktionieren am besten als abgestufte Festlegung. Der Rahmen – Ziel, Architektur, Budget, Meilensteine – wird klassisch vereinbart. Innerhalb dieses Rahmens wird iterativ gearbeitet und priorisiert. Sie bekommen damit Planungssicherheit auf der Ebene, auf der Sie sie brauchen, und Flexibilität auf der Ebene, auf der sie etwas wert ist.
Was agile Zusammenarbeit für Ihre Beauftragung bedeutet
Hier wird das Thema konkret. Wenn Sie einen Freelancer oder eine Agentur agil beauftragen, ändern sich vier Dinge.
Der Vertrag beschreibt ein Verfahren, nicht nur ein Ergebnis
Ein reiner Festpreis auf einen vagen Umfang ist für beide Seiten schlecht: Der Anbieter rechnet Risiko ein, Sie zahlen es, und jede Änderung wird zur Nachtragsverhandlung. Die verbreiteten Alternativen:
| Modell | Funktionsweise | Passt wenn |
|---|---|---|
| Festpreis | fester Umfang, fester Preis | Umfang ist wirklich klar und stabil |
| Aufwand nach Zeit | abgerechnet wird geleistete Arbeit | Umfang entwickelt sich, Vertrauen ist da |
| Budgetrahmen mit Priorisierung | Budget und Termin fix, Umfang variabel | der Normalfall bei Produktentwicklung |
| Sprint-Kontingent | feste Anzahl Sprints zu festem Preis | planbare Zusammenarbeit über Monate |
Das dritte Modell ist in der Praxis das tragfähigste. Budget und Termin stehen – das brauchen Sie für Ihre Planung. Verhandelbar bleibt, was innerhalb dieses Budgets zuerst gebaut wird, und darüber entscheiden Sie in jedem Sprint neu. Das verlagert die Verantwortung für Priorisierung dorthin, wo das Fachwissen sitzt.
Sie werden gebraucht
Das ist die unbequeme Seite. Agil arbeiten heißt, dass alle ein bis zwei Wochen jemand von Ihrer Seite Entscheidungen trifft und Rückmeldung gibt. Planen Sie dafür realistisch Zeit ein – erfahrungsgemäß einen halben bis einen Tag pro Woche für die Rolle des Product Owners. Wer diese Zeit nicht hat, sollte bewusst klassisch beauftragen, statt agil zu beauftragen und dann nicht erreichbar zu sein.
Sie sehen früher, ob es passt
Der größte Vorteil: Nach vier bis sechs Wochen gibt es etwas Benutzbares. Das ist der Zeitpunkt, an dem sich zeigt, ob die Zusammenarbeit funktioniert und ob das Produkt in die richtige Richtung geht – und es ist früh genug, um zu korrigieren oder auszusteigen. Beim klassischen Vorgehen erfahren Sie das nach der Hälfte des Budgets.
Transparenz ist beidseitig
Sie sehen jeden Sprint, was entstanden ist. Umgekehrt sehen Sie auch, wenn weniger entstanden ist als geplant – und müssen damit umgehen können, ohne dass daraus eine Schuldfrage wird. Ein Team, das schlechte Nachrichten früh melden kann, ist wertvoller als eines, das bis zum Abgabetermin zuversichtlich bleibt.
Praktischer Hinweis zur Anbieterauswahl: Fragen Sie nicht, ob agil gearbeitet wird – das bejaht jeder. Fragen Sie: Wie lang sind die Sprints? Was bekomme ich am Ende des ersten Sprints zu sehen? Was steht in Ihrer Definition of Done? Was passiert, wenn ein Sprint nicht fertig wird? Die Antworten unterscheiden Methodenkenntnis von Methodenvokabular.
Die Realität in Deutschland
Zur ehrlichen Einordnung: Zwischen Anspruch und Praxis liegt eine messbare Lücke. Eine Untersuchung der Hochschule Karlsruhe mit 655 Unternehmen aus 16 Ländern sieht Deutschland beim Einsatz agiler Methoden auf dem letzten Platz – 45 Prozent gegenüber 88 Prozent in China. Studien von Ayelt Komus zeigen, dass nur etwa ein Fünftel der Projekte durchgängig agil läuft; es dominieren Mischformen, in denen Dailys und Backlogs in klassische Projekte eingestreut werden.
Dazu kommt ein Führungsproblem: In Erhebungen beteiligen sich nur rund 15 Prozent der Führungskräfte aktiv an der Ausgestaltung agiler Praktiken, während drei Viertel der Manager unter Druck stehen, deren wirtschaftlichen Nutzen zu belegen.
Was folgt daraus für Sie? Nicht, dass Agilität nicht funktioniert – sondern dass die Methode nicht das Problem löst, das viele erwarten. Sprints ersetzen keine Entscheidungsfähigkeit. Wenn Prioritäten im Unternehmen nicht geklärt werden können, macht Scrum das nur schneller sichtbar.
Fazit
Agile Softwareentwicklung ist kein Glaubensbekenntnis, sondern eine Antwort auf eine schlichte Beobachtung: Bei Software weiß man am Anfang nicht genug, um alles vorab festzulegen. Scrum gibt dem einen Rahmen mit drei Rollen, fünf Terminen und drei Artefakten; Kanban verzichtet auf den Takt und optimiert den Fluss – Scrum fürs Aufbauen, Kanban fürs Betreiben, Mischformen als Normalfall. Für Ihre Beauftragung heißt agil vor allem zwei Dinge: Budget und Termin können fest sein, der Umfang sollte verhandelbar bleiben – und Sie brauchen eine entscheidungsbefugte Person mit Zeit. Wenn Sie beides nicht haben, ist ein klar spezifiziertes Festpreisprojekt die ehrlichere Wahl. Wie ein erstes Vorhaben zugeschnitten wird, beschreibt der Artikel MVP entwickeln.