How small can your Design Sprint team be?

Photo bySteinar Engelandon Unsplash

We ran several sprints and found a lot of difficulties and issues working with such a small team, both on our side as thestartupfactory.tech and the nature of early stage tech startups. Here are the lessons I’ve taken away, and some adaptations to help us deliver a design sprint with a much smaller team without compromising on quality of learnings or speed of execution.


Disclaimer: if you aren’t familiar with the Design Sprint methodology, I recommend you read up about it a little bit before continuing. See:


The Problem

Classic sprint team

A snapshot of the team from one of our most recent Sprints.

Before we dive in, it’s worth framing the problem by reminding ourselves of the recommended Sprint team composition. Ideally, your team consists of 4–7 people, including some of the following:

  1. Decision Maker– this person is directly accountable/responsible for project success. They must have a deep vested interest in seeing the project work.
  2. Facilitator– an unbiased guide for the team and process. Works better if they’re an outside third party.
  3. Designer or Prototyper– creative thinker and skills required to mock up an ultra-skinny version of a solution the team can dream up.
  4. Customer Representative– anyone who hears about the user or customer problems almost daily, understanding subtle nuances.
  5. Cynic 😈– someone who brings the team back down to reality, to help balance out the optimistic with some constructive pessimism.

Our team

At the time of writing we have a small and intimate, yet nimble team of 6 for the day-to-day operations:

  1. MD — the business brains and mastermind
  2. CTO — technical strategy and relationships
  3. Head of Engineering — technical execution and best practices
  4. Head of Projects — logistics and processes
  5. Head of Design — visual and structural strategy and execution
  6. Technology Intern — technical execution and fresh eyes

We could get the entire team involved in these Design Sprints regularly, but it’s only one aspect of our business. It wouldn’t be an efficient use of time or resources, and also it’d provide some strong biases into the Sprint process.

Startup team

Being completely honest, a lot of startup teams we work with begin like this:

  1. Founder

If we’re really lucky, it might look more like this:

  1. Co-founder
  2. Co-founder

Not so easy.

Sprints are amazing ways to kick start projects, but how can we deliver the benefits of a Design Sprint to a startup at such an early stage that doesn’t completely break the bank?

Our journey

Sprint 1.0

Illustration by Jake Knappfrom the Sprint Book
We began the journey as most would; we picked up the Sprint book, was immediately fascinated and got to work practicing the exercises and finding a suitable project to run it against. Here’s a couple of team configurations we tried using the vanilla method.

Team config #1

This was a team of three people; the startup founder, our Head of Projects (HoP) and Head of Design (HoD). Long story short, we’re lucky we got to the end.

But why?

  • High volume of work for 3 people to undertake
  • Lack of idea and opinion diversity
  • Long tail of work post-sprint

That last point mostly came down to myself running it as a combo designer-cum-facilitator. We instantly knew why the book recommended at least 4 people in the team. Who would have thought?

Team config #2

We tried four people, and tried to balance it as well.

From tsf.tech we had:

  • HoP
  • HoD

From the startup we had:

  • Founder
  • Sprint buddy

A Sprint buddy could be family, a friend, user, investor, board member. It’s anyone from the founder’s side of the table. We realised that if a startup was ever going to work, they need to have or be able to cultivate the relationship and buy-in for someone to commit 4–5 days of time into them. If they can do that, then we’re on the right foot for a Design Sprint (and hopefully the startup too).

With this team of four and a more balanced energy going around the room, we found that surprisingly it worked almost twice as good! We had solved most of the issues presented with a 3-person Sprint team or alleviated it enough to be workable. The insights and learnings from these Sprints were a lot more clear and helped inform many of the future decisions we had to make.

Pass the Baton Method

We realised that especially with startups, even within established organisations, it’s difficult to grab someone’s time for 5 consecutive days. It’s not impossible but we needed to make it as easy as we could, especially considering a startup budget usually consisted of favours and paid lunches.

We developed the “Pass the Baton” method, and it works similarly to the 400m relay race.

Recruit 5 willing volunteers for the 5 different days.
  • Get 5 Sprint buddies
  • Assign one person per day
  • Ensure you do a thorough recap each day

The great thing about running a Sprint with this methodology is you force yourself to be as clear as possible between the different days. In addition, the effort required to recap succinctly and effectively led to the final summary report being straightforward to assemble together after the Sprint had finished.

Testing

So we got the team size right, found the exercises worked well, at the very end there’s testing. We also had some err… logistical challenges when it came to test day, to say the least.

Test Configuration #1

Here’s the complex breakdown of how our very first test “day” went down, complete with a messy diagram. Note that this took place a few weeks after the original 4 days had been completed:

Breakdown of the days, locations and test participants in our first Design Sprint.

Represented textually, we had:

Day one:

  • Location A: 1x test participant
  • Location B: 2x test participants

Day two:

  • Location C: 1x test participant
  • Location D: 1x test participant

As you might be able to tell, this format didn’t compliment the principles or the Sprint methodology very well at all. Most significantly:

  1. Loss of momentum; we started to lose sight of why we did the Sprint in the first place and put in a lot of work to sustain that momentum afterwards.
  2. Less able to spot patterns; the disruption between locations and days made it difficult to collate our notes, as well as having different interviewers.
  3. Favours. This is perhaps the biggest downfall.

Utilising favours from friends and acquaintances of the founder reduced the quality of the insights. You know how you never ask your mother if you have a good idea because she’ll think everything you do is great? That notion still occurs here. This is easily the most valuable lesson I learned from all the Design Sprints I’ve been through:

The quality of your participants will directly influence the quality of the insights that come out the other side.

It might seem like a lot to offer $100 gift certificates as the original Sprint book suggests, but there’s a good reason to do so. Even if it’s not to that level of value, even offering £10 and lunch provided enforces the idea that this is a transaction. We want our test participants to be brutal, but fair and transparent in their first impressions.

Hidden benefit: even though the quality of the insights was compromised, we got buy-in from these participants to help again further down the line. Winning!

Test Configuration #2

Getting back to basics and following the instructions.

Even though it put more time pressure and required more work throughout the week, we went back to the original recipe and carried out all 5 user interviews sequentially on the same day. Suffice to say, we always endeavour to run the “test” day in a similar fashion.

Testing Takeaways

Here’s a few things that I distilled out of our experiences as lessons I hold on to whenever I do anything Sprint or Design related:

  • Provide compensation; it will enforce the idea of being an exchange for honest, valuable feedback.
  • Screen for participant fit; if it’s not the right type of user or customer you might make some misguided decisions later on.
  • Run your tests in quick succession; spotting the learnings is SO easy this way and you can readjust your test more readily.
  • Run with it; momentum shoots through the roof, use that to slingshot into the next phase of your project.

Open Challenges

The full team, tsf.tech and the startup, are present on all days of the Sprint.

So that’s end of story, right? Not quite. There’s still some challenges that I wanted to overcome, but didn’t yet have a clear way forward.

  1. HMW improve prototype fidelity? I wanted more realistic prototypes.
  2. HMW optimise Sprint Team utilisation? It still felt there were optimisations to be had.
  3. HMW create a manageable workload for a Facilitator/Designer combo scenario? I know it’s possible but its still heavy work.

The Solution

Sprint 2.0

If you aren’t familiar with Sprint 2.0 or AJ&Smart, they’re a company based in Berlin that have also run 150+ Design Sprints themselves with more traditional organisations. Whereas Google Ventures focused on their own startup portfolio, AJ&Smart found success in helping larger, slower moving corporates access the benefits of the Design Sprint too. Since they offered a Masterclass to learn their methodologies, I took the earliest opportunity to learn what we could incorporate.

So what changes?

Breakdown of Sprint 2.0 by AJ&Smart

In short, assuming you’re familiar with Sprint 1.0 by now, the biggest change is that the Map and Sketch days are merged into a single day. This allows the remaining days to move up in the schedule, and creates a 4-day long Sprint. There are a few aspects I’d also like to highlight and some observations I’ve made.

Good parts:

  • Definitely felt that we could optimise Map and Sketch in 1.0
  • Minimises client volume time and maximises the benefits
  • Subtle yet powerful tweaks to exercises and facilitation methods

“Could be better” parts:

  • Still intensive and hands on
  • Optimal team for 2.0 still doesn’t fit our structure

Did we solve all the Open Challenges?

So, we managed to address sprint team utilisation, improve fidelity using the suggested tweaks and alleviate some pressures in a part-time facilitator part-time-designer scenario. But it’s not quite there. There’s still a few points of contention we’ve experienced applying the latest techniques of Sprint 2.0 to subsequent Sprints we’ve ran:

  • Mapping; the map you produce is always better with some up-front UX research and this is still tricky to arrange for some startups.
  • Prototyping; the tooling is better, but I wanted even better. Think “photo-realistic”.
  • Test day; perhaps this is down to good delegation, but it still requires good skills and tenacity to pull off effectively.

With a practical hat on I know we won’t solve all of these challenges in one fell swoop, and some solutions may work until we hit an edge case, but we’ve got to start somewhere. After all, the spirit of entrepreneurship and innovation is to get started, iterate often, and tackle each challenge as you come across it.

“Solo Sprint 1.0″

This is our answer to help close that gap into a process that really works for us and our clients right now. Our modifications aren’t actually very complex.

Breakdown of the “Solo Sprint 1.0”.

In fact, there’s two major modifications:

1. As part of your Pre-Sprint work, create an Assumptions Board

This is something that I thought was a good idea, until I realised a few others had already come up with the same concept 😂. What you want to do is kickoff an engagement by listing out all the assumptions made about the product and the startup itself. Then, methodically devise a method to test those assumptions and what you must observe or what must happen for that assumption to be a truth. Getting to even 5 “truths” pre-sprint helps the Mapping exercise massively.

You can read an example of how thoughtbot use Assumption Boards here.

2. Add in an extra day for prototyping

I can’t magically make myself prototype faster, constantly hire in extra hands to participate in our Sprints or constrain ourselves to working with clients who can also prototype. Therefore the only logical way forward is to double the amount of time allowed to craft a prototype. In my experience so far it takes about 1.5 days for most prototypes, leaving a generous half day I can dedicate to the testing component of the Sprint.

It’s actually very simple in principle, still manages to fit the Sprint into a single working week and compliments the team size of ourselves and the startups we partner with. No doubt there’ll be some more challenges that present new opportunities for iterating our flavour, but I’m confident this is a solid recipe that should serve us well for some time.

Takeaways

Photo by Alan Hardman on Unsplash

I’ve listed out many takeaways, challenges and solutions throughout this piece but I thought I’d end with what I’d suggest to anyone embarking on a similar journey — some bite-sized nuggets of wisdom.

You’ll never truly be solo.

It’s impossible. The very nature of a Sprint is to assemble the key skills and experiences necessary to find an effective starting point for big, difficult business problems. At the very least you’ll be working with someone who can tell you about the problem. If it’s your own problem, you’ll need a 3rd party to test it or some fresh eyes to poke holes in your solution.

Practice pieces of the Sprint in isolation.

It can be daunting to try and pull off the entire Sprint in one go. It’s even more daunting to try and retrospectively go back during or after a Sprint to experiment with tweaks to improve your workflow. If you can, it’s much easier to run the exercises in isolation and try a few different tweaks to see if it helps or not before employing them in full-fat Sprints.

Don’t underestimate test day.

DON’T DO IT! But seriously, it’s the entire reason we run the Sprint in the first place. If you skimp out on test day, then all you have is a tangible concept with no data to learn from (or worse — low quality, inconclusive data). Make sure you spend just as much effort on testing as you do the rest of the Sprint, if not more.

Definitely don’t underestimate what happens post-Sprint

Everyone needs to have a method of translating the learnings into some next steps, lest you go back to “business as usual”. Firstly, remember why you did the Sprint in the first place and make that difficult decision based on the Sprint outcomes. Secondly, carry on the spirit of the Sprint with a tool like the Assumptions Board constantly throughout your product development to iterate and help make other decisions. If you must go straight into a build, then schedule in a follow up user test with the same people and the real thing once it’s functional enough.


If you’re based in Manchester, U.K., there’s a Design Sprint Manchester Meetup group to talk about advanced topics like this, or help newbies alike in a low-pressure forum. If you have questions, concerns or rebuttals, you can always find me on Twitter as @chuckwired or email me at charlesr@thestartupfactory.tech.


Originally published on Medium.

Read this…