Agile Ways of Working at Moselwal
How agile methods strengthen team cohesion and deliver results.
We have worked agile from day one — not because it sounds good in a pitch, but because the work we do does not function well in waterfall. In this post I describe what agile practice concretely looks like at Moselwal: what we have taken from the textbook, where we deliberately deviated, and which tensions the method creates inside an agency setup.
What we concretely do
We work with a Scrum-Kanban hybrid. One team of three to six people per client project, two-week sprints, a clearly defined product-ownership role, one tech lead per platform. What we pulled in from Kanban: work-in-progress limits per column, a continuous flow rather than strict sprint boundaries for smaller bug-fix and support tasks, and an honest cycle-time measurement rather than only story-point velocity.
The tools are GitLab for code, issues and CI, Notion for longer concept documents, Slack for ongoing communication. We do not run a separate Jira or Azure DevOps — consolidating on GitLab issues has removed more friction over the past years than any additional tool could have replaced.
Where we broke with pure Scrum
Pure Scrum by the 2020 Scrum Guide was never the right setup for us. We deliberately deviate in three places.
Daily standups are asynchronous. Instead of a 15-minute call every morning, each person writes three lines in a Slack thread: what yesterday, what today, where blocked. Anyone wanting to clarify a topic synchronously attaches a call. That saves roughly an hour per team per week, but costs discipline in writing.
We combine sprint reviews with refinement. The classical demo format at sprint end is rarely efficient in our agency setup: clients often do not have the time to sit through both the demo and a separate refinement session the following week. We bundle the two into a 90-minute session directly at the sprint boundary.
Story points are optional with us. We estimate where it makes sense — on larger chunks, on genuinely unclear tickets. For small, cleanly sliced tasks we skip the estimation and work directly with cycle time as the measure. That is not "No Estimates" but it is a clear break with the "everything must have a number" reflex.
Backlog as a discussion tool, not a wish list
A backlog is only useful when it is understood as a discussion tool, not as a long wish list with tickets from three years back. We keep our backlogs actively small: anything not implemented in the next two to three sprints does not belong in the backlog but in a separate ideas list with a less formal status.
In practice this means a "backlog spring cleaning" every two quarters in which all tickets older than three months are either prioritised, refined, or closed. Closed tickets are not lost — they are simply marked explicitly as "not in this half-year". This discipline keeps the backlog from becoming a demotivating ghost ride of open cards nobody takes seriously any more.
Sprint rhythm and outcome focus
Two-week sprints are our default length. Longer sprints give room for deeper work but stretch the feedback loop to the client; shorter sprints fragment the work unnecessarily. Two weeks is the compromise with the least friction.
More important than the length is the sprint goal. A sprint at our place is not "a dozen tickets that happen to fit together" but a clearly formulated outcome: "At the end of the sprint, the client can do X with the platform they could not do before." This outcome framing comes from the 2020 Scrum Guide and is one of the better corrections to the original format. Anyone who cannot articulate a sprint goal in one sentence has a refinement problem, not a velocity problem.
Retros that actually change something
Retrospectives are the place where many agile teams fail. Not because they do not run them, but because they always run the same one — "what was good, what was bad, what do we take with us" — until nobody participates seriously any more. We deliberately vary the format: sometimes the classical "Mad/Sad/Glad" round, sometimes a "5 Whys" on the most important problem, sometimes a "Fun/Done/Learned" round, sometimes a "pre-mortem" for the upcoming sprint.
More important than the format is the follow-through. Out of every retro comes at most one new point that is concretely implemented in the next sprint — as a standalone ticket in the backlog, with owner and definition of done. A retro without that ticket output is a nice discussion without effect.
Agile inside an agency setup
Agile methodology runs into three tensions in an agency that do not exist that way in an internal product setup.
Fixed price vs. iterative learning. Classical fixed-price proposals assume scope and solution are fixed at the start — the opposite of what agile work fosters. Wherever possible we therefore work on time-and-material or with "fixed price per sprint" models. For classical fixed-price projects, we put a discovery phase with a clearly bounded scope in front of the implementation.
Client stakeholders inside the sprint. A fully engaged product owner on the client side is the exception, not the rule. We address that by deploying one of our senior concept leads as an interim co-PO who holds the functional bridge to the client. That is more expensive than an engaged client PO — but it works, while the theory fails.
Multiple parallel clients per team. Unlike an internal product team, an agency team rarely works on exactly one project at a time. We have solved that by keeping teams stable and assigning projects as "primary focus" and "secondary focus" per sprint. A team works 70 percent on a main project and 30 percent on a smaller companion project. It is not a perfect setup, but it is better than uncontrolled multi-tasking.
What we deliberately do not do
Three practices that are common in the agile discourse we do not run.
No SAFe. Scaling frameworks like SAFe are oversized for our team sizes. We are not a 200-person organisation, and the tooling SAFe brings would create more overhead than value.
No story-point tracking as a KPI. Velocity as a team metric is useful, velocity as a target is toxic. The moment velocity is negotiated as a performance indicator, story points lose their meaning — teams estimate higher to look faster. We use velocity for planning, never for evaluation.
No "agile manifesto" on the wall. We have no poster, no glossary, no "agile coach" role. Agility for us is a way of working, not a ritual. The method has proven itself because we adapt it continuously — not because we defend it dogmatically.
Conclusion
Agile methodology for us is a tool, not an identity. We use what works and drop what produces overhead. Anyone saying agile and meaning waterfall has a problem; anyone saying agile and meaning ceremony has one too. What remains is a way of working that enables learning across three sprints without each sprint triggering its own method debate.