"Something old, something new, something borrowed, something blue, and a silver thruppence in her shoe."—classic wedding tradition

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.

 

Image of rose petals and rice courtesy Shutterstock.