This would be an interesting book review because not only will I be reviewing the book itself, I’ll also be reviewing the process which the book writes about – the Sprint Week. As part of my LSE MISDI course, we were put into groups and locked (not really) in a room for a week to execute the Sprint Week principles and then some. This was also 50% of the grade for one of our classes. Was this what Jake Knapp was thinking about when he wrote this book? Probably not. But heck if anyone ever followed a book to the tee, we got some interesting results from the process and that’s what I’ll be writing about today.

The Sprint Week is a process developed by Google Ventures to approach designing solutions for problems in a semi-structured and ‘agile’ way. Rather than start brainstorming solutions on Day 1, the Sprint Week focuses on using concepts of convergence and divergence of ideas (almost at a regular pace) to focus and stretch possibilities respectively. A Day by Day breakdown of the Sprint Week can be found here, but essentially the process follows Problem Design, Solution Generation, Storyboarding and Decision, Prototyping and Testing. It’s a simple enough framework and the book goes through the nuances and best practices for each day more thoroughly. Heads up, you’re going to need tons of paper, markers, stickers and flat surfaces for this week. And snacks, lots of snacks.

Our Sprint Week was developed in conjunction with Roland Berger, with the provision of VISA’s corporate goals as our problem environment. Essentially, we had to consider how to help VISA achieve its goals of millennial outreach and merchant buy-in. SPRINT instructs to start with setting goals, key questions and assumptions to consider, before developing a flowchart of sorts to map out how the goal can be achieved in broad terms. The MISDI program replaced the flowchart with a rich picture, something included in the wider Soft Systems Methodology we employed, to identify where problems and opportunities lay.  It’s a difficult thing to do initially because you’re trying to capture complexity without making your picture complex. It was also difficult (and this is a critique of the program rather than SPRINT) because payment systems are a whole world of knowledge that very few have a prior understanding on. So rather than mapping something out, our team had to take a timeout to research, clarify and understand before coming back to map the system out. I assume that SPRINT participants should have an understanding of the problem scenario before coming into the week and should have done basic research to hit the ground running – a key prerequisite not afforded us and that I’d find very useful for future iterations.

After converging on the problem, it was time to diverge on the solution. SPRINT employs a series of masterful and ‘fun’ activities that allow participants to stretch the possibilities of what solutions can look like, drawing from both inspirations as well as just permutating through ideas (through their Crazy 8s activity). Eventually, through the use of stickers and post-its, participants vote and comment on ideas and avoid opening areas of conversation. This is almost an endemic part of the process – conversation and debate distract from the product which is ultimately a perceived object and so if another participant can’t immediately understand your point, it’s not held as valid. There are opportunities for discussion but they’re timed, facilitated strongly and meant to be purposeful. This form of directed teamwork is highly effective but requires a reframing of people’s points of view especially if they’re used to dominating airtime. There are only two main roles in the group, the Facilitator who manages time and process and the Decider who makes executive decisions. Everyone else is held to an equal and fair standard of contribution.

The next step involves attempting to converge back on the proposed solution, and in order to do that, the team must agree on a storyboard that captures their vision. There’s a lot of references back to previous documentation such as goals, rich pictures, and solutions, to identify exactly what the ‘user’ aims to achieve and how they interact with our product to achieve them. This inspires the product and the features that must be embodied for success. This became an important by-product of our process as we kept using it to focus our features and not get distracted by next-phase or frivolous features.

Finally, we develop the prototype. I haven’t put a picture of the prototype just because it used theoretical VISA branding that I wouldn’t want to misrepresent, but I used Marvel, a prototyping software I love, to build it out. This was what SPRINT directs you towards, even suggesting paper and pen prototypes as equally satisfactory in achieving the goals of this stage. What was additional for our program was the inclusion of Unified Modelling Language schematics to describe our system. We had to produce a Use Case Diagram, Class Diagram and the bane of my existence, the Object Sequence Diagram (OSD). I can appreciate the purpose of the first two types of diagrams, but I could not find any relevance nor use of the OSDs. In fact, I had a candid chat with a friend who used to work in an IT firm in India that handled outsourced work and he remarked how business executives would use OSDs to communicate the mechanics of the system  to little avail. The IT folks would simply ask for the specs and iterate through it instead. In fact, quite ironically, OSDs seemed quite inhibitive to the agile spirit of the week. It seemed more like a tool for business majors to feel like they have a grasp on the system (which they probably don’t, let’s be honest) and something I rarely see myself employing in the future. Then again, I’ve caught myself eating my own words before, so I’m open to being proven wrong.

All in all, at the end of the long and tiring week, our pretty international team came together to develop a very impressive product that we were proud of. There were a lot of times where we had to trust the process and stick to it but when we saw our final product, we knew it had been worth the effort. There’s definitely gaps and inadequacies in the SPRINT process, especially since it was augmented and adapted so much for a program of 120 people in a room with not that much space. The combination of being graded for it and having to manage friendships within the program also altered the preferred dynamics of the process, but these are factors that cannot be escaped within the consideration of the course. I think the SPRINT process is a great foundation for teams and organizations seeking to solve complex problems in a structured way – it brings a design mentality to engineering and the book is a very reliable and useful companion for the team. In fact, one could even think of the book as an extra member, providing the structure necessary to navigate the complexity of the target problem.

Here is my review of the book:

Readability: 5/5

Intellectual Stimulation: 3/5

Perspective Shifting Capability: 4/5

Would I Recommend? – If you’re in the design/tech/engineering space, absolutely!