Human-Centered Design (HCD) -- Does It Benefit the Agile Process?

Just this month, Joe Montalbano and Brad Lehman published a pioneering new book entitled, Human-Centered Agile: A Unified Approach for Better Outcomes, which functions as a guide on how to apply Human-Centered Design (HCD) practices to an Agile product development model that is used widely throughout industry and government, where it is applied primarily to software and technology development efforts. This has been an ongoing industry challenge due to the fact that HCD prioritizes time spent understanding the problems to be solved (time spent in the problem space), while Agile prioritizes a fast hypothesize-and-deliver model (time spent in the solution space). 

I spoke with Joe and Brad this past week and asked them: “How does Human-Centered Design (HCD) benefit the Agile process?” Here is their complete answer:

Is there any more overloaded and misused term than MVP? Theoretically, in Agile the MVP is a vehicle to test a hypothesis using lightweight code until value is proven. Teams can pivot. Teams can iterate. Teams get actionable feedback with every release and can be responsive.

The real world isn’t always like that. Not every team can pivot. Not every release is lightweight. Not every failure is graciously accepted as a learning opportunity. Oh, and did we mention that production-quality code can be expensive and time consuming?

Bringing HCD into an Agile delivery workflow gives teams a chance to do their learning earlier in the process and do it less expensively. It lets teams explore multiple solutions and mitigate risks by making informed decisions based on what their customers actually want, not just what an executive hopes they want.

So, what does Human-Centered Agile provide?

Earlier learning — Discovery lets teams identify real customer needs, and validate the problems they are going to spend money solving. Concept Validation with lightweight, disposable prototypes and mock-ups (paper drawings, wireframes, etc.) allows teams to test and refine their solution concepts with users before the first delivery, shifting learning left.

Cheaper learning — The cost of engaging with users for Discovery and Concept Validation is far less expensive than it is to write some production-quality code and then release it to get feedback. 

Lower risks —  The costs of building a product are not the only risk a team takes when launching a product. Releasing products that frustrate customers can harm their relationship to the product, whether they are first-time customers trying it for the first time, or experienced users looking for improvements. 

Unfortunately, too many teams and programs think that HCD and Agile are simply incompatible. They aren’t! We wanted to show everyone that they are actually well-aligned in purpose, and can be done together with some adaptation. This requires a change in mindset, but neither the change in thinking nor change in work practices are as dramatic as you might think.

What do you think of Human-Centered Design? Have you used HCD within your Agile process and workflow?

Discovering Failure Modes Early in the Design Process

Earlier this month, I spoke with Ed Henshall, who just recently published a book entitled Right By Design: A Novel Approach to Failure Mode Avoidance. His book presents an approach to product design based on Failure Mode Avoidance that utilizes a series of strongly interrelated engineering tools and interpersonal skills that can be used to discover failure modes early in the design process. The tools can be used across engineering disciplines.

During our conversation, I asked him: "Is it possible to discover failure modes early in the design process?” Here is his complete answer:

The short answer -- Yes, with difficulty. 

In looking at a longer answer, I would rephrase the question slightly --  “Is it possible to discover potential failure modes early in the design process before you have a design?”  

Firstly, the word “potential” is important as it indicates that the design can fail but has not yet failed. Secondly, by not having a design I intend that the design is fluid and not finalized meaning that it can readily be changed without impacting the cost and timing of the design process. This latter point is the good news -- if failure modes are found that require fixing early in the design process, this can be done inexpensively. However, the associated bad news is that it is difficult to discover failure modes early in the design process when a design is fluid. 

The key to this conundrum is to have a clear understanding of what it is that the design is intended to do, and its function, along with an equally clear understanding of the way in which the design will achieve this function. What is important here is that the design is initially considered from a functional perspective rather than a hardware perspective. To quote the well know architect Louis Sullivan, “Form ever follows function.”

The System State Flow Diagram provides a way of modeling a design from the functional perspective allowing potential failures of function to be identified in a rigorous and systematic manner. This enables design countermeasures subsequently to be developed in moving into hardware design. 

Discovering failure modes early in the design process requires effective and efficient teamwork, which does not happen as a matter of course when groups of people work together but requires significant attention to, and coaching of, the team process.  

What do you think of Ed Henshall's perspective? Does your organization have effective "team process" and leadership?