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:
- Conduct research about users and user categories
- Contribute interaction designs to allow development of a product or product family
- Evaluate designs realized in prototypes and working products through feedback from humans of the target categories
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.
Defining Agile Terms
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.
Case Studies
Presentations at UPA 2009 included case studies of how specific teams brought user experience sensibilities into their Agile teams.
- Adjusting prior user-centered research and design activities by managing both the personnel and processes involved, to increase frequency of sharing of research results, prototypes, and designs
- Conducting a “design sprint” devoted to understanding one particularly difficult feature critical to product completion while educating the team about user research and interaction design
- As part of a one-week sprint, three to four hours of user research (using parallel populations) to produce designs—rapidly created paper artifacts on the way to making sketches and prototypes more directly tied to applications for clients
- Solving the need to assign limited UX staff to multiple small teams by creating office hours where teams without research or design members consult with an appropriate UX person.
- Separating UX into its own stream, coordinated with development, but with its own schedule, tasks, and leadership, plus twice-a-year design sprints to handle the issues related to big design.
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.
Retrieved from https://oldmagazine.uxpa.org/agile_and_ux_2009/
Comments are closed.
