Design thinking vs lean vs agile vs design sprint: which, when

Choose design thinking when you don't yet understand the problem. Choose lean startup when you have an idea and need to find out, cheaply, whether it works. Choose agile when you know what to build and need to deliver it in working pieces. Choose a design sprint when a clear, important problem needs a tested answer within a week. They are not rivals: each answers a different question, and most real projects use more than one in sequence.

The confusion comes from the fact that all four talk about users, iteration and learning. The difference lies in what each one assumes you already know when you start. For the wider question of which single tool to use, see which innovation tool should I use?.

Where each one comes from

A short history helps, because each approach still carries the problem it was built for.

• Design thinking grew out of design practice and was popularised as a general problem-solving approach by the design firm IDEO and the Stanford d.school (the Hasso Plattner Institute of Design, founded in 2005). The UK Design Council's Double Diamond, created in 2003, describes a similar shape. It was built for problems where the need itself is unclear.
• Lean startup was set out by Eric Ries in his 2011 book The Lean Startup, drawing on Steve Blank's customer development and on lean manufacturing. It was built for founders who risk spending years building something nobody wants.
• Agile traces to the Manifesto for Agile Software Development, written by 17 software practitioners in Snowbird, Utah, in February 2001. Scrum, created by Ken Schwaber and Jeff Sutherland, is its best-known framework. It was built for software projects that failed under long, fixed plans.
• The design sprint was developed by Jake Knapp at Google and Google Ventures and described in the 2016 book Sprint by Knapp, John Zeratsky and Braden Kowitz. It was built to get a team from a hard question to a tested prototype in five days.

Side by side

When each fits

Use design thinking when the problem is unclear

You hear several different descriptions of the problem from different people. Complaints exist, but nobody can say what causes them. A new service is needed for a group you have never studied. In these cases, starting with ideas or delivery skips the most valuable work. Begin with stakeholder interviews and finish the framing with a point of view and how might we questions. The full process is in design thinking, step by step.

Don't use it when the problem is well understood and the organisation needs delivery. Running a discovery phase on a problem everyone already understands tests patience, not ideas.

Use lean startup when you have an idea and the risk is that nobody wants it

You have a concept, a sponsor and some enthusiasm, but no evidence that people will use it, pay for it or change their behaviour for it. Lean thinking asks you to identify the riskiest assumption with assumption mapping, write a hypothesis test, and run the smallest experiment that could prove you wrong, such as a concierge test. More in how to test an idea before you build it.

It is weaker when the problem itself is unclear (you will test answers to the wrong question) and in services where you cannot ethically or legally run experiments on the public without care. In government, many experiments need a different consent and risk conversation than in a startup.

Use agile when you know what to build

The concept is validated and the work is mainly delivery: building the system, the process, the service. Agile breaks the work into small increments, written as user stories, delivers working pieces in short cycles, and adjusts through regular retrospectives.

Agile does not tell you what to build. Teams that use it for discovery often end up delivering features quickly that nobody needed. It also fits poorly where contracts, procurement or regulation fix the scope in advance, unless those are set up to allow change.

Use a design sprint when an important question needs an answer this week

A design sprint fits when the challenge is defined, the stakes are high enough to justify five days of a decision-maker's time, and the team is stuck between options. The classic shape: Monday, map the problem and pick a target; Tuesday, sketch solutions individually; Wednesday, decide and storyboard; Thursday, build a realistic prototype; Friday, test it with five users.

It fits poorly when nobody has researched the users (the sprint will lean on assumptions), when the decision-maker cannot attend, or when the problem is too large to prototype in a day.

Mixing them: the usual sequence

The approaches work best in an order that follows the uncertainty.

1. Design thinking to understand and frame. Research and a signed-off problem statement.
2. A design sprint to converge. Use the research to make the sprint's Monday faster and more grounded, and come out with a tested concept.
3. Lean experiments to de-risk. Test the assumptions the sprint did not settle, such as whether people will keep using the service after the first week.
4. Agile to deliver. Build and release in increments, and keep testing with users as you go.

Not every project needs all four. A small internal process fix may need a week of discovery and then delivery. A new digital product may skip straight to a sprint if the research already exists. The rule of thumb: identify your biggest unknown, and use the approach built for that unknown.

A worked example

Illustrative. A national postal operator in a mid-sized European country wants to offer a service for small online sellers.

Design thinking (six weeks). The team interviews twenty sellers and observes several of them packing orders. The expected problem was postage cost. The real one: sellers lose hours each week handling returns, because buyers print labels wrongly and parcels come back unidentified. The problem statement is signed off: "How might we make returns effortless for sellers with fewer than fifty orders a week?"

Design sprint (five days). With the head of parcels in the room on Monday and Wednesday, the team sketches, chooses and prototypes a returns code a buyer shows at the counter, with no printing. Five sellers test it on Friday. Four want it, and all five ask whether it works with their marketplace.

Lean experiment (four weeks). The riskiest remaining assumption is that counter staff can process the codes without slowing the queue. The team runs a concierge version in three branches, with staff handling codes manually from a printed list. Queue times stay stable.

Agile delivery (ongoing). A delivery team builds the real system in two-week sprints, starting with one marketplace integration and the counter scanning step, and testing each release with sellers.

Each approach did the job it was built for. Starting with agile would have produced a fast postage-discount tool. Starting with a sprint would have missed the returns problem entirely.

Do's and don'ts

Do

• Name your biggest unknown first, then pick the approach built for it.
• Feed research into design sprints. A sprint on top of real user insight is much stronger than one built on guesses.
• Keep testing with users once agile delivery starts.
• Agree up front who owns the handover between stages, especially from sprint to delivery.

Don't

• Don't treat the four as competing brands or ask which is "best". It is like asking whether a map beats a hammer.
• Don't use agile for discovery. Short delivery cycles don't replace understanding the problem.
• Don't run a design sprint without the decision-maker. You will get a good prototype and no decision.
• Don't call every workshop a design sprint. Five days with the defined structure is one thing; a two-hour ideation session is another.
• Don't let each approach live in a different department with its own vocabulary. The handovers are where the learning gets lost.

Questions people ask

Is a design sprint the same as design thinking? No. A design sprint is a fixed five-day process that uses several design thinking tools to answer one defined question. Design thinking is the broader approach, and its discovery work usually comes before a sprint.

Can design thinking and agile work together? Yes, and they should. Design thinking works out what to build and for whom; agile builds it in increments. The common pattern is a period of discovery, then agile delivery that keeps a regular rhythm of user testing.

Which is better for government projects? It depends on the unknown. Design thinking suits services where citizen needs are unclear; agile suits digital delivery once needs are clear; lean experiments need extra care on consent and risk when the public is involved. Many government digital service standards combine discovery with agile delivery.

Where to go next

For discovery, start with stakeholder interviews. For de-risking an idea, use assumption mapping. For the sprint's prototype day, see paper prototype, and for delivery, user stories. All method guides are in the guides index.