It’s long been established that agile software development principles lead to better project outcomes when compared to a waterfall approach. Nothing is perfect, but the agile movement introduced a new level of clarity in shared understanding, flexibility to absorb changes, a framework for constraining work-in-progress, and an iterative approach that involves a wider audience earlier in the process.
Similarly, human-centered design (HCD) has been widely recognized as a best-practice in developing solutions that solve real problems for real people. Rather than starting with a product or idea, let’s start with the person and problem and work toward the solution. Products driven by HCD foster a higher level of engagement with their users and result in a tighter market fit.
While both agile and HCD are often referred to as “methodologies” they really aren’t, they’re philosophies. There are numerous techniques and methods that fall under the HCD umbrella. And, there are several popular frameworks that can justify calling themselves agile.
This distinction between method and philosophy is an important one when exploring how HCD and agile can work together. Because these are philosophies, a set of mindsets and objectives, we don’t have to struggle to merge two disparate processes. Rather, we can conceive new processes that satisfy the values of both philosophies.
The Philosophies
The core difference between the parallel philosophies of agile and human-centered design revolves around how each system measures value. For many agile software teams, the measure of value is closely related to velocity (how quickly work is being done) and the progress in delivering features to production. In this way of thinking value starts at zero and incrementally (and uniformly) increases to some maximum as defined by the scope of the project.
HCD, on the other hand, measures value in terms of the quality of the user’s experience – how well and how completely does the product address the user’s pain points. This approach also adds value over time but it is much less linear and often doesn’t start from zero as problems are often already somewhat solved by alternatives. Additionally, practitioners of HCD consider that, at times, the product may actually decrease in value even though it has more features than before.
The working supposition of this article, and what we’ll discuss in subsequent sections, is that neither philosophy is wholly “correct”. The danger in taking an exclusively agile approach is that we may not build the ideal thing and therefore not solve a real problem. The peril in focusing only on an HCD approach is that we may not ever get off the ground, mired in a “design hole” and never ascending to execution. However, the philosophies are complementary, each covering the deficiencies of the other in powerful ways.
Why agile needs a little HCD
As stated previously, agile sprung from a well of discontent filled with stalled projects, drawn-out timelines, and endless planning. The intent of its founders was to address these problems in the context of software projects, a very “by developers, for developers” approach. Yes, agile does seek to involve the stakeholders more and later incarnations of agile practices such as Extreme Programming (XP) took this further. But, on balance, agile addresses the concerns of a well-executed project.
Some readers will doubtless argue against the previous point. And yes, I am generalizing. But in my many years of experience (most of it on agile projects), I have seen the agile methods used more as a defensive mechanism for teams than as a way to build a better product for the user.
So why then, does agile need HCD?
Savvy Users
As users become savvier with technology (the web, mobile apps, wearables, voice interfaces and AI, etc) they have a better intuition about how systems should behave. When a digital experience breaks their intuitive assumptions the product becomes much less effective at solving what they expected the product to solve. The immediate next step for a user is to search for an alternative, not a great outcome for our customers, or our businesses.
Higher Order Problems
As technology has advanced over the decades it has become capable of solving ever more critical human problems. These problems are often sweeping in their scope and require a systems approach. HCD’s concentration on deriving solutions from foundational user research leads to the discovery of a solution that is a system of systems.
For example, modern healthcare technology, transportation, farming, and public safety are large-scale problem domains. Solutions in these spaces are improved by this systems view rather than thinking of them as a set of isolated activities strung together.
A Benchmark for Validation
Both agile and HCD encourage the collection of feedback and refinement of ideas through validation. However, agile tends to benchmark from a different position, usually against the edicts of business stakeholders.
User-based research, on the other hand, provides a scale which can weigh design decisions against the value delivered to a real user. This evidence-based approach means much less guesswork which frequently becomes a matter of rather meaningless debate.
ABE, Always-be-Editing
The age of bloated, feature-centric software (more specifically interfaces) is over. There will always be a place for complex, technical, and utilitarian software, but the vast majority of products do not fall into this category. Pleasant, effective, and intuitive experiences are far more likely to drive success today than merely a long list of capabilities. HCD advocates for constant editing, always asking “do we still need this,” and “can we solve this in a simpler way.”
—
In our next post, we’ll explore where agile and HCD can falter and some of the principles to follow to bring them together successfully.
This is the first in a three-part series of posts that will explore how we do product development at DevMynd – something we call “Human-Centered Agile.”
