In October we attended Google’s annual Sprint Conference, an event that brings together the people with a shared affinity for design sprints. I attend each year to learn and become inspired by others’ stories of leveraging design sprints to lead and instill change.
Google Sprint Conference in San Francisco (October, 2018)
Attendees share stories of using design sprints to help break down communication silos, to step into new leadership roles, and to synthesize ideas the might lead to the company’s next successful innovation. The event is a celebration of all the good design sprints can do when applied correctly.
There’s so much to celebrate. Story after story shows how sprints have been a catalyst in sparking transformation—but just as exciting as these movements can be, they can also die a fiery death if the right container isn’t created to support the organizational change that’s required for them to be accepted.
During the Sprint Conference, in one-off conversations, a few of us cast worries about design sprints becoming overhyped, oversold, and ultimately discarded. The worst thing that could happen to sprints is that a sea of experts begin selling them to company leadership as a silver bullet: a tool to be applied, liberally, with guaranteed results in a week or less, regardless of the culture and conditions surrounding the sprint.
So in an effort to help you and your team avoid the mistakes I’ve made, understand the journey you’re embarking on, and then activate a sprint-powered design culture, I’ve created this 3-part series called “Scaling design sprints.”
This topic will be broken out in a series of three posts:
This article: Putting design sprints in perspective
Article #2: Overcoming the two biggest initial design sprint challenges
Article #3: Evangelizing and scaling sprints at your company
Putting design sprints in perspective
In this first article, we’re going to be super negative. Hang with me. It will all be OK.
If you think about it, design sprints currently have all of the same velocity and hype as agile did several years back. Now that we’re seeing the agile excitement wear off, the once-powerful tool is often regarded as hype gone cold.
So my goal here is to dig up dirt on agile so we appreciate what not to do with its new and shiny cousin, design sprints.
For context, I owe a lot of my earlier career success to installing and scaling agile methods within the software development teams I managed.
Earlier days of agile
In the late 90s through mid-2000s, if you mentioned the word agile you got hired or promoted. True story. The problems, however, started when people started selling agile as a wonder drug.
In the software development world, people were sold on agile and the belief that it directly correlated with more features shipped in less time, while eliminating the need to document anything. It also cured cancer and eliminated world hunger.
Given its success, every consultant under the sun jumped onboard, adding agile to their toolkit. And as larger companies with more complex business challenges and working environments picked up agile, new flavors of agile were created to help scale it up for mid-market and enterprise organizations.
I’m sorry for the headache you now have.
Today, many have lost their appetite for agile. In fact, if we were to plot the affinity of agile over time, it might look something like this…
A groundbreaking tool like agile has taken many a blow simply because people don’t take the time to understand it and use it properly.
And so my fear, and the fear of others who have seen design sprints produce unmistakable value, is that design sprints will similarly become over-prescribed as a generic painkiller. At that point, scaling design sprints will be the least of our worries.
In the grand scheme, agile has radically improved the ability for companies to ship. There are countless companies still learning about and adopting versions of it to best suit their needs. And there are equally countless success stories of agile transformations. The problem is that today, the right mindset, people, and methods to win with agile are harder to discover.
Therefore, the goal with this series is to help you approach design sprints in a way that gives them the best chance at scaling within your organization.
In the next article in this series, we’ll explore how to get started with design sprints so that you make a strong first impression, and build a solid foundation for future sprinting.
by Jay Melone
Jay Melone is a Partner at New Haircut, a product strategy and training group based in NJ. They help product teams fall in love with the digital solutions they make, and how they make them. They offer design sprints, problem framing, and outcome-based roadmaps as part of their 4-week Product Transformation Program.