Integrating UX into an Agile Environment

I’ve posted about Agile previously, but each time it has been generalized reviews of the practice. So I decided it was time to really get into the nitty-gritty of what it means to practice user experience in an Agile environment. There are some great resources out there on the subject, some of which I have listed below in my references which I recommend.

So we have a good idea what agile is, where it came from and definitely why developers like it. So how do we fit UX into the mix? I started by listing out some of the great benefits of UX that I needed to make sure weren’t left out. Some of these items were:

• Getting in front of projects and designing before production
• User research, feedback and usability tests on the product
• Time for iterations in design, based on changing requirements and research
• A means to support multiple projects with limited resources
• Time to gather all the necessary details and look at the project as a whole

Next I looked at some of the potential set backs to UX in a true agile environment:

• Lose the holistic view of the system
• No time to prototype everything before development starts
• Lack of extensive requirements
• More development teams working simultaneously, same UX resources
• Fast delivery means less time for testing and iteration
• Loss of time for user research projects and general R&D
• A need to track UX worth and work before a project is completed

I did a lot of research on how to address these problems and what I came up with are three different types of UX roles, that when combined in a team create a solution. Those roles are:

1. The Integrated Practitioner
2. The Support Practitioner
3. The Researcher

Each one of these roles works to meet the needs of a solid user experience while addressing the constraints and taking advantage of opportunities in agile environments.

The Integrated Practitioner
I would say this role is most similar to the traditional waterfall role. This person works with one or a few specific SCRUM or development teams. They are in a sense a dedicated resource to a few core teams. Before a sprint begins (Sprint 0, or pre-sprint) this person works closely with the Project Owner. During this time the Integrated Practitioner will ensure that proper personas are chosen for the project and assist in writing out project stories. It’s important this person is good at breaking down larger designs into smaller chunks and can identify the design and business goals of each chunk. They will also work to create user experience metrics that are included in acceptance testing as conditions of satisfaction.

Once the stories are ready for the upcoming sprint the practitioner will begin to create low to medium fidelity wireframes. These should be quick, and focus on the major functionality. It’s just about getting enough information down to get the point across. In the absence of document specifications the wireframes become the key method of communicating concepts and demonstrating interaction requirements to the team  It can be helpful to make this process collaborative with the SCRUM team and involve them in brainstorming and design sessions on some of the major initiatives.

This primary design work should be done just one step ahead of the development team, and continue in this fashion throughout the project cycle. Each sprint staying one step ahead of developers ensures that you’re always ready to hand off the next chunk of the design. All work done needs to be documented in UX stories to ensure proper velocity tracking for the work.

Testing should be integrated into the end of each sprint in a RITE (Rapid Iterative Testing and Evaluation) and discount fashion. These should be done quickly and provide quick and simple feedback as to the progress and success of the sprint. Any issues identified should be quickly addresses by developers during testing.

The Support Practitioner
Wouldn’t it be great if we had enough integrated practitioners to support all the SCRUM teams? Unfortunately if you’re like most companies this is definitely not the case. This is where the Support Practitioner comes into play. This person works with teams that have a less demanding need for usability work and less impact on the presentation layer of the product. They have more of an occasional need for prototypes and recommendations and contact the support practitioner on an as needed basis. Work is taken in a priority order and done on a consulting basis sprint by sprint.

Because this person works with a wide number of the teams, and has the most visibility into many areas of the product this is also an ideal role for maintaining pattern libraries and standards in documentation.

The Research Practitioner
So now that we’ve tackled working with the development teams and getting prototypes delivered in an iterative and timely fashion what about the bigger picture? This is where the Research Practitioner comes into play. This person would focus on the larger R&D for the product including major usability tests, persona research, user satisfaction studies and needs analysis, etc. It would then be up to this person to ensure that the results are communicated effectively across the team and the company. For example, when usability tests are done, have video clips of important results available for quick access in addition to overall reports.

In conclusion, it’s important to remember that just as the term its self describes, it’s important to remain agile. Not one solution will work for everyone but try out different ideas and iterate until you find a solution that works for you.

Probably the hardest thing for practitioners will be giving up some of the sense of entitlement to the work and sharing design decisions with the development teams in a collaborative process. This is important though as time is limited and collaboration reduces the workload and increases developer buy-in on decisions. Communication is key and the most important component of success.

References:

• Cooper’s Q&A video on Integrating User Experience and Agile
• Burndowns and Flareups in Agile Design by: Leah Buley
  
• Twelve emerging best practices for adding UX work to Agile development by: Jeff Patton
• Agile Usability: Best Practices for User Experience on Agile Development Projects
• Agile Development Processes: An Interview with Jeff Patton
• Adapting Usability Investigations for Agile User-Centered Design
• The Doctor is “In” – Using the office hours concept to make limited resources most effective