* This is the second in a three-part series of posts that will explore how we do product development at Tandem – something we call “Human-Centered Agile.” If you missed part one, be sure to get caught up here.
While the two philosophies are after the same goal it is undeniable that there has been a historic rift between the proponents of each camp. Agile’s origin story was written by developers, it’s roots are firmly in the hands of “engineers.”
The mythology of HCD or “Human-Centered Design” is a bit murkier but many of the concepts and terminology can be traced back to, Don Norman, director of The Design Lab at University of California, San Diego. It became a way for designers to describe their process and the outcomes they wished to achieve. To many designers (mostly those classically trained), agile methodologies are at best “those meetings the devs have” and at worst a cold, detached and mechanical way of creating software (not a product).
If my oversimplification here has offended anyone, my apologies. There are of course both developers and designers who happily coexist and even thrive in a close working relationship. We operate with this approach at Tandem and I know other organizations do as well. But there is a vast wasteland out there in which these two philosophies are anathema to one another.
Where HCD and Agile Can Falter
I don’t wish to leave the reader with the assumption that upon successfully combining agile and HCD their life will be rosy and all will be well. There is no road to product development Nirvana. So to wrap up, let’s look at some ways that this combination can fall short.
The Unviable MVP
If I had my way we’d strike the term Minimum Viable Product from our vernacular. It is a washed out phrase that more often than not becomes an excuse for building something that half-solves a problem and that certainly doesn’t delight users. We focus only on the M and forget the V altogether.
This is where HCD has a leg up on the way agile is practiced in most environs. Agile is concerned with doing the smallest thing that can result in working software. HCD is concerned with doing the smallest thing that can provide a valuable solution to a problem, or some part thereof. Both run the risk of defining the scope of “working” or “complete” as being smaller or larger than necessary. But at least HCD is focused on a tangible outcome for a person rather than checking off a requirement.
Constraint-free Design
Any designer will tell you horror stories of being stuck in a swirling vortex of indecision in which the search for perfect leads straight to nowhere. Constraints such as feasibility, budget, cost of change, and accessibility are a way to extricate a design team from such a vortex.
Infeasible designs, those which either can’t be built for technical reasons, can’t be effectively manufactured, or do not have a clear path to market have two downstream effects. First, the business stakeholders are left feeling that the development team has wasted time and let them down. Second, the design team feels that the only way to build anything is to “water it down”, that the cleverness of their designs are reduced to commodity.
The solution here is to define clear and measurable constraints at the outset. And, to ensure that these constraints are understood by all members of the team.
The Revenge of Waterfall
Sharp handoffs between teams creates a boundary over which understanding can degrade. This is especially true of teams that approach their work with different skill-sets, such as design and development teams. This loss in fidelity in understanding the theory or mental model behind a decision, design, or complete solution can wreak havoc on outcomes. These types of handoffs allow our teams to slide quietly back into waterfall.
We see this mistake time and time again in our work. And each time I consider it an oddity given that both HCD and agile place a disproportionate value on face-to-face communication over documentation or specification. Being a truly cross-functional team is hard work but it’s the only way to avoid the pitfall of handoffs.
Iteration and Refactoring
In agile contexts, we often use the word iteration to mean a series of time boxes each of which contains a given amount of work. But real iteration is not about the continuum of time, ticking off tasks, but about iteratively evolving the subject matter.
This misuse of the word is yet again one more signal of a propensity to fall back on waterfall, a failure of a “worse but easier” mindset. We do not build digital experiences like we build houses: first the foundation (100% complete) then the framing (100% complete) then the plumbing and electrical (100% complete), drywall, doors, and on until it’s all done. Rather, you should build a feature in a way that solves a problem and then iterate on it over time to solve the problem in better and more complete ways at each stage. The following visualization will help:
We see this danger not just on the development side of projects but also in design where perfect becomes the enemy of good all too often. UI designers need to resist the urge to wait to present work until it is in a “final” state because the truth is that it won’t ever be finished. Refactoring should happen both in code and in design.
Principles That Make HCD+Agile Work
If it is true that these two philosophies are indeed better together than apart what are the underlying principles that make such a marriage work?
Unrelenting iteration that places little to no value on previous coding. Iteration that isn’t just moving on to the next thing when we cross a time box boundary but that truely “iterates” a feature. This prevents earlier work from diverting the project away from user needs by way of the “sunk cost” myth. Developers (and designers too) must be willing to unceremoniously throw away previous work when a better outcome for the user is discovered.
User research is always needed and usually needs to be refined throughout a project. This is especially true for highly innovative projects that are forging new paths. The more innovative and groundbreaking, the more research is needed. Research also needs to be done intentionally with best practice techniques – we’ll explore these methods in greater depth in another article.
Ideal teams have balanced skills. In our experience, this is somewhere around 1.5-2 developers to every 1 designer/researcher. Depending on the size of the team and the project in question they also need the proper supporting cast of product owner, operations expertise, business strategy analysts, and quality control.
Agile methods and HCD will only support and complement each other so long as there is mutual respect and common understanding between designers, developers, and the whole project cast. In our experience we often see engineering teams view designers as support roles rather than integral to delivering value, this must be resisted.
Teams must be prepared for the natural ebb and flow on a project that is being informed by an evolving understanding of the user’s needs. This means changes in scope, timeline, release cycles, staffing, and refactoring. Flexibility, tenacity, and resilience are essential for high functioning teams.
Productivity should be measured by value delivered to a user, not by quantity of work. This implies that user testing is ongoing throughout a project to measure this value. Velocity and story points are fine for determining what might be accomplished in an iteration, but they should never be a measure of completeness or productivity.
—
In our next post we’ll get tactical and share a process framework for bringing HCD and agile together.
