The Difference Between Agile and Design Thinking

It’s been over a decade since Agile methodologies took over the world of software development. While large corporations are often still enmeshed in the structures of old, startups and other tech companies have learned another way. Agile has seen such an incredible success, increasing team output by as much as 28%, that savvy project managers are beginning to apply those Agile principles to disciplines outside of development.

But meanwhile, other disciplines have taken their own trajectories towards innovation. Design Thinking is one of those paths. It’s made its way up the ranks through project management and design departments. In the last five years the tech industry has seen major companies taking on their own versions of this process, from Google to IBM.

Now, the two schools of thought of Agile and Design Thinking are beginning to intersect. Companies are being faced with a new conundrum: a difference in language. One of the biggest reasons for failure in software development is communication breakdown. If one department is sprinting while another is diving into a workshop process, it can cause chaos—until you realize there is no wrong way to embrace innovation. These philosophies are really sets of tools and processes, and not only do you need to choose what works for your company—you can actually choose more than one.

The answer to which is the best is simple: yes.

Wash, rinse, repeat

Agile is an umbrella term that describes a philosophy of work more than the actual tools and processes that are used by its proponents. Agile is all about iterative loops; the heart of the movement is having cross-discipline teams that work from the ground up, never passing an idea along the chain. Instead they build together in short bursts, cycling back to iterate and address changing needs as new information becomes available.

The term Agile was coined by a group of technology thought leaders (and spirited rivals) working on Extreme Programming, Adaptive Software Development, Scrum, and other techniques, who realized that their values and philosophies aligned. They came together to form a movement, something that was intended as a philosophy as much as a set of processes. That philosophy was straightforward: a determination to rely on rapid empirical feedback and full transparency.

From its origin in 2001, Agile rapidly overtook its roots as a bootstrapped ideation for startups, gaining prominence in large organizations such as Facebook and Google. Small teams in Fortune 500s began to play with the idea, bringing sprints and standups into their offices, and other disciplines eyed the prize, realizing this format worked best when everyone was on the same page. Agile was eating software.

Embrace the sticky note

Meanwhile, Design Thinking was following a similar development. The term itself was coined decades ago, in Herbert A. Simon’s 1969 book The Sciences of the Artificial, to refer quite literally to the way designers come up with new ideas. From there the term broadened and generalized, moving from design to architecture to teaching before landing, in 1991, in the world of business. Even then, Design Thinking was slow to catch on. Technology companies began embracing it slowly over the next twenty years, with mainstream adoption not vaulting up until 2014.

Linus Pauling famously said, “The best way to have a good idea is to have a lot of ideas.” This is one of the foundational elements of Design Thinking. The philosophy encourages participants to open up and consider every idea, only paring down once every avenue has been explored. It often takes the shape of a week-long working session, where each day is dedicated to a slightly different avenue: customer interviews, idea creation, prototyping, and testing are generally hallmarks.

Design Thinking is best used to come up with a new idea. It usually starts with a problem, where the shape of the workshop is set in trying to solve that problem.

There is no one way to explore Design Thinking. IBM’s formula is available for anyone to internalize, while other companies make their living providing Design Thinking exercises to forward-thinking businesses who need a hand getting started.

Have your cake and eat it too

You may be wondering how much of a struggle it will be to integrate Agile and Design Thinking into your organization. The truth is, the two philosophies run parallel, not at an intersection.

Every product starts with a problem you want to solve. Design Thinking is the process by which you discover the shape of that problem’s solution, while Agile is the method you use to refine the solution once it’s been found. But there isn’t a moment of handoff where you context switch from Design Thinking to Agile. Rather, it’s a layered process, a soft slide from one to the other.

The people creating (designers and engineers) absolutely must be in the room during design strategy sessions. This ensures they understand not only the “idea,” but also where that idea came from. Similarly, strategy must stay in the room to help guide the decisions and shifts that are integral to the Agile process.

Smart companies are already using Agile and Design Thinking in tandem. Bain and Company’s description of Agile assumes that your company will already know about Design Thinking, describing a team’s “initiative owner, who typically comes from a business function and divides his or her time between the Agile team and key stakeholders, [as using] techniques such as design thinking to build a catalog of promising ideas or features. The initiative owner continuously (and ruthlessly) ranks that list based on the latest estimates of value to customers, financial results and other innovation initiatives.”

Don’t waste time

The first step to incorporating both Agile and Design Thinking into your organization is making sure everyone is on the same page. Teams need to understand the philosophy behind both systems, and agree on how to work them into the process. Remember, these aren’t cookie cutters, they’re living (and malleable) solutions. Each organization will have different needs—you won’t get anywhere trying to fit a square peg into a round hole, no matter how great you think circles are.

Start small. If your team is already Agile, considering running a Design Thinking exercise for your next feature rollout. Remember, Design Thinking is best for solving the question of “Why,” not “How,” so don’t try to apply it to something where you’re defining a solution, not a problem. Know that you might spend a little more time on this the first few times you do it. Set aside a week to really embrace the process; don’t expect to fit Design Thinking into a weekly Sprint! If you cut it down to a day or two the first time you do it, you won’t get the full benefit.

If you’re already using Design Thinking and want to integrate Agile, your first step is to bring developers and designers to your next Design Thinking workshop. Get them involved from the ground up, and stay involved as they take those ideas and bring them to production. Remember, rapid empirical feedback and full transparency are the keys of Agile. Scrum boards and sprints can come once you’re used to working as cross-discipline teams!

Do you have questions about ZenHub? We’d be more than happy to help on Twitter @ZenHubHQ or email us directly.