Category: gadgets     Posted by: cornelius     Discuss: view comments     Views: 3221

There is a lot of love out there for the symbiosis between Agile and UX these days. More often than not, companies that are using the likes of Scrum or XP (eXtreme Programming) as their software development methodologies are including user experience professionals as part of their delivery teams. So why am I writing yet another blog post about this very topic? Well, from my experience, this marriage doesn't work quite as smoothly as advertised...

The acceptance of user experience in agile organizations is a relatively new concept. Being able to quickly research, perform IA work (typically task flows, wireframes and sitemaps), create high-fidelity prototypes, perform UT (usability testing) for a story and then be able to serve it up to software developers is enticing to every development manager out there. And while this concept may work from a theoretical perspective, when it comes to execution and deadlines, it quickly becomes very clear that if the team falls behind, there are typically two areas that suffer: user experience and scope (and ultimately quality). Development managers are delivery driven (rather than quality driven), and for them delivery means one thing: code. As a user experience professional working in an agile environment, how many times did you hear a development manager telling you that you no longer have time to spend with the end users for user research, and that those deliverables (be it wireframes or high-fidelity prototypes that are required by developers for a particular story) are now due in less than 24 hrs or even worse, not needed altogether because the functionality is fairly simple and the developers will be able to go straight to code without them?

In my career, navigating the extent of my involvement within agile teams has sometimes been rocky. Yet at this point, looking back at projects ranging from the success stories to those that were quite simply narrowly avoided disasters, two distinct themes have emerged, and are going to be the focus of this article.

As I said before, when dealing with very short iterations, working on UX deliverables required in the same iteration in which they will be later coded has never quite worked for me. It may have worked for the first two, three iterations, but once developers fall behind, long hours start being the norm and eventually UX becomes an afterthought. Also, if the so called "Agile" methodology is a little less agile than advertised, and the product is being coded in a more incremental rather than iterative manner, being able to look back at previous iterations and fix user experience and design flaws becomes very difficult. And cutting into user research and ideation because Agile is bringing the 'customer' into the fold overlooks the fact that customers (as in business customers in the Agile definition) and users (as in the people who will use the product) are only very rarely the same. So the fact that Agile is there to design the for the business client and not for the actual user, is an early warning sign for most issues between Agile and UX.

So how is it that this has worked for me in the past? Well, it has much to do with finding creative ways to ensure that even though coders will eventually fall behind, the user experience side always has a buffer of scope (stories for which the UX aspect has already been designed prior to the developers starting work on the iteration containing those stories) or it has a organizational makeup that has the flexibility to pick up speed going forward to tackle retroactive UX work while not falling behind the ongoing overall product roadmap.

Option 1: Staggered delivery

Having an 'Iteration 0' type of ramp-up time for the BAs and user experience designers means that the preliminary research, the visual big-picture, the general layout and the initial story development for the first one or two iterations will be out of the way before the software developers even have a chance to join the project. Once the development goes under way, the UX team will focus on stories that are at least one or two iterations away for the developers and therefore the usual clashes between our teams will be reduced. Also, there is a chance that any stories that may be affected by previously developed work could reach the UX team prior to or at the same time they are being worked on. This approach also gives the BA/UX teams some time to go back and fix particular BA/UX deliverables that have been flagged as defects since their technical implementation took place.

Option 2: A Standalone BA/UX Team

Agile is a software development methodology. The typical values sought after by successful software developers clash with the user research and creativity focus that UX teams observe. In this second option, a product manager would oversee the hybrid BA/UX teams when developing their stories, independent of the software development team. That way a number of stories for which the BA/UX stage is complete will always be available for the development team. Also, the physical and temporal isolation from the development team will also ensure that development setbacks are not affecting the BA/UX delivery. In order for this work, the UX team has to work as an internal consultancy, working on multiple projects/workstreams. This allows for engaging a variable UX headcount to tackle in-iteration changes and future iteration work, and then allowing the surplus to move to other projects/workstreams when catch-up is achieved. Needless to say, this option doesn't quite work on small projects, but has proven to be very effective on larger enterprise-scale agile implementations containing double-digit UX teams.

Ultimately, both of these options recognize the same concept: mixing user-focused UX designers and delivery-focused developers within the same iteration is a timebomb on IT projects. Separating them without loosing contact, and allowing both to focus on the high-performing (and mutually-exclusive) cultural quirks of their respective teams, will be the success factors in the long run.

Anyone else out there who has successfully implemented one of these two options? Any other view out there that actually works in real life?

Tags: user interface, project management, marketplace, thoughts

khaleem (05.11.2010 01:53:49) wrote:
I think that the important point in the article is not so much the two options, but making the differentiation between incremental and iterative and the way the UX team needs to support the iterative process. I never thought much about internal consultancy-like teams before, but this peaked my interest

Steve (10.11.2010 19:21:17) wrote:
What about having a fully cross-functional Agile team, with interchangeable skills? Should we teach the UX team members to do basic UI development or should we teach the development team to do basic UX work? Or both? I don't think these questions are explored enough in Agile UX literature these days.

Note: Your email address will be protected and will not be shared with anyone.

Name:*

Website:

E-mail:

Comments:*