OK, so you’re running a hot new startup or tech business.

You’ve built an incredible squad of engineers. Your team is full of great ideas, and is technically sound. Like most successful software companies, your development team has adopted the practice of Agile, whether it be Scrum, Kanban, XP or Lean. Your dev team is consistently dominating whatever stories you can throw at them.

Hell, your product management team is on point as well. Roadmaps defined for the next 6 weeks, 6 months and 6 years. Pieces of work are routinely concepted through user research, validated with solid business analysis, and are distilled into simple-yet-robust Stories.

Everything is cruising along perfectly (maybe even landing a funding round in the meantime?) when it happens – your dev team raises the red flag.

“No more! We cannot proceed until we figure out this specific issue. Full stop!”

This is your momentum.

There goes your momentum.

And with that, the wind has officially left your team’s sails.

Apparently, somewhere along the lines of concepting a feature, validating the need for it, and defining the acceptance criteria, you forgot that the design needs some serious work to accommodate this Story. The current UI options within your team’s meticulously-crafted style guide no longer suffice. We’ve somehow stumbled upon a scenario where we need to concept a new way to tackle an issue.

But how might we do this?

Time to learn about the Design Spike, a tactic to focus your team, rapidly solve unknowns, and get your team back on to your sprints. At the end of this article, whenever your team faces design challenges in the middle of a sprint, you’ll know how to get back on track and start shipping product in no time at all.

What on earth is a Design Spike?

I know, I know – you’re thinking “…a design what?

A Design Spike temporarily halts all recurring sprint progress, and defines a timebox to hyper-focus your team on the design issue at hand. The fine folks at Scaled Agile Framework define it as “used whenever there is significant uncertainty as to how a user might interact with the system” and are “…often best evaluated through some level of prototyping”. Spiking allows your team to concept good ideas and bad ones without committing anything other than the time it took to sketch & validate them on a whiteboard. Seriously, it’s an awesome tool in your Agile belt, no matter which discipline of Agile your team practices.

Similar to the sprints that your dev team normally uses, Design Spikes are timeboxed. While you could have a 1-day spike or a 2-week spike, Jeremy Jarrell, frequent Agile blogger, mentions…shorter spikes force us to keep them well-defined, which means that they’re more likely to produce something of meaningful value to both the team and the customer.”

Seems like it makes sense, right?

Swarming: getting everybody's focus on the design problem, to find the solution in the shortest time.

Swarming: getting everybody’s focus on the design problem, to find the solution in the shortest time.

But here’s the catch…it works best if your entire team swarms on it. And when I say the entire team, I actually mean it. Get your PMs involved. Get your designers involved. Hell, even get us involved. And definitely, absolutely, positively get your developers involved.

Design Spikes are actually pretty similar to the famed Design Thinking by the Standford d.school or the Google Ventures design sprint – a concentrated timeframe where team members focus on volume of ideas before consolidating down to a few solid options that can be tested.

How we run Design Spikes

We run Design Spikes frequently with our clients, and we have a couple of go-tos for generating a large quantity of new solutions:

These are just a few of the tactics our team uses when we’re stuck and feel the need for a Design Spike. They work for us, but we’re always looking to learn more.

At DT, we’ve been able to run them on several occasions. In fact, when many clients come to us, it’s because they need that design thinking figured out before their dev team can move forward.

Spiking with CollabNet

One of our clients, CollabNet (a leader in the Application Lifecycle Management space) has a feature called Orchestrate, which links user stories to git commits to bugs, so your team can understand how certain events are chained together (think of it like “6 degrees of Kevin Bacon,” but for super complex development projects). For a new version of Orchestrate, much of the technical functionality had been previously determined…but no interface had yet been defined.


CollabNet’s Orchestrate interface, pre-design spike.

CollabNet brought us the challenge of designing a UI for Orchestrate that allowed time to be visually and intuitively represented (the previous version did not represent time). Their dev team had some ideas, but they really wanted to swarm on fresh solutions.

We ran a design spike for 2 weeks, during which we used Crazy 8s to draft a wide variety of design concepts: there were printer-friendly options, more detailed concentric circles, completely tabular representations, and a sitemap-esque style.

After a few meetings, we learned what worked (the sitemap-esque style easily allowed for time to be represented), what didn’t (concentric circles turned out to be confusing for users), and we narrowed our choices.

CollabNet, after design spike

The Orchestrate interface, after a design spike. A significant redesign, in only 2 weeks – made possible by extreme collaboration across the entire organization.

Ultimately, an intensive design spike that included Collabnet’s dev team, enabled us to concept and prototype a solution that got them back to their normal sprints after only a 2-week pause in development.

In summary: Stop, in order to move faster

So what have we learned about Design Spikes? Well, first of all, stopping work on development to collaboratively solve an important design problem doesn’t necessarily mean you’re going to ship later. In fact, you could be heading off much more serious headaches with usability, feasibility and customer support costs at the pass by tackling them now, before any code has been laid down.

Design Spikes are a time-boxed tactic to focus your team, rapidly solve unknowns, and get back on to your sprints. It’s best used when your dev team has a design hurdle that precludes them from moving forward on a backlog item.

The most important thing to remember with Design Spikes is that you’ll want to define a specific time range, get all members of your team involved, and generate a massive volume of potential solutions with the exercises mentioned above. Remember: when you’re in a spike, you’re not shipping…so swarm and figure it out!

What do you do when your dev team is at a design impasse? How do you search for ways to solve the design challenge without losing momentum? Let us know in the comments.

Surprised that a design agency like ours is able to seamlessly plug in to enterprise software teams for big results? Well, we’re a little different – by which we mean, we’re a lot different. See how we work.