Sprint (the book), is a true phenomenon. It describes a method developed at Google Ventures to solve big problems and test new ideas in just five days. Published in March of 2016, the book has perfect ratings on Amazon.com and is a New York Times and Wall Street Journal bestseller.
After reading it, I was in violent agreement with most of the author’s recommendations.
At the same time, it advocated unusual techniques and seemed a bit too prescriptive.
Despite those reservations I, I jumped at the first opportunity to try it.
And it worked seamlessly.
The experience was so positive that, after a few sprints, I started to wonder about how I could apply parts of the process to solve smaller problems — without the need to devote an entire week to it.
Recently, I have had the opportunity to do just that, working with my team at data.world.
At data.world we strive to operate like an exponential organization:
“An Exponential Organization (ExO) is one whose impact (or output) is disproportionally large — at least 10x larger — compared to its peers because of the use of new organizational techniques that leverage accelerating technologies.” ― Salim Ismail
As such, we value techniques that help us collaborate more efficiently, validate our hypothesis, and converge on only the highest-value initiatives.
We are adepts of the Lean Startup approach, and that guides our product development process.
The exception? Our core platform product.
In a context of that product, where quality and robustness are not negotiable, the Lean Startup concept of Minimum Viable Product does not translate to cheap. In addition, our platform team is composed exclusively of engineers and our customers are other internal teams. Prioritizing our roadmap in a user-centric way is not trivial.
When asked to organize a day-long planning meeting, I decided to try a modified and much shorter version the Sprint process.
How it was adapted:
- Duration — Six hours (instead of five days)
- Goal — Determine the next highest-value feature to build and produce a sketch for its design
- Team composition — Engineers (exclusively)
- Activities — Only those corresponding to the first two and a half days of a regular sprint; compressed and prioritized based on experience
It is true that the most valuable outcome of the Sprint process is the validation of new ideas based on real user feedback. In our timeframe, that goal was unattainable. However, the process is rich with strategies that help counter many of the most serious shortcomings in collaborative problem-solving. Problems such as…
Anchoring
“Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the anchor) when making decisions.”— Wikipedia
Most people will come to a collaborative problem-solving exercise having already spent time thinking about the challenge at hand and how they would tackle it.
In most cases, the first solution that sounds reasonably good to the group is the one that will be refined and accepted. Yet that solution will be heavily reliant on one person’s perspective — a potentially costly limitation.
The first steps in the Sprint process encourage the team to think broadly and examine the context of the problem before looking for a solution. For example, by:
- Thinking optimistically in terms of what the world would look like once the problem is successfully solved, and translating that into a Sprint goal.
- Thinking pessimistically in terms of what participants do not know or fear and turning that into Sprint questions.
- Understanding the actors, activities, and outcomes in the context of the problem to be solved and translating that into a process chart (Map).
- Interviewing experts and capturing their insights in terms of How Might We questions.
These steps are intentionally designed to produce questions, not answers. It invites participants to examine the context of the problem from many complementary perspectives. It brings the team to a common level of understanding that will inform their proposals and forces them start afresh; free from any anchors.
Scope creep
Whereas problem-solving can be confused with brainstorming, it is very different in that a tangible outcome is demanded when problem-solving. Encouraging ideas is important, but narrowing on a target is paramount. The Sprint forces difficult decisions to be made in a pragmatic way. Clear-cut decisions protect participants from scope creep as they move from one milestone in the process to the next, guaranteeing that at least one whole solution will be produced at the end of the cycle.
The secret is this: The Sprint encourages decisions that are participative, but not democratic. Participants cast their votes, but the Decider makes the call. After all, democracy may feel good, but it does not work well in business. At the end of the day, projects are only seen through completion when their sponsors (Deciders) are fully on board. In fact, it is often more rewarding for the team to back their leader going in a different direction — knowing that he has acknowledged all votes — than to see their ideas accepted for a project that never sees the light of the day.
Dominant personalities
When you strive to hire only the best of the best there isn’t anything more disappointing than keeping your talented colleagues from freely expressing their opinions and applying their skills. In collaborative problem-solving, the risk of wasting such an opportunity is high. Especially with the tendency of those with dominant personalities to overshadow others.
The Sprint promotes notions that create an equal opportunity for participants to express their thoughts. In many cases, it resorts to silence to accomplish that. Specifically when:
- Capturing insights; during experts interviews
- Working on sketches
- Reviewing each other’s sketches
- Voting
When everyone talks, discussions go in circles. Someone shares an idea; the group critiques it; someone tries to explain; someone else has a new idea. Besides shutting valuable people off, this back and forth leads to loss of useful information.
The silence, of course, will be broken to create space for critique, and for making decisions; however, at specific times and in proper order.
Infinitely adaptable
There is no question that the Sprint process is most valuable when used the way it was intended. However, it would be irresponsible to limit its applications like that.
The many techniques that make it so effective can and should be mixed and matched to make collaborative problem-solving, well, solved.
