UX and Agile: Tying the knot

In the modern software development environment, UX and agile practitioners are becoming part of a growing culture defining the way online products and services are being delivered.

The modern UX team is much more multi-disciplinary and organic than ever before, and it's no surprise that hybrid processes and methodologies are being employed to ensure better management of personnel and project deliverables. Although UX and agile both address key pitfalls that exist in traditional software development to deliver a better solution for the end-user, sometimes UX and agile approaches seem to work against each other when people focus too much on the processes and procedures.

Just as UX design doesn’t have to be constrained to a specific type of user research or wireframe tool, agile software development is not defined by SCRUM meetings or dynamic programming pairings. The detailed research and testing required to develop an understanding of complex user interactions and behaviors still has its place in the hectic sprints through iterations of design concepts and prototypes. There is a place for both practices to co-exist harmoniously if we ignore the hype and stick to the basics.

Here are some factors and advice for a happy marriage between the two.

Something Old: The project management triangle

For team members working in an agile software development environment (if you are not already, it is simply a matter of time), the principles of the old Project Management Triangle still apply. How the cost, scope, and schedule are balanced will always determine the quality (i.e. success) of the project, and this needs to be assessed with each project (i.e. the client requirements). Unfortunately, no one is immune to senior management and project managers trying to upset the balance of the PM Triangle by reducing costs, tightening deadlines, and adding features in the specification (most likely to try and make a sale).

These low hanging fruits, with their frustratingly shortsighted gains, invariably end up being the poisoned chalice that no one wants to drink from. The companies with long-term vision recognize that, in the end, you can’t set a fixed price tag to the quality of the work if you add to the effort required to produce it. Trends in software development methodologies come and go (the acronym creators may already be at work now), but age-old principles and ideas are here to stay.

Something New: The project management triangle redefined

There is a change in the air: not something fundamental but a shift in the balance of power. One could argue that the primary motivation for companies adopting UX and agile approaches is a desire to satisfy demands of multi-faceted consumers, which requires more user research and evaluation to deliver a user-driven product.

As products and services evolve more rapidly in the digital space, the end-users also become more sophisticated and harder to define (i.e. no single persona is appropriate). UX design can serve as the input into an agile software development process, just as the prototypes developed can be used as input to further refine the product design. This has the effect of blurring the distinction between design and development phases because the prototype itself is being used as a research tool.

What is clear is that product concept and development is moving back into the hands of the consumers, so companies are putting more emphasis on project management changing from the perspective that they are selling what you are going to build to the customer’s perspective: building what you are going to sell. This requires a delicate balance between the viability (can we afford it?), feasibility (can we build it?), and desirability (do they want it?) of the products and services. The reinterpretation of the PM Triangle is therefore set to understand how the same principles apply to different parts of the organization (i.e. how to balance the same parameters for the sales/marketing, development, and design activities).

Something Borrowed: Lean and agile

It should come as no surprise that organizations need to be adaptive and flexible to meet the needs of users: a constantly moving target encompassing generations of consumers. The user-centric view of product development reflects the trend of a more holistic view of the product development process rather than a new concept, as companies begin to see how this view complements (rather than contradicts) business goals and requirements.

Practitioners of agile and lean methodologies understand that it is about finding the right balance rather than sitting at the extremes (the agile manifesto describes this concept perfectly). Lean and agile methodologies are complementary in that becoming lean makes you more agile (and vice versa). You can even argue that what lean tackles at the management team level (by cutting down on unnecessary or inefficient processes) agile tries to tackle at the development team level (by removing some limitations of the traditional systems development life cycle). Therefore, it makes sense to have them working in tandem. When the organization has an integrated and efficient product development pipeline, a UX architect/designer will be able to produce their best work.

Something Blue: The problem facing the modern UX guy

However, not working in an agile environment is not the real problem facing UX architects/designers. Even as the debate around the role of the UX guy continues, there is recognition that a great UX lead can be a critical factor in driving a user-centric development process. However, it is not enough for UX practitioners to simply sit at a desk and design user experience.

The “wireframe/storyboard machine” that the company paid for needs input, and that comes from face time with end users. For architects juggling the time that they spend with users and the designers and developers—coming up with user research, information architecture, usability, content planning, and interaction and interface designs—is something that many organizations (not to mention the UX professionals themselves) are still struggling to get right. Sometimes it means design considerations that require in-depth research and analysis by the UX designer get buried between sprints and micro-managed development tasks.

Many UX professionals haven’t done themselves any favors by evangelizing user experience as something that is beyond the reach of graphic designers and software developers. It isn’t, and is something that should be embraced by all parts of the organization.

Invariably it should be the people who have the most contact with clients and users who take ownership of user experience design, so it’s sometimes surprising when sales and marketing departments worry more about their KPIs than how happy the users are, because it seems impossible to achieve high KPIs without keeping the customers happy. And even bad user experiences (perhaps even more so than the positive ones) deserve attention of the consummate UX professional, who (for better or worse) is always focused on building strong relationships between users and products.

And a Silver Thruppence: Can money buy UX or agile?

Of course, just paying a UX professional or a SCRUM master an exorbitant amount of money won’t solve the real problem, in the same way that going to a therapist won’t automatically guarantee that any deep psychological issues will magically disappear. There are different levels of UX/agile capability that organizations at different levels of maturity can strive for. One responsibility of the UX architect is to guide the organization through the process of developing the personnel and resources for it to happen. But regardless of the company’s UX competency, the UX designer should act as a custodian for the current user experience and the target user experience to be achieved in product development. Furthermore, the rest of the organization needs to understand that the business goal and vision of the company (as much as its product and service) is part of the overall user experience.

Will it Last?

There are plenty of pitfalls that you need to avoid in the relationship between UX and agile, but like every good relationship the key is to be able to work through the problems and find the best solution. If both parties are willing to make it work then there is a good chance that it will.

And on that note here are some good tips for making it work:

The quality of a working relationship is a function of the extent to which it is built on a solid mutual understanding of the needs of the two parties involved.

Forget whether you're right or wrong. The question is: Is what you're doing working or not working?

There is no right or wrong way to fix a relationship. Find your own way that works. But recognize when it's not working and be honest when it needs fixing.

Have you had any notable successes or failures marrying UX and agile methodologies? Please share them below.

ABOUT THE AUTHOR(S)

Michael Lai is a freelancing and consulting UX architect specializing in infographic and data visualization design. He has worked and consulted in a number of different industries (hospitality, research, IT, science, and engineering) and covered many UX related roles including user research, copywriting, training, graphic design, business analysis, and information architecture. In his spare time he is working on iPhone app and hardware integration, startups, and non-profit organizations.

Add new comment

Login via:

Your name *

E-mail *

The content of this field is kept private and will not be shown publicly.

Comment *

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as click-able links.

Comments

Hi Arin, Thanks for the comments. It might be of interest to the readership if you described the relationship between the UX lead and the Dev lead for your company, especially since your organization handles the UX + Agile (and also Lean methodology) in a pretty effective manner. I haven't seen too many other methods outside of SCRUM that have been implemented within organizations, but I suspect that with some tweaks it should not clash with UX processes.

If we take another look at the agile manifesto, you'll find that there are many parallels between the values and principles between UX and Agile:

Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan;

Other than the second point, which is probably more relevant to programmers, I think you can argue that UX and Agile are both trying to address the trend of user-centric design. Yet most of the utility in adopting these philosophy and practices have been hampered by following specific processes or methods without a true understanding or appreciation of the user needs.

My advice is, as the article suggests "ignore the hype and stick to the basics".

Great Article, I actuslly do think that "Working software over comprehensive documentation" is achieved via a more agile approach to UX. The ability to modify and demo a prototype can potentially remove the often heavy requirement for multiple wireframes and concepts.

Stew - I see your point but "as much design is done prior to a sprint as possible" doesn't seem very agile to me - you are creating a dependence on this phase to be finalised prior to sprint kick off - I think there is more value on approaching the UX work iteratively and incrementally delivering. The added benefit here is that you don't end up with a development team which are too focused on the technical feasibility and lose sight of the user benefits being delivered.

I agree that the crux of the challenge is this: in many situations, UX has NOT handed off all these great research/design conclusions before development begins.

Therefore, how to optimize if you take it as GIVEN that UX has 0 knowledge at the start, same as the dev team. How do you begin? Does 'Agile/Lean UX' mean that we just make up a Sprint 1 hypothesis to develop, and THEN validate it? Seems reasonable.

"In my experience it can easily as long as sprints are seen as being about implementation and that as much design is done prior to a sprint as possible. "

That's most people's experience as well as far as I can tell (certainly is mine). The trouble is, that's not Agile. And Lean UX isn't defined in any real way so people are free to say what they want about it.

BTW on your first point about it being obvious that people understand each other they can work better together. I would say not only is that obvious, but that you don't need Agile, or indeed anything else, if that's happening - you only need a "process" to address issues of suboptimal practices like misunderstanding, ignorance or disease.

I'll flag up first I'm going to be critical of this article. The reason being sentences like this...

"The quality of a working relationship is a function of the extent to which it is built on a solid mutual understanding of the needs of the two parties involved."

Or in other words...

"If everyone understand each other they can work better together."

Which is really stating the obvious. The rest of the article touches on some of the issues UX faces in different kinds of organisations without really offering solutions.

Above all it doesn't touch on how UX, lean or not, can better work with Agile. In my experience it can easily as long as sprints are seen as being about implementation and that as much design is done prior to a sprint as possible. The UX work should be attached to the stories ready for the dev team and then, as is natural, it is found reality isn't quite how the UX work predicts then the UX resource should be able to be there for the dev teams to resolve any issues in a very quick way - these changes being documented etc later to allow the sprint to run without delay, for example solving a UX on a white board or as a sketch. Lean UX (which remains wonderfully undefined) often does encourage getting all team members involved with the UX process rather than it being a black box or the UXers knowing best. That we can all agree with (I hope).

Is there really a 'silver bullet' that works for every company? I would suggest that while high level approaches can guide the path to coming up with the right solution, nothing that you can prescribe from a manual or a consultant is guaranteed to fix anything, if at all. I like the previous comment that you don't really need Agile or UX if people come up with their own processes and communicated more.

Good topic. Integrating UX thinking and deliverables into Agile delivery is like creating a research-based "back story" for every user story. By linking epics and user stories to the personas, goals, and scenarios that drive them, teams can get the best of both worlds: strategic, business-focused design directly linked to short-cycle deliverables. Agile iterations can benefit from UX design artifacts, such as annotated wireframes, to jump start minimum viable documentation. And organizations can map the value of project and development initiatives directly to prioritized user needs at every stage of a product or project lifecycle.

Nice article. I think that the whole team needs to take ownership of the UX (in the same way that an agile team takes ownership of the problem domain) and that designs should be evaluated by end users during development as part of an iterative agile process. The team is 'too close' to the product to evaluate it objectively without assistance.

Very good point about the whole team needing to take ownership of the UX. This is considering that the UX designer is usually the UX team, so Product Managers, Sales, Marketing and developers all need to chip in. And if the design decisions are not validated by exposure to real end-user testing, then all that effort will have been put in for no real gain, unless your initial assumptions all happened to be correct.

PMI-Agile Training at Bangalore starts from 27th April 2013
The PMI-ACP (Agile Certified Practitioner) is a new credential offered by the PMI for people working in Agile project management environments. The PMI-ACP carries a high level of professional standing and credibility as it requires the combination of Agile training, experience, and the PMI ACP Certification examination.
If you use agile practices in your projects, or your organization is adopting agile approaches to project management, this 2 day session and the PMI-ACP certification may be right for you.
Workshop Dates at Bangalore : 27,28 April 2013
Location: The Shelton Grand, #73, M.G. Road, (Entrance Church Street), Bangalore 560001.
http://www.starpmo.com/pmi-agile/bangalore.php