Agile Needs Design Thinking

When Agile methods were first introduced, I thought they were going to be a significant improvement over waterfall methods for design. Developing smaller parts of an application to support a subset of user tasks and then testing them as soon as they were built rather than developing the entire application and only then testing it was a significant improvement. And, in many ways, Agile has been a significant improvement. However, in many other ways it has made things worse and the zealously articulated phrase "fail fast, fail often" sums up the major problems in my view. 

This phrase is usually meant to communicate that teams should start coding to build a Minimal Viable Product (MVP) quickly, release it, and if it fails, to learn from it, pivot and start over. This is the approach most startups use, in my experience, and the approach many enterprise teams are readily adopting too.

In contrast to this approach, if teams practice design thinking, or better yet, IBM Design Thinking, they will very quickly carry out some user research to identify a problem to address or an opportunity to pursue, or to validate that an initial idea the team came up with has merit. In doing that user research they will also be empathizing with the users to be served by the solution which can then be used to inform the early design visualizations. They will then prototype the idea rapidly using pencil and paper and gather some quick feedback on it. If any aspect of the conceptual design should be improved, they can even change that design while they're with the users giving the feedback. They can then take the information summarized in assets like Empathy Maps and Scenario Maps, to write the user stories which can then be developed using Agile methods but with a much higher sense of confidence. During Agile development, the detailed design for the user stories is crafted and coded and quick user feedback is gathered and incorporated in every Sprint. Additional elements of IBM Design Thinking like Hills and Playbacks will further increase the chances of success. 

This approach doesn't preclude the chance of failure but it minimizes it rather than glorifying it. It increases the likelihood of success by ensuring that the team has more information with which to design and develop. And if failure does happen, and its bound to some of the time, the team will have even more information that they can use to understand the failure and what to do next. It's important to point out that this approach requires more than engineers. It also requires designers with expertise in user research methods, visual, and interaction design.

Can Agile methods lead to building solutions more quickly? Yes, but without the information and methods that design thinking provides, many of the teams using Agile methods simply build badly designed solutions or even ill-advised solutions more quickly. Those kinds of failures can and should be avoided. The combination of Design Thinking and Agile methods together provide the approach that optimizes for designing and building the right solution rapidly and, in turn, minimizing the chance of failure.