Agiles Arbeiten bei Moselwal

Wir arbeiten seit dem ersten Tag agil — nicht weil es im Pitch gut klingt, sondern weil die Arbeit, die wir machen, im Wasserfall nicht gut funktioniert. In diesem Beitrag beschreibe ich, wie agile Praxis bei Moselwal konkret aussieht: was wir aus dem Lehrbuch übernommen haben, wo wir bewusst abgewichen sind und welche Spannungen die Methode in einer Agentur-Konstellation auslöst.

Was wir konkret machen

Wir arbeiten mit einem Scrum-Kanban-Hybrid. Pro Kundenprojekt ein Team von drei bis sechs Personen, Sprints von zwei Wochen, eine klar definierte Rolle für Product Ownership, ein Tech-Lead pro Plattform. Was wir aus Kanban dazugeholt haben: Work-in-Progress-Limits pro Spalte, ein laufender Fluss statt strikter Sprint-Grenzen für kleinere Bug-Fix- und Support-Tasks, und eine ehrliche Cycle-Time-Messung statt nur Story-Point-Velocity.

Die Werkzeuge sind GitLab für Code, Issues und CI, Notion für längere Konzept-Dokumente, Slack für die laufende Kommunikation. Wir nutzen kein separates Jira oder Azure DevOps — die Konsolidierung auf GitLab-Issues hat in den letzten Jahren mehr Reibung weggenommen als jedes weitere Tool sie ersetzt hätte.

Wo wir mit reinem Scrum gebrochen haben

Reines Scrum nach dem 2020er Scrum-Guide war für uns nie das richtige Setup. An drei Stellen weichen wir bewusst ab.

Daily Standups sind asynchron. Statt eines 15-Minuten-Calls jeden Morgen schreibt jede Person in einem Slack-Thread drei Zeilen: was gestern, was heute, wo blockiert. Wer ein Thema synchron klären will, hängt einen Call an. Das spart pro Team und Woche knapp eine Stunde, kostet aber Disziplin in der Schriftform.

Sprint-Reviews kombinieren wir mit Refinement. Das klassische Demo-Format am Sprint-Ende wird in unserer Agentur-Konstellation selten effizient: Kunden haben oft nicht die Zeit, parallel zur Refinement-Sitzung in der Folgewoche zu sitzen. Wir bündeln die beiden Termine zu einer 90-Minuten-Session direkt am Sprint-Übergang.

Story Points sind bei uns optional. Wir schätzen, wo es Sinn ergibt — bei größeren Brocken, bei wirklich unklaren Tickets. Bei kleinen, klar geschnittenen Aufgaben sparen wir das Schätzen und arbeiten direkt mit Cycle Time als Maßzahl. Das ist nicht „No Estimates“, aber es ist ein klarer Bruch mit dem „alles muss eine Zahl haben“-Reflex.

Backlog als Diskussions-Werkzeug, nicht als Wunschliste

Ein Backlog ist nur dann nützlich, wenn er als Diskussions-Werkzeug verstanden wird, nicht als langer Wunschzettel mit Tickets aus drei Jahren. Wir halten unsere Backlogs aktiv klein: Was nicht in den nächsten zwei bis drei Sprints umgesetzt wird, gehört nicht in den Backlog, sondern in eine separate Ideen-Liste mit weniger formellem Status.

Praktisch heißt das: ein „Backlog-Frühjahrsputz“ alle zwei Quartale, in dem alle Tickets älter als drei Monate entweder priorisiert, präzisiert oder geschlossen werden. Geschlossene Tickets sind nicht verloren — sie sind nur explizit als „nicht in diesem Halbjahr“ markiert. Diese Disziplin verhindert, dass der Backlog zu einer demotivierenden Geisterbahn aus offenen Karten wird, die niemand mehr ernst nimmt.

Sprint-Rhythmus und Outcome-Fokus

Zwei-Wochen-Sprints sind bei uns die Default-Länge. Längere Sprints geben Raum für tiefere Arbeit, machen aber das Feedback-Loop zum Kunden zu lang; kürzere Sprints zerschneiden die Arbeit unnötig. Zwei Wochen sind der Kompromiss, mit dem wir am wenigsten Reibung haben.

Wichtiger als die Länge ist das Sprint-Ziel. Ein Sprint hat bei uns nicht „drölfzig Tickets, die zufällig zusammen passen“, sondern ein klar formuliertes Ergebnis: „Am Sprint-Ende kann der Kunde X mit der Plattform tun, was er vorher nicht konnte.“ Diese Outcome-Formulierung kommt aus dem 2020er Scrum-Guide und ist eine der besseren Korrekturen am ursprünglichen Format. Wer ein Sprint-Ziel nicht in einem Satz hinbekommt, hat ein Refinement-Problem, kein Velocity-Problem.

Retros, die wirklich etwas verändern

Retrospektiven sind der Punkt, an dem viele agile Teams scheitern. Nicht weil sie keine machen, sondern weil sie immer dieselbe machen — „was war gut, was war schlecht, was nehmen wir mit“ — bis niemand mehr ernsthaft mitmacht. Wir variieren das Format bewusst: Mal die klassische „Mad/Sad/Glad“-Runde, mal ein „5 Whys“ auf das wichtigste Problem, mal eine „Fun/Done/Learned“-Runde, mal ein „Pre-Mortem“ für den nächsten Sprint.

Wichtiger als das Format ist die Konsequenz. Aus jeder Retro entsteht maximal ein neuer Punkt, der konkret im nächsten Sprint umgesetzt wird — als eigenständiges Ticket im Backlog, mit Owner und Definition of Done. Eine Retro ohne diesen Ticket-Output ist eine schöne Diskussion ohne Wirkung.

Agile in einer Agentur-Konstellation

Agile Methodik gerät in einer Agentur an drei Stellen in Spannung, die im internen Produkt-Setup nicht so existieren.

Festpreis vs. iteratives Lernen. Klassische Festpreis-Angebote setzen voraus, dass Umfang und Lösung am Anfang feststehen — das Gegenteil von dem, was agile Arbeit fördert. Wir arbeiten deshalb wo immer möglich nach Time-and-Material oder mit „Festpreis pro Sprint“-Modellen. Bei klassischen Festpreis-Projekten ziehen wir vor der Implementierung eine Discovery-Phase mit klar abgegrenztem Umfang vor.

Kunden-Stakeholder im Sprint. Ein voll engagierter Product Owner auf Kundenseite ist die Ausnahme, nicht die Regel. Wir gehen damit um, indem wir einen unserer Senior-Konzeptioner als interimsweisen Co-PO einsetzen, der die fachliche Brücke zum Kunden hält. Das ist teurer als ein engagierter Kunden-PO — aber es funktioniert, während die Theorie scheitert.

Mehrere parallele Kunden im Team. Anders als ein internes Produktteam arbeitet ein Agentur-Team selten an genau einem Projekt zur Zeit. Wir haben das gelöst, indem wir Teams stabil halten und Projekte als „primärer Fokus“ und „sekundärer Fokus“ pro Sprint zuweisen. Ein Team arbeitet 70 Prozent auf einem Hauptprojekt und 30 Prozent auf einem kleineren Begleitprojekt. Das ist kein perfektes Setup, aber besser als unkontrolliertes Multi-Tasking.

Was wir bewusst nicht machen

Drei Praktiken, die im agilen Diskurs verbreitet sind, machen wir nicht.

Kein SAFe. Skalierungs-Frameworks wie SAFe sind für unsere Team-Größen oversized. Wir sind keine 200-Personen-Organisation, und das Tooling, das SAFe mitbringt, würde mehr Overhead erzeugen als Wert.

Kein Story-Point-Tracking als KPI. Velocity als Team-Metrik ist sinnvoll, Velocity als Ziel ist toxisch. Sobald Velocity als Performance-Indikator verhandelt wird, verlieren Story Points ihre Bedeutung — Teams schätzen größer, um schneller zu wirken. Wir nutzen Velocity zur Planung, nie zur Bewertung.

Kein „agiles Manifest“ an der Wand. Wir haben kein Poster, kein Glossar, keine „agile coach“-Rolle. Agilität ist bei uns eine Arbeitsweise, kein Ritual. Die Methode hat sich bewährt, weil wir sie laufend anpassen — nicht weil wir sie dogmatisch verteidigen.

Fazit

Agile Methodik ist für uns Werkzeug, nicht Identität. Wir nutzen das, was funktioniert, und lassen das weg, was Overhead produziert. Wer agil sagt und Wasserfall meint, hat ein Problem; wer agil sagt und Zeremonie meint, auch. Was bleibt, ist eine Arbeitsweise, die Lernen über drei Sprints hinweg ermöglicht, ohne dass jeder Sprint eine eigene Methodendiskussion auslöst.