Why Design Thinking + Scrum Makes a lot of Sense

Read the original article

Watch the Design Thinking primer

Take the Scrum Crash Course

Practice Rapid Design Thinking

Transcript

Hi, I’m Coach Takeshi. As some of you may have already read from my 2018 viral article, I am a big fan of the hybrid practice of Design Thinking plus Agile Scrum. In this video I’d like to explain why.

In doing so, first, I’d like to take us back to remind ourselves why we do agile.

1911, Taylorism and the history changing success of the Ford Model T factory. Scientific Management all the way to Waterfall project management — they have for sure brought us the many miracles of modernity, and we should be thankful about that.

But the ills of the many dysfunctions and unhappiness we see in today’s world is brought from the simple fact that we are tackling new problems and challenges with old tools and methods that no longer work. And we’ve known this for decades and we still can’t fix it.

Two things. First, the old way of teamworking is no longer working. Gone are the simplistic days where highly educated leaders make decisions, pass down instructions, and workers just focus on execution. Taylorism dictated the separation of the decision makers and the doers. In contrast, in an agile team everyone is a decision maker and a doer. Why? Because in today’s fast-paced world and complex marketplace, the people who are closest to the customer and technology are in the best positions to make decisions. So, from fixed “leader — follower” model, to dynamic we lead each other, follow each other model; I follow you because you have the best information and experience to do this part; and in turn I’ll lead this part because I have the most knowledge and insight here. From control and command to self-organized, autonomous teams; we lead each other, follow each other. We are all each decision makers and doers; this is reason number one of why we do agile.

Second, we experiment and iterate. Because the old linear deterministic way of waterfall project management does not work on complex adaptive challenges where there are a lot of unknowns. So we don’t do big predict-all-the-way-to-the-end planning like in waterfall, and instead do small hypothesis based planning and run small experiments and pilots to build products, services and solutions in increments. Then we learn from those increments, adapt our plan and iterate until will crack the challenge. So experimentation and iteration, learn and adapt; this is reason number two of why we do agile.

And Design Thinking and Scrum are both super smart practices that embrace these two reasons of why agile.

Okay, so that was level 1 explanation, why agile. Now on to level 2 explanation, why Design Thinking PLUS Scrum? Why not Design Thinking OR Scrum? Starting to get interesting, right?

Both are great, and if deployed properly and thoroughly, either way you’ll get solid results.

The thing is that in agile, there’s no one magic bullet that works for everything. That’s the reason why agile is not a methodology. Design Thinking and Scrum are both great frameworks, but they each have their shortcomings.

Back to decision making and doing, or to rephrase, the separation of thinking time and doing time. David Marquet’s use of “blue” and “red” color coding to separate the think-do rhythm is pretty catchy so I’ll use it here. He’s the former nuclear submarine commander with the famous “Turn the Ship Around” video and book, and recently he wrote about this blue work — red work rhythm in his book “Leadership is Language.”

In Design Thinking, “empathize, define, ideate” is blue work, i.e., thinking time. As a matter of fact, “ideate” is sort of like the watershed between blue and red, where the “prototype” stage is red work, i.e. do time. The test stage is again the watershed between red and blue, going back from doing time to thinking time, by learning and adapting from the test results.

In Scrum, Sprint Planning is blue work, thinking time, and the development days, typically between three to eight days for one to two week Sprints, are for red work, doing time. Then Sprint Review and Sprint Retro is again blue work, thinking time to inspect and adapt.

Now between this red and blue work, I see the typical weakness of Design Thinking in red work, i.e., lightness in execution, and likewise for Scrum, weakness in blue work, i.e., possible lack of depth in thinking and designing of what to develop. I’m sure many Design Thinkers and Scrum Masters may disagree as either approach works when it works. And I agree; they work when they work, but I also see structural weaknesses in both frameworks which can be addressed by their complimentary strengths.

I find Design Thinking’s prototype stage sometimes treated overly simplistically, and often wish if the team can invest more time in building the prototype product with less haste and more robustness. This is the part where Scrum shines; the Product Backlog and Sprint Backlog are translations of the master idea of what to develop and how, and the rigour of daily Sprint work with the daily stand-ups, Kanban board, the discipline of Definition of Done, all of these are practices that contribute to developing powerful increments of a product.

Meanwhile, many Scrum Teams fall into the trap of Sprint Planning as a flow exercise. Sprint Planning is for stopping and thinking. It’s for taking the results from Sprint Review and Sprint Retrospective and rethinking, what to build, why and how. “Hold on, are we building the right thing?” — not all Scrum Teams ask this critical question every Sprint Planning.

Now if we do, for example this Rapid Design Thinking exercise during Sprint Planning, literally we can go back to the drawing board, start again from reimagining who you are developing the product for and why, it would be a powerful way to keep the focus on developing a product of real value to the customer

.

From a behavioral perspective, Design Thinking can sometimes be a trap for analysis paralysis, i.e. getting stuck in blue work in perpetual thinking loop, and not being able to do things and produce valuable output. On the other hand, despite the built-in Sprint Review-Retrospective-Planning time for blue work, Scrum can give the hamster wheel like never-ending feeling of red work, because of the misnomer labelling of Sprints.

Some people think too much and have difficulties going in to do mode. Many others are perpetually busy for the sake of being busy because they’re too scared to stop. Teamwork is same. Just as life, we need consciousness for a good balance between thinking time and doing time. Try Design Thinking + Scrum for your teamwork. It makes a lot of sense.

Learn How To Do Design Thinking + Scrum

Read the original article:

Watch the Design Thinking primer:

Take the Scrum Crash Course:

Practice Rapid Design Thinking:

This article was originally published on: https://agile-od.com/lean-agile/why-design-thinking-plus-scrum-makes-a-lot-of-sense