Incorporating Design Thinking into Lean Agile Sprints

Josh Frank
Revelry
Published in
4 min readAug 2, 2018

At Revelry, we infuse Design Thinking into each aspect of product delivery. Many people wonder, “What’s the difference between Design Sprints and Design Thinking?”

Design Sprints are intensive, structured learning activities.

The purpose of a Design Sprint is to produce shared understanding, hypotheses, and minimal forms of testable solutions.

Agile Sprints are equally intensive, structured iteration activities.

Each Agile Sprint produces a usable, testable unit of software.

We’ve weaved design thinking into iterative product development — our Lean Agile Sprints — in order to challenge assumptions within an existing product creation process.

This helps us identify opportunities for improvement while still performing necessary builds. It’s too easy to drop the learning aspect from Agile when the default is to build. We believe in the value of the principles, and our innovation partners benefit from the quick wins that come out of slowing down once in awhile.

We can utilize the principles and exercises of a Design Sprint to enhance the effectiveness of the product over a series of our one-week, Lean Agile Sprints. It’s design thinking, the Revelry Way.

For the full blog post on this topic, check out: Incorporating Design Thinking into Lean Agile Sprints, originally published at revelry.co on August 2, 2018.

Debriefing: Gather “How Might We” Statements

When we apply design thinking to an existing product, we can fast-forward a lot of market learnings.

Together with our internal team and the product owners, we utilize the technique of listening and documenting potential opportunities or pain points under the framework of “How Might We”questions and statements.

How do we craft a good “How Might We” statement?

It’s not too broad: “How might we build a better house?” generates too many unhelfpul ideas.

It’s not too narrow: “How might we build a door that swings inward and outward?” produces a solution within the question.

It’s just right: “How might we improve traffic flow in high-use areas of the house?” targets a segment and makes room for possibilities.

Voting and Sketching: Explore and Create

In Week Two, we quickly focus our efforts on prioritizing problems, challenges, and opportunities. This helps us move quickly to the key exercise that will lead our exploration of solutions.

We utilize structured a mechanism to surface the most impactful “How Might We” statements, and then we move on to Ideating on two or three of them.

We utilize Mind mapping, “Crazy 8s”, and Story boards in order to get to some of the best solutions for the problems we identified.

User Testing: Experimenting with a Prototype

Three weeks into the process, we’re ready to select users for prototype testing. This prototype does not need to be (read: shouldn’t be) a piece of usable software. We sketch a more robust, but still lo-fi, walkthrough of what the User Interface will look like.

Sometimes, the two final solutions merge into a single solution. But it’s perfectly fine to present two testable prototypes for your selected users. This might add a week to your design thinking exercises, and that’s ok. It also adds highly valuable learnings to your agile product development process.

Ideally, you’ll aim for a minimum of 5 people for testing and reviews. While we’re not following a strict Registered Trademark Google Design Sprint, there are particular elements that require purity in order to work. And one of those elements is the user test.

The Role of the Whole Team

Design thinking exercises work best when cross-department team members participate. It’s not always obvious to an engineer how product ideas are generated, and “doing UX research” is very rarely a task performed by a developer. This process allows the product makers to think and learn more about the unique needs of their users.

So gather the designers, the developers, the QA testers, the marketers.

Help your team develop and expand their skills. They’ll learn how to prepare for and conduct a user test. They’ll tap into creative techniques through the constraints of prototyping. And, their input can inform how to arrive at better solutions or improvements to pieces of the process that no one else had thought of. Improving the way we gather and organize notes, lending structure to preparation for the activities, and disseminating learnings into shared knowledge are all ways we’ve benefited from having multiple Revelers participate in our exercises.

In a very fast paced Lean Agile format, our scope is often very limited. And we can forget to stop and be creative or mindful. So making space for exercises like this allows the team to open their minds and let their thoughts go to far-off places in terms of problems and solutions.

Challenges and Tricks: Making Room for Design Thinking

Agile software development is an action-oriented process. It’s easy to fall into the trap of expecting action or a really solid outcome when launching design thinking exercises.

Agile is also learning, so be sure to give your team credit when progress is made, even if progress during learning doesn’t look the same as progress during a build.

Check out the original post for more

There are a lot of challenges to weaving Design Thinking, mini-Design Sprints, and other user-focused exercises into the lean agile sprint process. I address them, and provide an array of tips, in the original post on Design Thinking in Lean Agile Sprints.

--

--