Harmonizing Agile With "User-Centered Design"
UX specialist Anthony Colfelt presents a case for how agile, alone, might not be sufficient and a thorough and engaging look into how User-Centered Design can, and should, be merged with it.
Colfelt sets up his message asking if agile is well-suited to solving the problem of helping the business know what it wants:
In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.
He describes a "minefield" of 6 ways he's seen agile fall short in a UX sense:
- "Mine 1: An unclear role for design":
The agile principle stating “Business people and developers must work together daily throughout the project” leaves little explicit room for a UX designer, often leaving the job to developers who are unlikely to possess such skills.
- "Mine 2: The requirements gathering process is not defined":
It's not uncommon for agile teams to adopt a "requirements magically fall from the sky" mentality, eschewing efforts spent on outlining strategical product vision as un-agile.
- "Mine 3: Pressure to cut corners":
Forcing UX design into the same iteration as it's corresponding development can lead to impulsive design, losing opportunity to test design ideas on user. Of course, agile allows the real thing to be usability tested, but responding to the feedback from this may take more time than you've expected or are comfortable with.
- "Mine 4: The temptation to call it “good enough”":
Even (maybe especially) when agile is done well, teams are invariably faced with the need to prioritize 'iterating on existing features to get them right' against 'incrementing new features into the product'. As Cofelt observes:
Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.
- "Mine 5: Insufficient risk-free conceptual exploration time":
Many agile teams will just begin building day one of the project (or very close to it). Some may employ an "iteration zero" to do some up-front planning and design. Cofelt asks if this is enough - does the agile approach of using a working example to validate ideas always truly outweigh doing some validation with rough sketches before committing to code?
- "Mine 6: Brand Damage":
Putting non-raod-tested (via UX design approaches) features out into the market, even if intentioned to gain feedback, can quickly lead customers to lose faith in your company's ability to consistently hit the mark - this is damage to your brand, something well known to be hard to build and even harder to re-build.
Colfelt makes an interesting summary statement that agile, in and of itself, "is good for refining, [but] not defining". He asserts that agile alone may suffice for "an existing product that you want to develop to the next level", but, particularly when you're starting something new, "some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution".
He describes a traditional/"typical" UCD process, focusing the readers attention to its inclusion of upfront research for product "strategy" (he later also talks of this as "Concept Design", drawing on the quintessential iPod example), something he asserts does not become any less important when adopting an agile methodology. He's careful not to say that agile explicitly precludes such upfront thinking, but asks if it provides sufficient explicit encouragement to do it justice.
Ultimately, Colfelt's goal is to raise awareness for how UCD's focus on "strategical"/"concept" discovery can and should be combined with agile's ability to "refine":
In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.
Reserve some time to read Colfelt's full article before making any hard line judgements. You may also want to check out this related article by Johnny Holland about how the UX designer's job morphs in an agile (Scrum) world, in which he also discusses similar themes of "strategy" but focuses more on interaction with the development team and iteration level activities and dynamics.
equirements magically fall from the application
Regarding mine 2 you can see here a demo on how the Agile Platform can be used to gather feedback directly in running applications. This is a good way to get the information with the proper context and to include and responsibilize business users in the prioritization efforts.
User centred design
Thank you Mike!
I particularly liked the "Agile(Scrum)" qualification at the end. For the gazillionth time Scrum != Agile! I'm personally giving as many people an earful about how tying Agile to Scrum is so backwards it's not even funny. Sad to say, many people are actually contradicting the Agile Manifesto with their blind, rigorous adoptions of Scrum. Agile is about being responsive to need, not blindly following a process even when it is not fit for purpose.
On "Mine 2": An undefined requirements process is probably preferable to an over-defined process. I've seen too many projects derailed by a requirements gathering process that ran on and on and on and on. I've found that many times a project gets lost in analysis paralysis because they don't have anything to actually use. Getting working software into the hands of the people creating the requirements can go a very long way towards making the requirements process much much more efficient and accurate. However, I'm glad to admit that there's many folks that jump in way too fast and try to start shipping way too early. You need time to hang some muscle on the bones, not just skin.
Mine 4: This is a problem with developers? Since when? I've generally seen the opposite problem with developers: The temptation to say nothing is good enough. Usually, it's management types who say it is "good enough" and don't realize the cost they will be paying down the road.
Mine 5: This is the result of failure to apply common sense. 'nuff said.
Generally speaking, I'm very skeptical of how many organizations are approaching the "UX" bit. I've seen too many cases of really, really bad "UX" spec'ced by so called UX/UI experts that were just graphic designers. Give me someone who knows about things like mouse clicks, consistency, and logical grouping. Don't give me someone who treats each screen/window as a blank canvas.
Re: Thank you Mike!
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015