Design Thinking vs. Agile: Combine Problem Finding & Problem Solving
Whether it’s Agile, Lean, design thinking, or a combination of the three, your company’s development methodology can make or break any project.
This is only exacerbated by the fact that 70% of projects fail to deliver on what the customer was promised.
Many IT leaders believe that adopting a single development methodology will fundamentally address this issue — but which is the right choice? Read on to learn more about design thinking, the part that Agile and Lean play, and how to ensure that your product is best suited to match what users need.
What is the Agile design methodology?
Agile is a software development methodology that helps organizations stay responsive to change. Small businesses, Fortune 500s, and even the FBI follow the Agile methodology.
Gartner defines Agile as a “development approach that delivers software in increments by following the principles of the Manifesto for Agile Software Development.”
That means that Agile is a flexible and iterative software development methodology designed to adjust quickly with feedback.
There are various types of Agile frameworks:
- Dynamic Systems Development Method
- Feature-Driven Development (FDD)
Each approach follows the main principles of Agile, including a focus on the people doing the work and collaboration between business and IT.
A key tenet of effective Agile development is seeking frequent feedback from end-users to iterate the right outcomes. Early on, this includes:
- establishing the project business goals
- writing user stories
- creating backlogs
Throughout the Agile process, the team shares working demos to gather feedback and uncover unanticipated needs. Users should be able to submit issues, suggestions, and ideas through embedded feedback mechanisms within the software—both during development and once in production.
Ideally, there’s a closed loop that brings feedback directly into the development environment enabling ongoing iteration.
Low-code development platforms are particularly helpful here. With regular interaction points through meetings and demos, developers can continually gather new insights to adapt and better align the software with both user and business goals.
Where does Lean fit in with Agile and design thinking?
Without Lean, there wouldn’t be Agile.
Lean is a production methodology that started in the manufacturing industry as a way to help companies reduce waste (anything that doesn’t bring value to the user), increase innovation, and optimize processes.
The history of Lean dates back to the 1450s in Venice, Italy, but Henry Ford was the first to truly integrate it into a production process in 1913.
When it comes to software development, Agile follows many of the same principles as the Lean methodology including:
- fast and frequent iterative development
- short feedback loops, or “sprints”
- disciplined, error-proof processes
Design thinking versus Agile
Now you might be wondering, “Is design thinking just another name for the Agile manifesto and framework?” That’s a great question. Both frameworks depend on response to feedback, but there is a core difference.
While Agile is an approach to problem solving, design thinking is an approach to problem finding. It calls for a high degree of empathy and understanding of end users, and an iterative process of developing new ideas, challenging assumptions, and redefining problems.
The 5 stages of design thinking
The goal of design thinking is to identify alternative solutions that might not necessarily be apparent. There are five stages of design thinking through which this is accomplished:
Understand people, their behaviors, and their motivations. People often don’t know or can’t articulate these things explicitly. Understanding emerges through viewing users and their behaviors in context to identify patterns, ask questions, and challenge assumptions.
Create an actionable problem statement to define the right challenge to address and the set of needs that are important to fulfill based on the organization, its goals, and the perspective of end users.
Leverage techniques such as brainstorming, mind mapping, sketching, or paper prototypes to step back, go wide, and create innovative solutions that weren’t originally envisioned.
Bring ideas to life by showing instead of telling. Quickly create working prototypes to get something into users’ hands and begin to collect real-world feedback.
Learn from users’ experiences, iterate, and repeat the process as needed until reaching a Minimum Viable Product (MVP).
Better together: Agile and design thinking
Together, design thinking and Agile create a user-centric environment focused on rapid, frequent iterations as a means of reaching optimal outcomes. Use design thinking to identify the right problems to solve, and then use Agile to iteratively build solutions to solve those problems.
Design thinking brings a strong user focus while Agile is an excellent way to incrementally deliver solutions. User needs are kept front and center throughout the entire design and development process.
For teams looking to leverage Agile and design thinking for the first time, here are three recommendations to keep in mind:
Start small. Focus on high-value, low-risk opportunities to gain experience using design thinking and Agile together. Then, as your capability matures, take on more challenging initiatives.
Create cross-functional teams. To facilitate the required creativity, create cross-functional teams that work together to design and develop solutions. The team should be physically collocated with end users to promote frequent collaboration.
Balance design and development. Because Agile teams are often inclined to “just start coding,” mixing the two methodologies for the first time may create tension around how much time to spend on design thinking before beginning development.
Make sure the team understands the value of the empathy, definition, and ideation phases, and that design thinking is not leveraged only at the front end of the process. The team should be prepared to uncover new user insights and reframe the problem, and then continue development with a renewed sense of why.