Work & Feedback: Warum du keine Frameworks, sondern Skills brauchst

Das Label „Agile“ ist verbrannt, das habe ich in meinem letzten Artikel bereits analysiert. Bedeutet das auch, dass "Agile" selber verbrannt ist? Nein! Wir müssen nur genauer hinsehen: Wenn wir den ganzen Ballast aus Rollenbeschreibung, Zertifizierungs-Zirkus, Jira-Workflows und bunten Post-its wegschmeißen, was bleibt dann übrig? 

Es sind genau zwei Wörter: Work und Feedback.

Das ist der gesamte Kern. Agiles Arbeiten ist kein Hexenwerk, es ist ein gnadenlos ehrlicher Kreislauf: In kurzen Zyklen etwas Funktionierendes bauen, echtes Feedback einholen und den Kurs anpassen. Mehr ist es nicht. Aber genau hier liegt das Problem: Die meisten Unternehmen beherrschen diesen Kern nicht – und verstecken ihr Unvermögen hinter 500-seitigen Framework-Handbüchern.

Das Märchen vom „Wir können nicht öfter releasen“

Wenn ich online über dieses Thema rede, bekomme ich folgendes immer wieder als Antwort.

Thomas, das klingt ja nett mit dem Feedback. Aber wir sind ein Enterprise-Umfeld. Wir können technisch nur alle drei Monate releasen. Unsere Architektur lässt das nicht anders zu.

Meine Antwort ist hart, aber ehrlich: Das ist eine Lüge.

Es ist keine gottgegebene Gesetzmäßigkeit, dass Software drei Monate bis zum Kunden braucht. Es ist die Entscheidung, nicht in das notwendige Handwerk zu investieren. Wer sagt „ich kann nicht öfter releasen“, meint eigentlich: „Wir haben Angst vor unserem eigenen Code.“ (ja, es gibt Ausnahmen wie z.B. gesetzliche Vorgaben...)

Wir müssen aufhören, Agilität als Management-Methode zu diskutieren. Wir müssen anfangen, sie als Handwerk zu begreifen.

Die Skill-Lücke hinter dem Prozess-Vorhang

Warum dauert es drei Monate? Weil das manuelle Testing Wochen frisst. Weil das Deployment ein Hochseilakt ohne Netz ist. Weil niemand weiß, was passiert, wenn man an Modul A zieht, während Modul B noch am seidenen Faden hängt. Weil es keine gute Planung und Story-Zerlegung gibt.

Wenn dein Umfeld komplex ist – und das ist es meistens, sonst bräuchtest du kein agiles Arbeiten –, dann ist der einzige Weg zur Risikominimierung die Verkleinerung der Einheiten.

Wenn deine Stories und damit deine Iterationen zu groß sind, steigt dein Risiko exponentiell, etwas zu entwickeln, dass der Kunde gar nicht braucht. Kommt das Feedback zu spät, baust du drei Monate lang am Markt vorbei. Das wird alles sehr teuer.

Um diesen Teufelskreis zu durchbrechen, brauchen wir keine neuen Meetings, sondern technische Exzellenz. Testing, CI/CD, Feature Flags und Decoupled Architectures sind keine „nice-to-have“ Entwickler-Spielereien. Sie sind die Grundvoraussetzung dafür, dass das Wort „Agil“ überhaupt eine Bedeutung hat. Und glaub mir, bei den Devs rennst du damit offene Türen ein. Wahrscheinlich habe sie das sogar schon lange gefordert oder hinter vorgehaltener Hand (in der Retro) diskutiert.

Wer nicht schnell releasen kann, kann nicht schnell lernen. Wer nicht schnell lernt, arbeitet nicht agil. Er macht nur Wasserfall in teuren Sprints.

Die gute Nachricht: Man kann es lernen

Das Schöne an dieser Erkenntnis ist: Fehlende Skills sind kein Schicksal. Man kann daran arbeiten!

Wenn du merkst, dass dein Feedback-Zyklus zu langsam ist, dann ist das dein wichtigstes Backlog-Item. Vergiss das nächste Feature. Kümmere dich darum, dass aus den drei Monaten drei Wochen werden. Dann drei Tage. Das klingt teuer? Ist es auch! Aber etwas zu entwickeln, dass drei Monate braucht, bis es released ist und dann nicht das erfüllt, was die User eigentlich haben wollten, ist noch teurer.

Diese Schritte erfordern harte Arbeit am System und am eigenen Können.

Du musst lernen, Aufgaben besser schneiden zu können. Wenn ein Feature zu groß für ein schnelles Release ist, hast du es falsch geschnitten. Es gibt immer einen kleineren, wertstiftenden Teil.

Du must lernen, zu automatisiere. Jedes manuelle Testing ist eine Bremse für deine Agilität. Entkopple das Release vom Deployment: Mit Feature Flags kannst du Code live bringen, ohne ihn sofort für alle scharf zu schalten. Das nimmt den Druck und erhöht die Feedback-Geschwindigkeit.

Es gibt viele weitere Methoden und Herangehensweisen, um Features klein zu bekommen. Ich habe ein paar in dem Artikel Backlog Refinement Technik: Tickets schneiden wie ein Pro angesprochen. 

Fazit: Fokus auf den Kern

Egal, ob auf deiner Visitenkarte Product Owner, CTO, Tech Lead, Scrum Master, Release Train Engineer oder Agile Coach steht: Deine Aufgabe ist es nicht, Zeremonien zu moderieren. Deine Aufgabe ist es, den Weg für Iteration und Feedback frei zu machen.

Wenn du in einem komplexen Umfeld arbeitest, ist der Overhead von agilem Arbeiten (die Meetings, das Kleinschneiden, die Abstimmung) nur dann gerechtfertigt, wenn du die PS auch auf die Straße bringst.

Hör auf, dich hinter Frameworks wie SAFe, Scrum oder Kanban zu verstecken. Schau dir deinen Feedback-Zyklus an. Ist er zu lang? Dann arbeite an deinen Skills, statt nach neuen Methoden zu rufen.

Agiles Arbeiten ist Handwerk. Und 2026 ist das Jahr, in dem wir endlich wieder anfangen zu bauen.