Constantine on combining Agile and User Experience

Usability and Teamwork author and consultant Larry Constantine recently wrote two articles about the “Interfaith Marriage” between experience design and agile development.  The first article can be found here, and the second one here.

He discusses the fervent adherence to practices by both the UX and the agile communities and how that marriage can be fraught with difficulty and tension.  As he says:

When these two meet, when experience design is married with agile development, the results can be a crisis of faith on either or both sides.

He examines the history of both agile methods - the XP focus on the “onsite customer” who might not be a real user where “customers are not, in most cases, the same as users, and the customer role is more focused on functionality than on usability.”  He continues to say:

In their slight of users, the agile methods resemble most other software development methods, which have a long history of treating users, user interfaces, and usability as afterthoughts at best or at worst as irrelevant. I myself am guilty in this regard, having pretty much left users out of the equation in the now ancient techniques of structured design, a sin that I repented and for which I did penance by developing, with Lucy Lockwood, the body of techniques that came to be known as usage-centered design.

He talks about the work of professionals from both the agile and the UX community working to bring the two perspectives together:

Many professionals on both sides of the aisle—Jeff Patton, Scott Ambler, Ron Jeffries, Thomas Memmel, Don Norman, and Jakob Nielsen, among others—jumped into the role of matchmakers, promoting a relationship or rapprochement between experience design and agile development. This has been a long engagement. I’ve been writing about user interaction design and agile methods since the turn of the century (are we allowed to say that now that we are in the second decade of the millennium?), and Jeff Patton’s agile-usability forum (agile-usability at Yahoo Groups) dates from 2004

He goes on to discuss the public debates and disputes between UX and agile adherents, and how the debate has been largely one-sided:

An interesting aspect of this speed-dating dialogue has been that, for the most part, nearly all of the narrative so far has been about experience designers accommodating to the dictates of agile methods and schedules. Hardly a word is printed or spoken about what developers might do to accommodate the agenda and practices of designers. Short stand-up meetings, test-first development, 2-3 week sprints, emergent requirements, avoidance of upfront analysis or design, pair-programming, rapid incremental development with re-architecting, the customer role with user stories—all the practices and paraphernalia of agile development tend to be assumed as fixed and given, while the practices and processes of experience design are modified or mangled to fit into the particular agile method being performed.

He then examines where the incompatibilities lie between agile methods and UX: 

There are many core incompatibilities in this couple. Agile methods employ rapid, iterative refinement, with short, incremental development cycles. The imperative is to produce executable code and deliver added functionality at each iteration right from the get-go. BDUF, for Big Design Up-Front, is a curse to be avoided at all cost. The single most important criteria, embodied in the test-first development approach, is that each increment of expanded code run to completion, executing correctly to produce the right output. Little or nothing is said about the usability of the results or of the means for the end-user to reach them. Test-first development does not include or address user testing, and it is arguable whether it should or even could. 

User experience design, on the other hand, tends to front-load activities, often beginning with a fairly long lead-up devoted to field study and observation of users, analysis of user requirements, user modeling, prototyping, and visual and interaction design. User testing is often a fairly time- and labor-intensive activity that may sometimes be integrated with prototyping but is almost always heaviest late in a project when a beta or later version becomes available. In general, experience design assumes that a design will be completed in substantial detail before anything beyond a prototype is built, because user experience is usually shaped as much by subtle details and their precise interconnection as by overall structure and organization. 

In Part 2 of the article he goes on to provide guidelines for four elements that need to be brought into the Agile-UX relationship to make them work well together: 

• Respect
• Equality
• Knowledge
• Independence

 Respect:

We are all professionals, yet developers too often look down on experience designers as muddle-headed, touchy-feely types drawing on soft-science impressions and unsupported opinion. To be honest, I have also known some designers who see developers as narrowly focused, socially inept techno-nerds stuck inside their code. In truth, programmers and designers alike need to learn to be better at acknowledging and deferring to each other’s expertise.

Members of both communities need to adopt a one-team attitude and respect each others’ professional credentials and knowledge.  The developers understand how best to build a software product, and the UX professionals understand how people interact with systems and software – acknowledging and respecting the skills that each bring to the table will result in products that creat customer delight.

 Equality:

Designers and developers need to be co-equals in the development process. I confess that I have personally come to believe that, for greatest success in most instances, experience design should drive the process and that, for the most part, user experience issues should trump implementation issues. If it comes down to the position and opinion of the developers on the one side and the designers on the other, most of the time, the outcome is better if the nod goes to the best design. However, in practice, a more workable compromise is to consider developers and their concerns and designers and theirs as equally important.

Where differences of opinion and perspective cannot be resolved between the team members there needs to be an arbiter – a role who has the responsibility of talking for the customer and making the final decision about aspects of the product under development.  This role is known in Scrum as the Product Owner and is well defined, someone who has the long-term interests of the product at heart and provides strategic and technical direction for the product in the organisational context.

Knowledge:

One of the most effective ways to build mutual respect and equality is through knowledge.

He talks about the need for UX designers to understand the principles and approaches of software engineering and for software developers to gain knowledge of the principles and key aspects of usability design.  Remembering that “we are not our users” and that gaining an understanding of real customer interactions will result in a vastly improved product. 

Another argument for spreading the skills is that even the most thorough presentation and interaction design will not and cannot cover everything down to the lowest detail, and will always fail to anticipate some interaction or presentation issues. In practice, programmers inevitably end up making many user interface design decisions on the fly—everything from whether or not to align certain visual components to creating unanticipated error messages to deciding whether column headers on a grid display should be active to sort on that column. Not only does knowing the fundamentals of interaction design contribute to better teamwork and more successful collaboration with designers, but it is also in keeping with the ethic of cross-training and fungible skills that permeates agile methods.

Any good marriage allows for independent thought and activity, which can be a problem for meshing the work of user experience designers and software developers. The impulse to launch immediately into productive work on day one is understandable and all but universal for both designers and developers. Designers start sketching screen layouts or product designs in first meetings, and programmers start writing little bits of code as soon as they can get their hands to the keyboard. And management makes the matter worse by pushing for visible deliverables from day one.

He discusses decoupling UX design and development – use a “one sprint ahead” mode of working where the UX design is undertaken in small slices, just ahead of the development and delivering just-in-time input to development stories.