Sprint-based design work solves one problem well: it creates urgency. Two weeks, a defined output, a review at the end. The pressure is real, and pressure produces decisions. But sprints also create a specific kind of dysfunction in design-heavy work: the team is always executing, and the space for thinking about whether they are executing the right things collapses.
At France VAE, the platform for prior learning recognition operated by beta.gouv.fr, I was embedded as the product designer on a cross-functional team. The work was complex: a national platform serving 100,000+ candidates, with a parallel system of field actors (the AAPs) whose needs were often different from the candidates' and sometimes in tension with them. The team was not short of ideas. It was short of direction. Each sprint produced output, but the cumulative shape of the product was getting harder to read.
From sprints to seasons: the structural change
The shift I proposed was to organize work around monthly seasons, each containing three delivery cycles. A season has a theme: a specific capability area or user problem that the team is orienting toward for the month. The three cycles within it produce progressively refined work on that theme. At the end of the season, there is a retrospective that looks at both the delivery and the theme choice itself.
The practical mechanics matter here. A cycle is not a sprint: it does not require a full planning ceremony or a rigid backlog. It requires a clear output and a clear question the output is supposed to answer. "By the end of this cycle, we will have a tested version of the guidance flow for AAPs, and we will know whether the problem is comprehension or confidence." That statement takes fifteen minutes to write. It replaces two hours of sprint planning.
The season retrospective is what makes the system work at a higher level. It is not a team health check or a process improvement session. It is a deliberate look at whether the theme we chose was the right one: did the work we did this month move the product in a direction that matters? If not, what does that tell us about our understanding of the problem? That question, asked monthly rather than weekly, creates a different quality of reflection.
What changed at France VAE within two seasons
The first season was imperfect. The theme was too broad, and two of the three cycles produced work that was solid but did not connect clearly to each other. The retrospective made that visible. The second season was tighter: a narrower theme, more deliberate cycle sequencing, and a clearer line from the opening question to the final deliverable.
The observable shift was from reactive to intentional. Before the seasonal structure, the team's weekly rituals were well-established: discovery calls, review sessions, backlog grooming. But these rituals operated at the level of individual tasks. No one was looking at the month as a coherent unit. The seasonal structure provided that frame without adding overhead to the weekly cadence.
The relationship with the product manager also changed. In a pure sprint model, the PM is often the person who decides what goes into the sprint. In the seasonal model, the designer and PM co-own the theme: they agree together on what the month is for, then the PM manages the delivery backlog within that frame and the designer manages the craft. That division of ownership produced fewer ambiguous handoffs and more aligned decisions.
The underlying principle: urgency and orientation are different things
Sprints create urgency. Seasons create orientation. A high-functioning design team needs both. Urgency without orientation produces polished work that does not accumulate toward anything. Orientation without urgency produces thoughtful processes that do not produce output.
The delivery cycle structure I landed on at France VAE is not a framework I would impose on every team. It emerged from the specific conditions of a public service product with a complex actor ecosystem and a team that already had strong execution habits. But the underlying logic applies more broadly: the unit of planning should match the unit of thinking. If the important questions in your project are monthly in nature (what are we building toward this period?), then weekly sprints are the wrong planning unit. The planning structure should make the right questions easy to ask.
What we were looking for at France VAE was a way to hold both execution and reflection in the same system. The seasonal structure did that. It took two seasons to calibrate, and the calibration was worth it.