Design Thinking + Scrum = ?

In 2015, I worked with a team of seven amazing students and Olin’s new Library Director, Jeff Goldenson, on a summer design/build project called the “Olin Workshop on the Library” (OWL). The project was about designing new life into Olin’s library space and the resources it provides to students. We started with a mantra (a la Guy Kawasaki): “Make Olin’s culture manifest.” It was the highest performing team I’ve ever worked on, and at least part of that had to do with the process we committed ourselves to 100%. This post was originally published in 2015 and is a reflection on that process and an effort to distill some key lessons learned.”

A few years ago, after attending a training led by the man himself I became a “certified Scrum Master.” For the uninitiated, Scrum is an iterative product development and management framework that grew out of the Agile software development movement. One of the greatest strengths of Scrum is its ability to handle significant uncertainty. In the structure of Scrum, work is determined by a “product backlog,” proceeds in finite (typically 2-4 weeks) time periods (“sprints”), and is evaluated by relevant stakeholders at the end of every sprint. This iterative approach makes it very hard to veer off course for too long before the next opportunity to self-correct arrives in planning the next sprint. Combine that with mechanisms for making work and process transparent (daily stand-up meetings, Scrum boards, retrospectives), and you have a very powerful tool for pushing any project forward.

At Olin, design (and design thinking) is one lens through which we view engineering. If you’ll allow me a gross oversimplification, design (as it relates to engineering) is about situating the technical work typically associated with engineering in the context of the people, organizations, societies, etc. whom it’s intended to benefit. More specifically, elements of “design thinking” often include empathizing with users, divergent thinking (and an associated deferral of judgment) in search of solutions, and a bias toward action, i.e. a bias toward doing/prototyping/creating (in contrast to discussion). We believe applying design thinking leads to better and more effective solutions to problems than engineering analysis alone might otherwise do.

So what do these two seemingly unrelated approaches have to do with each other? On the surface, they are very different. Scrum is a prescription for how to work on a project. Plan in chunks. Make work visible. Fix time and quality, let scope vary accordingly. Design thinking is a methodology for exploring and generating ideas, understanding users, wrestling with ambiguity, innovating. Over the course of our work, however, our team has found that the two tools complement each other quite nicely.

One aspect of our library reinvention project that makes it distinctly different from a corporate or industry project is that the team gets to decide both what work to do and how to do it. Design thinking is great for the first part, that is, what work to do. Each OWL team member is intimately familiar with Olin’s community and its needs (but many still have differing perspectives and opinions). Consequently, identifying needs, proposing solutions, and developing and testing prototypes comes quickly. We then take those solutions and use them to populate our product backlog. Instead of trying to quantify the business value of a particular task or design, we focus on those tasks that deliver the highest impact to the users of the space and services provided by the library.

If design thinking helps us understand what work to do, Scrum gives team members the autonomy to decide how to do it. What’s interesting to me is precisely how Scrum enables team members to work autonomously. Granting team members true autonomy requires significant trust. Scrum (and a willingness to assume each team member is doing her best) helps to  build that trust for the following reasons:

1. The team has agreed on an ordering of tasks based on impact.
2. The team has agreed how “large” each task is.
3. All work is visible on a shared (Trello) Scrum board (we always know what a given team member is working on).
4. Individual members are held accountable daily in the standup meeting.
5. We know we will collectively review our work (and our process) after the end of each 1-week sprint.
6. We will try to improve every single week.

On the face of it, these characteristics seem like common sense. And maybe they are. But, based on my experience with this team, I can say that being truly committed to following the process helped enable this team to complete work I would never have imagined being possible in a 9-week project.

I’d love to be able to make the assertion that design thinking + Scrum is some magical recipe for success in all projects, but that would probably be overreaching just a bit. What I can say is that the combination of the two processes is decidedly stronger than either alone. For creative projects facing significant ambiguity, design thinking is great for generating and exploring solutions quickly while Scrum excels at ensuring high-quality execution of the work. In particular, its iterative nature dovetails nicely with design thinking’s bias toward action. Weekly (in our case) assessment and replanning enabled better solutions to emerge and be developed more thoroughly while lower impact approaches were de-prioritized. As a team, we’re quite happy with our results, but I’d be interested to hear about your experience applying Scrum in creative design contexts.