Classic Scrum’s Achilles’ heel
One of the weak areas of classic Scrum, in my opinion, is the relative simplicity of the ideation phase. “What to build” is sometimes an arbitrary discussion during the Scrum Backlog building and Sprint Planning exercises, and too frequently I see people just listing up things “to do” in linear fashion, resulting in what Jeff Patton calls a “flat backlog”. Not enough thinking is put in to “what to build: why, for who, and how?”
The check-in question “Is this really what we’re supposed to be building?” is frequently pushed aside while everybody is absorbed in getting the Scrum up and running and maintaining the frantic pace of Sprints.
Patton’s User Story Mapping is one such approach to fixing this problem. It goes back to the crucial question, “Who are our users and what are we building for them?”, and applies a constructive yet laborious process to boil that down into a “user mapped backlog”. It’s a multi-day process with a lot of brain sweating and heavy team work, but it is a worthwhile investment of time and effort that I would recommend to any Scrum Product Owner.
Another powerful approach for ideation is Design Thinking.
While Agile originated from computer engineers and Lean from industrial engineers, Design Thinking came from, not surprisingly, designers – the creative bunch. That could be a reason why Design Thinking has long been a relatively weak influence to the management science community, despite being around since the 1980s.
But we are now witnessing the fusion of Design Thinking with other branches of Lean and Agile. And I think it’s a wonderful development: EVERYONE should be a DESIGNER, not just the creative bunch.
Here’s how Design Thinking flows. It’s a very creative process that forces people to expand and condense thoughts and actions in cycles:
As you can see there are many parallels to Lean and Agile – understanding the user is sacred, the spirit of hypothesization and experimentation is there, and the build measure learn flow is same.
What makes Design Thinking standout is that the “what to build” thinking phase is robust. It’s broken down in to three stages of Empathize, Define and Ideate, with excellent practical tools and concepts provided.
Design Thinking advocates “human-centered design”. In the first step of “understanding” what problem we are trying to solve, Design Thinking pushes us to a higher metacognitive state of learning: “empathy”.
Likelihood is that you are running or you’ve been called into a project that is trying to solve a user problem: the problem is not yours, but a user’s. You’ll need to get in to the state of mind of the user, hence the importance of “empathy”. You’ll need to suspend your own assumptions, dig for stories, feelings and emotions so you can immerse yourself in their values, and keep on asking questions (and challenging your assumptions) on what’s important and why:
- Speak to the users, develop personas
- Dig for stories, feelings, emotions
- Find out what’s important: ask why five times
- Observe and infer: empathy maps are a good way of note taking
- Suspend assumptions, challenge assumptions
- Think whole thoughts
Are we solving the right problem? Is the problem big enough?
If there is one lesson I’ve learned so far from my life as a marketer, it would be:
The customer’s “I want” is often not their real wants and needs
You can’t take customers’ “I want” at face value. That’s what they believe, but in actuality, people often don’t know what their real needs and wants are. Or they do unconsciously but can’t bring it up to the surface (this is where marketing becomes psychology!). And so, it’s the marketer’s job to find the undercurrent of real wants and needs. (And of course that’s an elusive, exploratory endeavor, hence we’re doing Lean and Agile to discover through experimentation, right? And, just like everyone needs to be a designer, we all need to be marketers too!)
In Design Thinking, the first Empathy stage is spent to gain deeper insights on the users’ wants and needs.
In the second Define stage we externalize these findings and re-examine the problem set. Putting them in POV (“Point of View”) and HMW (“How might we..?”) contexts are powerful ways of casting new light to the scattered many inputs picked up in the Empathy stage:
- Synthesize the learning from the first step into “needs” and “insights” discovered
- Use personas; different people have different needs, but patterns can emerge
- Reframe the problem with a problem statement, commonly known as “Point of View” (POV), reframe it again with a “How might we..?” (HMW) question
- Use verbs to write needs: “User wants to…”, “Use needs a way to…”
- Add insights you found that will deeper explain the needs: “Surprisingly…” “because…” “but…”
- The POV should be your unique design vision: POV should never contain any specific solution, nor any indication as to how to fulfill the users’ needs with your product/service
Achieved, experienced professionals operate as they “know what to do”, but unfortunately that modus operandi often become limitations to finding real solutions in complex problems. Applying what worked before is a safe play, but it treats old and new situations same – innovation needs exploration beyond the norm.
From “know-do” to “know-create-do”; this is the essence of all modern learning based management practices, including Design Thinking, Lean and Agile.
In the case of Design Thinking, the solution ideation stage comes in the third step, only after heavily investing in understanding the users and defining the right problem to solve. As a matter of fact, Design Thinking suggests to do brainstorming, everyone’s favorite creative routine, not in the beginning but only in this third stage. This makes a lot of sense, because immediate brainstorming for ideation will entail a lot of assumptions, and that would probably introduce unwanted biases.
This stage is very visual with a lot of sketching done – you might think you’re not an artist and the best you can do is draw stick people, but we’re going after volume so don’t worry! Radical ideas are born out of the frenzy of pulling things out of everyone’s brains:
- Now’s a good time to brainstorm – but with good facilitation
- Sketch to ideate: keep on popping many radical ways to meet the user’s need
- Go for volume: this is time for idea generation, not evaluation
- Not just words: use diagrams, arrows, stick people
- Share your ideas with the users: test it, capture feedback, reflect, iterate to generate a new solution
Ideate variation from Design Sprint
Another great reference for ideation is the Tuesday on Jake Knapp’s Design Sprint.
Design Sprint is Google Venture’s 5 day adaptation of Design Thinking. It is incredibly well structured, super rigorous and full of amazing hacks and tools that will drive people nuts but find order among chaotic creativity.
Design Sprint on Monday uses a somewhat different approach to cover the Empathize and Define stages in Design Thinking, but achieves the same objective of trying to define and find the right problem to solve.
Design Sprint on Tuesday starts yet again with more research – you still don’t get to jump into solution ideation! The first task of the day is to “steal” ideas from other industries and different domains and give “Lightning Demos” to the team. The “stolen” ideas are captured on a whiteboard, and by the end of the Lightning Demo, it should be covered with ten to twenty ideas.
With the findings from Monday and the ideas from the morning, Tuesday afternoon is spent on “sketching solutions”. Design Sprint is cautious of the drawbacks of “group thinking” so it doesn’t really allow unregulated brainstorming. Instead, it rotates between group critique and individual work dubbed “work alone together”. The solution sketching is done individually but in parallel with the team in four steps (“Four-Step Sketch”):
- 20 min to “boot up” by taking notes on the goals, opportunities, and inspiration you’ve collected around the room
- 20 min to write down rough ideas
- 8 min for “Crazy 8s” – rapid sketching exercise for exploring alternative ideas
- 30 min to draw your solution sketch – a single well-formed concept with all the details worked out
Crazy 8s is really cool… I would highly recommend the book to any Agile practitioner, it’s full of crazy ideas that would be great fun to try with your team!
Prototyping and Testing: consider a hybrid approach with Scrum
The prototyping and testing phase of Design Thinking (and Design Sprints) is robust and practical, and no doubt it is an extremely productive process.
But the end state of Design Thinking does not have to be rapid prototyping. You can instead integrate the findings from the Empathize, Define and Ideate stages back into your normal product development routine.
My preference is to go back into the rhythm of Scrum after the solution ideation stage:
If you are a team already on a Scrum routine, implementation of this hybrid approach is actually seamless and easy. You can incorporate the elements from the Design Thinking Ideate stage into what your team will be building in the next Scrum Sprint by populating the building blocks into the Sprint Backlog and the Sprint Plan (To Do items on the Scrum board). And thereafter you start the Sprint and go into the rhythmic team routine of daily Sprints. At the end of the Sprint, you do the customary Sprint Review and Retrospective meetings, and if all is going well with no major change to the scope of the product build, the team continues on to planning the next Sprint.
If for example the user testing during the Sprint suggests that your product vision is deviating from the customer needs and wants, or your stake holders and partners raise similar thoughts during the Sprint Review, you can consider stopping the clock and going into another round of Design Thinking.
A fresh take on understanding the customer, defining the problem and ideating solutions will give a much deeper insight on making an informed decision on persevere, tweak or pivot.
Design Thinking + Scrum makes a lot of sense
There are many advantages to the hybrid Design Thinking + Scrum approach:
- Design Thinking can help teams find the right thing to build, better
- Scrum can carry Design Thinking’s discoveries further
- Having Design Thinking on standby between Sprints will let teams regularly stop and ask the enterprise level reality check question, “Hold on, are we really building the right thing?”
- Design Thinking makes everyone a designer (and marketer)
Design Thinking and Scrum inherently have different paces. Design Thinking’s intensity is exhilarating, while Scrum’s cross country running like pace gives you the feeling that you are conquering terrain and gaining mileage. That demonstrates that they are tools built for separate purposes.
Meanwhile, they beautifully overlap in an extraordinarily complementary way. They both are Agile approaches sharing the same “relentless pursuit of customer value creation” spirit. Why not combine both and use it to your team’s advantage?
Give it a try, it makes a lot of sense.