The design sprint: Structured decision making

The simplest and most effective thing an organisation can do to be more innovative is to make faster decisions. This article looks at some of the common pitfalls in making decisions, particularly around the waterfall project management method. We’ll then present the agile methodology, which embraces change and enables iterative decision making. Finally, we’ll explain the design sprint framework by which organisations can structure their decision-making process.

Everyone has a plan until they get punched in the mouth.

Mike Tyson

Introduction

In our previous article, ‘Where good ideas come from‘, we described the science around ideation and how brainstorming sessions can result in groupthink. We concluded by making four recommendation when forming an innovation strategy:

1. Assemble participants with diverse expertise & backgrounds;
2. Ditch the brainstorming sessions for working alone together;
3. Create an environment where ideas can be shared and challenged (without negative repercussions); and,
4. Enable slack for ideas to emerge and develop.

One of the best ways we’ve discovered to incorporate these principles into a framework is the ‘Design sprint’. The design sprint is a five-day process originally developed by Google Ventures for answering critical business questions. The methodology was subsequently refined by Jake Knapp and shared in his book, ‘Sprint: How to solve big problems and test new ideas in just five days’.¹

At Parametric Monkey, we’re big fans of the design sprint process. There are many reasons why we believe this is a highly effective framework. Mostly, however, we see it as a practical application in how organisations can make decisions.

Don’t go chasing waterfalls
Please stick to the rivers and the lakes that you’re used to
I know that you’re gonna have it your way or nothing at all
But I think you’re moving too fast

‘Don’t go chasing waterfalls’, TLC, 1994

Waterfall project management

Many readers will be familiar with the project management methodology known as ‘waterfall’. That is, where a project is broken down into distinct stages, and the team moves step by step through the stages. It is the dominant project management method used in the Architecture, Engineering and Construction (AEC) industry. Indeed, the waterfall method originated from the manufacturing and construction industries.

The waterfall process is one of command and control, attempting to impose rigid predictability. Months and months are spent planning, culminating with colourful Gantt charts defining critical paths and key milestones. The problem, of course, is that the Gantt chart is always wrong. We succumb to the planning fallacy and massively underestimated how long the task is going to take. The client is out of town and can’t sign-off the design report. The excavation uncovered soil contamination, and all construction needs to stop. The subcontractor has gone into liquidation, and we need to source a new supplier. The list goes on-and-on. And we know that this routinely happens. But this is how we’ve always done it, so we accept it as a part of life.

The agile manifesto

In 1987 Tom Peters popularized the term ‘failing fast’.³ Despite the negative connotations with the term ‘failing’, the idea was simple – an iterative approach to development with regular feedback reveals potential issues before becoming problematic and difficult to fix. Thus, it’s less about failing and more about learning quickly.

Fast forward fourteen years, and in 2001, seventeen people met to discuss the future of software development. The group’s members shared frustration about the current state of affairs, even if they disagreed about how to remedy the situation. The problem, they agreed, was that companies were so focused on excessively planning and documenting their software development cycles that they lost sight of what mattered—pleasing their customers.⁴ And so the agile manifesto was born:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

The agile manifesto

Applying agile

Since then, an agile methodology has become the norm in software development and many other industries. There are various implementations of agile, the most common of which are Kanban and Scrum. Kanban is all about visualising your work, limiting work in progress, and maximising efficiency. They do this by using a Kanban board, such as Trello, and continuously improving their workflow Scrum teams, on the other hand, commit to shipping working software through set intervals called sprints. Their goal is to create learning loops to gather and integrate feedback quickly.⁵

While I accept that much in the AEC industry must be done via the waterfall method, there is still scope to embrace agile, particularly in how organisation make decisions around innovative initiatives. Innovation is a messy process, and over time, some ideas will undoubtedly fail. But through an agile approach, organisations can minimise risk while maximising innovative initiatives.

One-size decision making

Jeff Bezos, the founder of Amazon and the world’s richest person, describes that one of the most common pitfalls for large organisations is “one-size-fits-all” decision making.⁶ He makes the distinction between what he terms ‘Type 1’ decisions and ‘Type 2’ decisions:

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation…We call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors…Type 2 decisions can and should be made quickly by high judgements individuals or small groups.

Jeff Bezos⁷

Bezos continues why this distinction is important:

As organisations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversions, failure to experiment sufficiently, and consequently diminished invention.

Jeff Bezos⁸

The trick then is to identify Type 2 decisions and empower individuals to make those decisions themselves. This represents a departure from the micro-managing that goes on in a lot of AEC organisations. But for an individual or small group to make the correct decision, they must be fully aligned with the company’s mission. For Type 1 decisions – those that are the most important and challenging, we recommend the Design Sprint.

The Design Sprint

The design sprint is different to a sprint as defined in agile development. However, it is very much complementary. It runs for five days, with a different focus each day. Five days, of course, is a long time to focus exclusively on a single idea. However, the process is not simply about deciding what to do, so comparing it to a one-hour meeting is not fair. It is about deciding, building a prototype and testing the idea. Course-correction, or ‘pivoting’ as Silicon Valley would say, is then possible before it is too far down the line.

Creating barriers to distraction

Strict rules around no devices, such as iPhone, laptops, etc., means participants aren’t easily distracted with business-as-usual. This means ‘System 2’ thinking, which is effortful mental activities, can be evoked, reducing the possibility of cognitive biases.

Moreover, it improves focus and productivity. Whenever your brain changes context – say from Project A to Project B, there is a switching cost. Your brain has to ‘boot up’ to load all of the relevant information into its working memory. The science behind this phenomenon is known as ‘Dual-task interference’ and was pioneered by Harold Pashler in the 1990s.¹² He concluded that people could really only think about one thing at a time.

In his book ‘Quality software management’, Gerald Weinberg claims that running two simultaneous projects results in a 20% loss to context switching.¹³ This means only 40% of the time available per project, and the remaining 20% is a complete waste. When you get up to five simultaneous projects, as maybe a director or project manager might, 75% of your time is a complete waste, lost due to dual-task interference!

The dual-task interference test

Not a believer? Try this task. You want to be as fast as possible. Write down the numbers 1-10, the Roman numerals 1-10 (I, II, III, IV, etc.) and the letters A-J. First, do it each row at a time. Time yourself and make a note of it. Got it? Now, repeat the task but instead of doing it by rows, do it by columns. Again time yourself and make a note of it.¹⁴

Most people discover that completing the task by rows is far slower than doing it by columns. The output, of course, is the same, but the process is different. When we do the task by rows, we are effectively multi-tasking, and it is slower. This is the dual-task interference in action, and it is very much real. And much like compounding interest, the longer you remain focused, the more engaging you’ll find it and the better work you’ll do.

Assembling a team

The ideal size for a sprint is seven people or fewer, inclusive of the facilitator, and are most successful with a mix of people. The one caveat is that the Decider must be involved in the sprint. The whole premise of the design sprint is to make decisions, and if the Decider isn’t there, this can’t be achieved. A cameo appearance on the last day for fifteen minutes isn’t going to cut it. If the Decider won’t commit, that is a big red flag.

As we discovered in ‘Where good ideas come from‘, the best ideas originate when there is cognitive diversity – people with different backgrounds and experiences. This helps avoid groupthink and echo chambers. The design sprint addresses this by incorporating seven people in total, enough to get diversity without a regression to the mean.

Monday: Map

Defining the problem

The first step of the design sprint is to define your long-term goal. This requirement ensures that priorities are sorted before starting on solutions and acts as a beacon to keep everyone aligned.

Make a map

The next step is to visualise the problem via a simple diagram. Each map is customer-centric, with a list of key actors on the left.

Ask the experts

Since nobody knows everything, experts are invited in for one-at-a-time intervals. This step enables more people to become invested in the process and can yield surprising insights by telling you what you didn’t know. With each person taking notes in the form for a question, “How might we…”, it forces the team to look for opportunities and challenges, rather than getting bogged down by problems or premature solutions.

Choose a target

The how might we notes are organised and voted on using dot stickers. Notes are then prioritised based on the number of votes. Once this is done, the decision about where to focus should be easily identified. It is the place where the most significant opportunity (and possibly risk of failure) exists. The Decider then makes the call on the target for the remainder of the design sprint. Everyone’s option is acknowledged via voting but without groupthink and open-ended discussion.

Tuesday: Sketch

On Tuesday, the team starts sketching out possible solutions to the target. This is a four-step process beginning with gathering key information (notes). Doodling rough solutions (ideas), trying rapid variations (crazy 8s), and then figuring out the detail (solution sketch). The process of working alone together allows the generation of better solutions. Moreover, each person has time for deep thought, but time limits keep things moving along.

Wednesday: Decide

Decide

Wednesday is about evaluating solutions all at once, critiquing all at once, and then making a decision all at once. Everyone’s sketches are put up on the wall in an anonymous manner (art museum). Voting is then done via dot stickers on the sketch you like (heat map). A time-boxed, structured team discussion occurs for each solution on a sketch-by-sketch basis (speed critique). The creator of the sketch remains silent until the very end. The creator then explains any ideas behind their sketch that the team missed. This method means that ideas have to stand on their own

A nonbinding vote via another dot sticker is used to gauge the group’s opinion (straw poll). Based on this outcome, the Decider then casts the ultimate decision (super vote). Therefore, the chosen sketch represents the best chance of answering your sprint question and helping you reach your long-term goal.

Many organisations have the habit of confusing collaboration with consensus, wrongly assuming that consensus is needed for the process to be collaborative. The result, however, is that decisions can’t be reached and execute quickly. Collaboration becomes not the oil greasing the wheel but the sand grinding it to a halt.”²⁵ But as this process shows, there are better alternatives that are both collaborative and enable decisions to be made.

Storyboard

The next step is to imagine your finished prototype so that you can highlight any problems or points of confusion.

Thursday: Prototyping

Thursday is about turning the storyboard into a prototype. The prototype is not about building the real thing. It is a ‘façade’ or an illusion to gain feedback. The process requires a mind shift from perfect to just enough. The prototype should be considered disposable, so quick and dirty solutions are preferred.

Friday: Test

Friday is about conducting user testing of your prototype. In our article, ‘UX Design: 5 golden rules to elevate your in-house software solutions,’ we explain the logic behind this. Back in the 1990s, Jakob Nielson showed that 85 per cent of the problems with web usability were observed after just five people. What this means for our prototype is that after five thirty-minute interviews, 85% of issues should be identified. Again, the process of testing ideas quickly enables you to pivot if necessary.

Conclusion

AEC organisations are well-advised to embrace an agile project management methodology. Such an approach allows testing ideas quickly, and most importantly, receiving valuable feedback before any substantial time and money is invested. The design sprint framework demonstrates how simply this can be applied to any idea. Ultimately, it is about setting up the proper framework with the right incentives and giving people the freedom, respect, and authority to make intelligent decisions. So next time you feel yourself succumbing to the planning fallacy, take a note from Chilli, T-Boz and Left Eye and don’t go chasing waterfalls. You’ll be more innovative and more productive as a result of it!

Interested in Parametric Monkey facilitating your next design sprint? Drop us a line and discover how we can help you do better things.

References

¹ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London.

² Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days.

³ Peters, T. (1987). Thriving on chaos: Handbook for a management revolution. Knopf, New York.

⁴ Drumond, C. Is the agile manifesto still a thing? Atlassian.

⁵ Rehkopf, M. Kanban vs. scrum: Which agile are you? Atlassian.

⁶ Bezos, J. (2021). Invent & wander: The collected writings of Jeff Bezos. Harvard Business Review Press, Boston, p.143.

⁷ Bezos, J. (2021). Invent & wander: The collected writings of Jeff Bezos. Harvard Business Review Press, Boston, p.143.

⁸ Bezos, J. (2021). Invent & wander: The collected writings of Jeff Bezos. Harvard Business Review Press, Boston, p.143.

⁹ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.38.

¹⁰ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.39.

¹¹ Knapp, J. & Zeratsky, J. (2018). Make time: How to focus on what matters every day. Penguin, London, p.2.

¹² Pashler, H. (1994). Dual-task interference in simple tasks: Data and theory. In Psychological Bulletin, vol. 116, issue 2, pp.220-244.

¹³ Weinberg, G. (1991). Quality software management. Dorset House, New York.

¹⁴ Sutherland, J. (2014). Scrum: The art of doing twice the work in half the time. Penguin, London, p.90.

¹⁵ Knapp, J. & Zeratsky, J. (2018). Make time: How to focus on what matters every day. Penguin, London, p.89.

¹⁶ Knapp, J. & Zeratsky, J. (2018). Make time: How to focus on what matters every day. Penguin, London, p.89.

¹⁷ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days.

¹⁸ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.63.

¹⁹ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.63.

²⁰ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.75.

²¹ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.80.

²² Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.109.

²³ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.128.

²⁴ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.128.

²⁵ Ibarra, H. & Hansen, M. (2011). Are you a collaborative leader? Harvard Business Review Press.

²⁶ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.148.

²⁷ Knapp, J. (2016). Sprint: How to solve big problems and test new ideas in just five days. Bantam Press, London, p.149.