Methodik ist die oberste Schicht

Software-Delivery-Praktiken bilden einen Stack mit drei Schichten, und die meisten Teams versuchen, sie in der falschen Reihenfolge einzuführen.

Schicht 1: Grundlagen. Versionskontrolle, Arbeitserfassung, Absichtskommunikation, Schätzgewohnheiten und Nachvollziehbarkeit. Das sind die Praktiken, die dieser Kurs abdeckt. Sie sind methodik-agnostisch — ein Scrum-Team und ein Kanban-Team brauchen sie beide, und sie sehen in beiden Kontexten fast identisch aus.

Schicht 2: Methodik. Scrum, Kanban, XP oder ein Hybrid. Hier wählst du eine Kadenz (Sprints oder kontinuierlicher Fluss), definierst Rollen (oder entscheidest dich explizit dagegen) und führst Zeremonien ein (Standups, Retrospektiven, Planungssitzungen). Methodik gibt einem Team Rhythmus und Struktur — aber sie setzt voraus, dass die Grundlagen bereits vorhanden sind.

Schicht 3: Skalierung. SAFe, LeSS, Lean Portfolio Management oder selbstentwickelte Koordinationsmuster. Diese Schicht ist nur wichtig, wenn mehrere Teams die Lieferung koordinieren müssen. Sie setzt voraus, dass sowohl Grundlagen als auch Methodik auf Team-Ebene funktionieren.

Der Stack ist wichtig, weil jede Schicht von der darunter abhängt. Ein Team, das Scrum ohne solide Arbeitserfassung betreibt, wird die Hälfte jeder Sprint-Planungssitzung damit verbringen, wiederzuentdecken, was läuft. Eine Organisation, die SAFe ohne funktionierende Team-Retrospektiven einführt, wird Dysfunktion skalieren, nicht Lieferung.

Die meisten „agilen Transformationen" scheitern, weil sie bei Schicht 2 oder 3 beginnen. Sie kaufen ein Tool, stellen einen Coach ein, benennen Meetings um — und fragen sich dann, warum sich die Velocity nicht verbessert. Die Antwort ist fast immer dieselbe: Die Grundlagen waren nicht da.

Jede Methodik setzt voraus, dass du bereits die Basics hast. Scrum setzt voraus, dass du Arbeit in einem Backlog erfassen, Code in ein gemeinsames Repository committen und Aufwand mit genug Konsistenz schätzen kannst, um einen Sprint zu planen. Kanban setzt voraus, dass du Arbeitselemente visualisieren, Cycle Time messen und ein Ticket von der Anfrage bis zur Lieferung nachverfolgen kannst. XP setzt voraus, dass du Tests schreiben, Code reviewen und häufig deployen kannst.

Keine dieser Annahmen wird in den Methodik-Leitfäden genannt, weil die Autoren sie für selbstverständlich hielten. Aber für viele Teams sind sie nicht selbstverständlich — sie sind aspirativ. Und wenn ein Team eine Methodik ohne die Grundlagen einführt, wird die Methodik zum Theater: Die Zeremonien finden statt, die Artefakte existieren, aber die Ergebnisse ändern sich nicht.

Du hast das gesehen. Das Team, das Sprint-Planung durchführt, aber nicht beantworten kann „wozu haben wir uns letzten Sprint verpflichtet?", weil die Tickets nicht aktualisiert wurden. Das Team, das Daily Standups macht, aber keinen Fortschritt teilen kann, weil die Hälfte der Arbeit nicht erfasst ist. Das Team, das Retrospektiven abhält, aber nicht auf die Erkenntnisse reagieren kann, weil es kein System gibt, um Aktionselemente zuzuweisen und nachzuverfolgen.

Die Lösung ist nicht, Methodik aufzugeben. Die Lösung ist, zuerst die Grundlagen richtig hinzubekommen und dann Methodik darauf aufzubauen. Das ist die Reihenfolge, der dieser Kurs folgt: Module 2–4 decken die Grundlagen ab (Versionskontrolle, Tickets, Schätzung), und Modul 5 hilft dir, zu wählen, welche Methodik — falls überhaupt — du einführst, sobald das Fundament solide ist.