METHODE

Agile

Familie von Softwareentwicklungspraktiken, die kurze Iterationen, häufiges Kundenfeedback und Plananpassung gemäß realer Ergebnisse priorisiert.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Agile ist älter, als die meisten denken (das Manifest stammt aus 2001) und schlechter umgesetzt, als die meisten Teams zugeben. Der Ursprungsgedanke war simpel: weiter zu planen, als man vorhersagen kann, ist vergeudete Arbeit. Also: kurz planen, shippen, lernen, neu planen. Alles andere (Scrum, Kanban, SAFe, Sprints, Retros, Story Points) ist Implementierungsdetail obendrauf.

Die nützlichste Frage an ein Team, das sagt „wir machen Agile": Wann hat sich der Plan zuletzt aufgrund dessen geändert, was letzte Woche geshippt wurde? Lautet die Antwort nie, macht das Team Wasserfall in Zwei-Wochen-Häppchen.

Beispiel für den Unterschied: Zwei Teams fahren beide zweiwöchige Sprints. Team A demot, sieht, dass das Feature, das niemand auf der Roadmap vorhergesagt hat, das ist, das Nutzer tatsächlich anklicken, und ordnet den nächsten Sprint darum neu. Team B demot, notiert das Feedback in einem Doc und macht mit dem im Januar geschriebenen Plan weiter, weil der Plan der Plan ist. Team A ist agile. Team B hat agile Zeremonien und ein Wasserfall-Gehirn. Die Zeremonien sind identisch; nur die Bereitschaft, auf Evidenz zu handeln, unterscheidet sich, und das ist das ganze Spiel.

Der ehrliche Trade-off und der Founder-Fehler: Agile ist kein Freibrief, Planung zu überspringen, und es ist nicht gratis. Es tauscht Langhorizont-Vorhersehbarkeit gegen schnelles Lernen, was genau falsch ist, wenn Scope, Regulierung oder ein Interface-Vertrag wirklich nicht ändern können (zertifizierte Medizingeräte, Avionik, manche Hardware). Selbst dort gelten die ursprünglichen Prinzipien innerhalb des Teams; der nach außen sichtbare Prozess sieht nur mehr nach Wasserfall aus. Wavect ist agile im ursprünglichen Sinn: Wir arbeiten in kurzen Zyklen, demoen oft, lehnen uns auf CI/CD, damit Shippen billig ist, und sind bereit, Arbeit wegzuwerfen, die sich als falsch herausstellte. Wir sind skeptisch gegenüber der Zertifikatsindustrie-Version von Agile, bei der die Meeting-Kadenz zum Ziel wird und eine TDD-Suite zur Schau statt für Vertrauen geschrieben wird.

// FAQ

Häufige Fragen

Ob der Plan sich aufgrund der letzten Auslieferung ändert. Echtes Agile produziert verworfene Tickets und gestrichene Features, weil das Team etwas gelernt hat. Sprint-Theater produziert dieselbe Roadmap wie vor drei Monaten, nur in Zwei-Wochen-Häppchen verpackt.
Kein Framework rettet ein Team, das nicht lernen will. Kanban für kontinuierlichen Flow ohne Sprint-Zeremonie, Scrum für Teams, die Struktur brauchen, SAFe fast nie freiwillig. Wer SAFe aus Überzeugung wählt, hat meist mehr als 200 Engineers.
Ja, wenn der Scope eines Sprints fest ist und die Sprint-Reihenfolge flexibel bleibt. Wir machen das oft: Werkvertrag über Discovery-Output, dann sprint-basierte Auslieferung. Was nicht geht: agile als Ausrede für moving Scope ohne Change Request.