The Magazine of the Usability Professionals' Association
By Nancy Frishberg
Several activities at UPA 2009 focused on shared experiences of working in Agile environments. (See box for Agile definitions.) Six presentations, one panel, and a pre-conference workshop told how usability professionals face new challenges reconciling their research, design, and evaluation activities with schedules and practices of Agile teams.
What is Agile?
In contrast to the traditional “waterfall” process, Agile refers to a software development process conceived in 2001 by a group of developers.
Agile recognizes that the best work is done by a small self-organizing and self-regulating group of collocated individuals. Management embraces Agile with the expectation that development will proceed more quickly and thus more cost-effectively.
Agile processes have an impact on organizations that are our clients or employers—and sometimes the customers of our clients. Agile development is adaptive rather than predictive and people-oriented rather than process-oriented. The Agile approach has been growing in popularity the past few years.
User Experience in an Agile Environment
User experience, encompassing branding, product concept, development and release, customer service and end-of-life transitions, draws on a wide array of techniques that typically have touch points in multiple areas of an organization. In a narrower definition, user experience specialists:
Agile requires the segmentation of work into small teams, rapidly changing requirements, and the expectation of working software as the output from a two-week development cycle. This puts new pressures on UX professionals to find clear project definitions and success criteria, segment the work into small chunks that can be shared with the team, and communicate daily with their teams.
Working one sprint ahead of development has become established as a best practice, as is using an initial sprint (“Sprint Zero”) for planning, sketching, and conducting user research or gathering relevant existing research.
Presentations at UPA 2009 included case studies of how specific teams brought user experience sensibilities into their Agile teams.
What About Big Design?
Each organization has bumped up against the question, “When do we do the big design work?” Implied in that question is the related question, “When do we do the user research that feeds to design work for the product or a related group of products?”
The obstacles to big design are the same issues that confront waterfall development teams: the many steps in planning (gathering product requirements, reviewing competitors, and creating elements to be shared among several products) will take too long. The planning steps will also refer to situations that are likely to change during the several-month development course of a multi-faceted product.
An alternate view is that any project will make decisions about architectural framework, programming languages, and framework for test suites before starting development. So why not take the opportunity to make decisions about UI architecture, prototyping methods, testing schedule, and filling the evaluation pipeline with customers and users at the same time?
In practice, though, interlacing quick research and sketching to the next (or next plus two) sprints is widely accepted, if not universally practiced. Sharing research results with the team—in small chunks, as soon as possible—conforms to the spirit of Agile. Evaluation activities during the following sprint confirm design concepts and implementations, and indicate which additional items belong in the backlog.UX
Sprint: The fixed interval of time (typically one to four weeks) during which the team works on particular items from a backlog of development tasks. Also called Iteration.
Release: The goal of a sprint or series of sprints, a product release. At the end of each sprint, whatever is done is complete, tested, documented (to the extent necessary), and integrated with the rest of the work for a release boundary. The release is made available to the customer. The general goal is to release frequently, understand what is working or not working, and release again soon.
Backlog: Known requirements (or a feature list) expressed as User Stories, and other tasks that become work for future sprints.
Scrum: The Agile work group which focuses on a sprint as the key work interval; a small team which includes a customer representative (product owner), facilitator (ScrumMaster), and a multi-disciplinary team meeting daily to track progress and stay in sync with each other.
Extreme Programming (XP): Software development processes, such as simple design, pair programming, and frequent small releases that emphasize customer involvement and teamwork.
Pair Programming: Two programmers at one computer—a driver and a navigator. In theory, they accomplish better work together and more quickly than either could alone.
Nancy Frishberg is a user experience strategist, based in the Bay Area of San Francisco, California. She employs appropriate qualitative and quantitative methods, turning user research into actionable findings. Among her favorite techniques are design games: playful methods for interacting with customers and users to inform design of products and services.
Usability Professionals' Association
promoting usability concepts and techniques worldwide
User Experience Magazine is by and about usability professionals, featuring significant and unique articles dealing with the broad field of usability and the user experience.
This article was originally printed in User Experience Magazine, Volume 9, Issue 1, 2010.
© Usability Professionals' Association
Contact UPA at http://www.usabilityprofessionals.org/about_upa/contact_upa.html