By Frank Spillers

Agile timeboxing-UX

Agile's defining characteristic is speed. Unlike other software development methodologies (like Waterfall) that work in timeframes of months, Agile timelines are measured in weeks (2-4 typically) with actual code developed for each 'sprint'.

Is Agile's rapid and fixed development deadlines and deliverables conducive of usability activities? In short do you have time to do usability?

In this post I will show you how teams are coping with the marriage of Agile (Scrum, Extreme Programming and Lean) and UX (User Experience, usability and User Centered Design) and how Agile development teams are managing to make time for UX to keep the relationship from going on the rocks.

Agile and User Centered Design: Common Threads?

It is important to point out that rapid application methodologies like Agile have a defining quality that is in unison with UCD: both are iterative, both focus on "just in time" design; quality of product, better products that are customer-centered, better software development efficiency and ROI and ultimately a final product with high user adoption.

It is this shared intention that has always led me to embrace Agile in my work at Experience Dynamics. On some of my first Agile projects eight years ago, I always found it strange that UCD would be perceived to be antagonistic to Agile. I was excited in 2001 when I was first introduced to Extreme Programming. Wow, a software development methodology that has a user-centric focus and even takes "user stories" seriously!

Lack of time or lack of familiarity with UX?

The biggest problem I find that often gets in the way of Agile UX harmony is lack of familiarity with UCD or a thin understanding of usability engineering practices.  Since Agile is inherently obsessed with risk-management, maybe it senses the disruptive (as in innovative) nature of usability. The truth is that usability can compliment and empower the Agile development process to get what it needs, when it needs it and if factored properly into your time-boxing and cycle planning process, can strengthen user adoption.

There's no point delivering on-time software that fails with end-users. Sorry but that's the business reality. Managing the risk of poor user adoption can be mitigated with rapid UX techniques.

Yet some teams are sprinting toward classic failed IT project mistakes made over the last decade or more: lack of user involvement.

If user involvement accounts for the highest weighted risk in failed IT projects, then it makes sense to mitigate that risk by demanding usability activities that can provide usability requirements and UI design fixes 'just in time'.

How to involve your UX team in your sprints: 5 Musts

UX people can be bridges between business teams, users and technology. Similar to the role a good software or enterprise architect can play to bridge business and technology needs.

1. Conduct a rapid field study before the first sprint or during the first sprint. While back-end preparing and early sprint planning is taking place, a field study can be conducted. At Experience Dynamics, we have this process for up to 15 users down to 7-10 days delivery and completion (from 3-4 weeks a decade ago, and still the norm in usability consulting).

2. Conduct regular remote usability testing or rapid testing. With today's remote online usability testing tools, user testing can be conducted while you are in your meetings. Testing can take an afternoon or 2-3 days. User testing should be scheduled alongside sprint planning and the findings from the previous cycle of user testing used to guide prioritization of features and functionality. At Experience Dynamics we have rapid user testing down to 5 days end to end, down from 2-3 weeks- a normally quick turn-around in the industry.

Note: Microsoft's RITE (Rapid Iterative Testing and Evaluation) approach is Agile-friendly. It involves regular usability testing with findings immediately applied to change design and code.

3. Conduct expert usability reviews before and in parallel with the next sprint to flag high-value usability fixes. Usability reviews (heuristic evaluations) are designed, like usability tests, to be fast-iterative and regularly done. If your UX is not doing this (or you are not letting them do this), you are missing a chance to put their brain to work. Expert Reviews, like usability testing, are vital and perfect for Agile time cycles. At Experience Dynamics we have our fastest type of expert review down to overnight (12-24 hr delivery down from 3-5 days).

4. Let your UX be a bridge for competing technology, business and user needs. Your usability or UX person is best positioned as a product owner or co-owner. The product owner in Agile is the voice of the customer, so this only makes sense. It is also an easy role for the UX because they do this anyway (or they should be) when recommending usability enhancements or updating the wireframes containing the evolving features and functionality. Usability can be a bridge to "herd cats" and create rapport with the business team and users- vital stakeholders in the direction and approval of requirements.

5. Plan for UX as a "good" disruption that will occur in parallel with dev efforts. Many teams forget to including usability activities in sprint planning. This again I believe is largely due to lack of familiarity with usability and UCD methodology. It is important to remember that usability and UX can be conducted quickly and informally (e.g. Google's cafeteria user testing). The team should be informed of what UCD deliverables and usability requirements will be coming and at what point (so they can react to change). This will also help the UX prioritize and champion user needs.

Conclusion

One thing is clear, Agile and UCD are not going away anytime soon. Both need each other for the others success. Positioning and using your UX properly, will give you a stronger chance at mitigating poor user adoption. Because when push comes to shove, and the clock is ticking, it's easy to forget about user acceptance, user adoption and user involvement- the three leading factors of project failure.

Best Wishes,

Frank Spillers, MS