Why designing during the sprint is dumb

When I interview designers and ask them how they work in their current organisation they often describe a situation where design work is carried out just before or during the sprint. The results are usually the same too — poor quality, messed up sprints, stress and low job satisfaction.

Nobody in a leadership position in any company would want those things. Yet companies with strong delivery or engineering focus seem to be quite willing to accept the problems associated with it.

Inevitably a designer’s input is needed during the sprint to clarify something or work out how to handle an unexpected edge case. Designers should be involved in the QA work too as they usually have an eye for detail. Designers help the team deliver.

But *most* of the designers work for a sprint is done in advance of the sprint.

Agile-theorists may whine about design in advance being “mini waterfall” but rest assured they’re talking through their arse. Engineers make preparations in advance of a sprint and that’s not questioned. Designers make preparations too. The difference is that few non-designers take the time to understand how designers prepare.

A couple of caveats for before we go any further.

Firstly I’m not talking about doing all (and I mean all) of the design work in advance of the sprint. That is hard to reconcile with agile approaches.

Secondly I’m not including design discovery work. The research, the benchmarking, the interviews with stakeholders. All that design strategy work associated with the first diamond in “double diamond” still happens *before* anyone is even talking about agile.

Doing all the design work up front is risky

The main risks are associated with delayed delivery of working software and the value it is supposed to create. These risks include:

• Things changing. Business priorities, technology, the competition. The further in advance of development you work, the greater the risk of re-work due to changing circumstances.
• Delayed creation of value. In addition to bottling up risk, you’re also delaying the commencement of development and the delivery of working software.
• Lack of engagement from technologists. Engineers have a day job just like anyone else. It’s far more likely that they will not be engaged in the design process if it happens several months prior to development. This lack of input increases the risk of unfeasible design solutions that will require rework.
• Wasted effort creating design artefacts. Designers can spend an inordinate amount of time creating documentation to hand-off design to engineering. This means designers spend a lot of time creating documentation because they don’t have close engagement with a team.

Doing most of the design work during the sprint is a different kind of risky

Designing during the sprint might seem ultra-lean but in reality is it extremely wasteful and likely to result in rework and the creation of both technical and design debt. Why?

• Planning is impossible. All teams needs time to bottom out requirements, set acceptance criteria and prepare for the sprint. Design during the sprint causes requirements and acceptance criteria to change during the sprint.
• Customers needs time to approve designs. Yes, in reality the PO should be empowered to approve design but in many organisations the PO is a proxy and the invisible (and sometimes all too visible) hand of the stakeholder comes into play.
• Design quality compromised. There is always compromise but the acute pressure to deliver results in poorer quality work.
• Time is wasted during the sprint. Simply put, spending more time planning during the sprint and less time delivering sets the team up to fail to deliver on commitments.

“But you’re just not agile enough.”

“In theory, there is no difference between theory and practice. But in practice, there is” — Attributed to Jan van de Snepscheut, computer scientist

There are hypothetical scenarios where designing very close to the beginning of a sprint might work.

I have listened to many non-designer-agile-theologians preach their gospel. Their religion requires a set of ephemeral criteria to exist and a team of true-believers working in some kind of zen-master-flow-state.

Their fantasy involves:

• Assumptions more often correct than incorrect
• A design system in place that accommodates the majority of scenarios or is so simple that anyone can use it.
• A predictable backlog with several sprints-worth of well-refined and sprint-ready stories, and no surprises or sudden changes in priority.
• Few 3rd party dependencies, and low risk associated with dependencies.
• An empowered PO-decision maker with the authority to make final decisions without management interference.
• No new or recently joined team members. Team works as one.
• No team members or contractors working in vastly different time zones from the designer.
• No management or outside interference.

So what works in the real world?

Every organisation has their own institutional psychodrama to contend with. In my experience I’ve found the following to work.

• Design activity (excluding discovery, remember) needs to start several weeks in advance of development.
• Design needs to start early enough for all requirements to be bottomed out, for real approvers to approve designs and for typical refinement and planning activities to occur.
• Design outputs need to be included in the teams “Definition of Ready” and “Definition of Done”
• There needs to be a balance struck between not working so early that priorities change and work is wasted, and not working so late as to undermine commitments and require the team to waste time during the sprint figuring out what they’re doing.