Sprint Day Three
First, if you haven’t read the Sprint book, close this page and go read it. It’s worth it. You’ll thank me.
Then, go and read some reactions from the rest of my team about Monday and Tuesday. Or read about the whole week.
Ready? Ok, let’s go.
TL;DR, on Wednesday of your Sprint week:
- It’s critical to get on the same page about what you’ll prototype on Thursday
- One prototype vs several competing prototypes is a continuum, not a dichotomy
- Be aware that your prototype may not fit cleanly in a linear storyboard
- Don’t forget your Stitcher
The Story:
Interplanetary politics is messy business, or so we hear.
But going into Wednesday we had some sticky-note sketches on how to help out: we clearly need to build a new warp drive. Or maybe a subspace communicator. No, it was a universal translator. Phasers? Definitely a possibility.
Whatever it was, we knew a lot more than we did when we started the Sprint on Monday: we had some concrete, testable ideas. On Monday, all we knew was that “sometimes alien cultures don’t get along.” Ya think? By Tuesday, we’d heard that the Andorians were having trouble with their existing universal communicators, the Klingons cared a lot more about making themselves felt than heard, and that everybody needed faster transport for emissaries. And maybe more efficient communications could help somehow.
At the start of Wednesday, we had blueprints for new devices that would solve those problems… because… technobabble. (And that’s where the analogy starts to break down.)
We had different solutions to many surface problems, which may each be components of our underlying problem.
Contrast that with many of the examples from the Sprint book, where the teams started with a much more well-defined goal, and by Wednesday they at least knew what form their prototype would take, categorically speaking. They already knew they needed to build a more intuitive interface for the universal translator (because that’s where they started), and by Wednesday they knew it would involve either a new getting-started tutorial, or an interactive setup process.
We started really broadly, so we had a lot of ground to cover in order to end the week with reactions from real users, interacting with a “real” prototype.
So far so lost. We had sketches. But what then? Which of those parts was most critical? What could we leave out? How should we figure out what the Minimum Viable Star Ship (MVSS) was?
Wednesday:
The first step, by the Sprint book, was to put all the anonymous sketches up on the walls then walk around and ponder them in silence, commenting via sticky and informally voting via dots. I particularly liked someone’s idea of adding fusion coils to the warp drive — but based on the scant dot votes, I was alone in that.
We progressed to analyzing each sketch as a group, whereupon each sketcher revealed him-or-herself and clarified their intent for us. We then moved on to the formal voting, for which our Decider (or Admiral, if you will) joined us.
She used our votes as advice, but the ultimate decision was up to her. That’s important, since she had (and has) veto power over everything that comes out of the Sprint. Better to know upfront if something’s not going to fly.
Our Decider had a busy schedule and could only join us briefly, which added strict time constraints. Here we came to the first challenge on Wednesday: ferreting out what our Decider really wanted us to test. Was it the new language module for the universal translator, or was it the fusion coils that could provide the needed power for the more advanced analysis? They were both on the same part of the sketch. And if it was the fusion coils, why didn’t she also vote for those in the context of the warp drive? It took some careful prodding, but we ended with a list of key features we wanted to test.
The Sprint book recommended either a single prototype or a “rumble” of competing prototypes. What we had was perhaps somewhere in between: a feature rumble. These features were complementary (all part of a single prototype), yet loosely-coupled and competing. We could get different feedback about each.
Our second challenge was figuring out how to fit all of these features into a coherent, testable whole. In hindsight, the constraint of creating a storyboard had us spinning our wheels for a while. We were trying to fit a nonlinear hub-and-spoke model into a sequence of boxes, which lead to unnecessary arguing.
“Which feature should come first in the flow?”
That question was distracting at best, because the real answer is: “We should let our customers tell us.”
The last step on Wednesday was choosing a platform to build the prototype on, and divvying up the work by choosing our roles.
The prototype platform was tricky for two reasons: we needed something that would be easy to guide remote interviewees through. (Our customer base was a select group of very busy people.) Second, there wasn’t a tool that we all simultaneously had experience with and easy access to. Powerpoint and Keynote were out, given our Mac/PC split.
We settled on a mockup tool that did the job well enough, but in hindsight was hard to set up for remote people, and only two of our team members had experience with it.
On Thursday, the workload in creating the prototype ended up being rather unbalanced. The two people who knew the mockup tool ended up doing most of the work, while everyone else scraped together the odds and ends. That may be difficult or impossible to fix, even with hindsight, but this was also the first Sprint for all of us.
Lastly, no one took a strong Stitcher role to bring everything together, and we felt that absence on Thursday: for a while, the prototype was hodgepodge, and any consistency was accidental. It wasn’t until later in the day that we all rallied on a shared vision. Lesson learned: choose a strong, opinionated Stitcher in preparation for Thursday.
But all in all, Wednesday was a success: we figured out what to prototype, and had a good plan ready. Not too shabby for an inexperienced Sprint team.
The Outcome:
Fast-forward to Friday afternoon: we had a much clearer idea of what users wanted, and what real product to build. It was astonishing how quickly we were able to take a nebulous idea, condense it, solidify it, and test it. That’s my key takeaway from the Sprint process: how to make quick yet well-reasoned decisions, in service of getting authentic feedback as fast as possible.
Engage!
