Agile User Experience Design

A Practitioner's Guide to Making It Work

Diana Brown

• Publisher: Morgan Kaufmann
• Year: 2012
• Print ISBN: 9780124159532
• eBook ISBN: 9780123914095
• Topic: Computer Science
• Subtopic: Digital Media
• Index: Computer Science

Being able to fit design into the Agile software development processes is an important skill in today's market. There are many ways for a UX team to succeed (and fail) at being Agile. This book provides you with the tools you need to determine what Agile UX means for you. It includes practical examples and case studies, as well as real-life factors to consider while navigating the Agile UX waters. You'll learn about what contributes to your team's success, and which factors to consider when determining the best path for getting there. After reading this book, you'll have the knowledge to improve your software and product development with Agile processes quickly and easily.- Includes hands on, real-world examples to illustrate the successes and common pitfalls of Agile UX- Introduces practical techniques that can be used on your next project- Details how to incorporate user experience design into your company's agile software/product process

Chapter 1

Introduction to Agile

Contents

Introduction

Agile Values + UX

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Agile Principles + UX

Principle 1

Principle 2

Principle 3

Principle 4

Principle 5

Principle 6

Principle 7

Principle 8

Principle 9

Principle 10

Principle 11

Principle 12

Common Methods

Crystal

Extreme Programming (XP)

Scrum

Hybrid agile, or custom agile

Kanban

Scrumban

Lean UX

Common Terms

Chickens and pigs

Product owner

Scrum master

Sprint

Product backlog

User stories

Epic

Planning poker

Story-point estimation

Acceptance criteria

Burn-down chart

Spike

AgileFall

Jeff Patton

Summary

References

Introduction

To understand what it means to practice an Agile form of user-centered design, it is important to have a sense of what exactly Agile means and where the term came from. Since the Agile methodology has a deep, rich history and is continually evolving, it has become the subject of many books, blogs, white papers, conference presentations, and websites, all of which have their own take on the value system and its methods. This chapter touches on only the most common terms and concepts and those that might be most relevant to a user experience practitioner. I encourage everyone to spend some time exploring the many resources that are available to get a deeper understanding of the philosophy and the various methods for applying it that have grown up along the way. It is also important to recognize that there is no one single right way to implement Agile design. At its core, “Agile” is a set of values to use as compass to guide a team through the production of software. Whatever process or tools are used and how they are applied are secondary to the overall goals of empowering a highly functional team as it builds great software to the delight of its end users.

Agile is a term that grew out of efforts in the 1990s to find a better development method for producing software. Traditional methods, such as the waterfall method, were starting to be recognized as a bit unwieldy. Consumers were expecting more of their software in terms of quality and functionality, and production cycles needed to change in order to create a product that would satisfy end users. Additionally, production cycles needed to be able to adapt and accommodate the reality of shifting requirements. Waterfall development makes it especially challenging for teams to respond to issues, mostly because it is inherently unable to discover serious problems with the design, architecture, or the code itself early in the cycle and can really identify them only when it is too late for a correction. Not knowing what problems might exist until the end of the release cycle results in a lower-quality product or longer release cycle. Traditional methods are also prone to creating silos, where product managers throw requirements “over the wall” to designers, who then throw their design specifications over the wall to development teams, who throw their code over to a quality team, that eventually authorizes the release of a product. Due to the limited interaction and communication among these teams during the production of each deliverable, each team is playing a game of telephone and putting its own interpretation on the requirements or the specifications. As in the telephone game, the end result very rarely matches the original intention.

Development teams began experimenting with new techniques like Extreme Programming, Adaptive Programming, Scrum, and other methods to find a better way to produce high-quality software and meet demands without requiring developers to write code 24 hours a day. In 2001, practitioners of a variety of these philosophies got together in Utah and created the Agile Manifesto. The manifesto, and its accompanying 12 principles, captures the spirit of what all these methods were trying to achieve and is an important starting point for an organization that is consider adopting Agile practices. Reading the values expressed in the Agile Manifesto is always a good way to check on whether or not you are on track with your own Agile implementation. While the methods, techniques, and terminology have evolved since 2001, the core values of Agile have not. The manifesto eloquently states:

“We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more”

The Manifesto for Agile Software Development, agilemanifesto.org

FIGURE 1.1 The agile process.

Agile Values + UX

The manifesto provides the best guidance for and is the most succinct expression of the values that should drive an Agile organization. A description of the principles behind the Agile Manifesto is provided on the website, and it gives additional insight into the manifesto, but the heart of the matter is very well expressed in the manifesto itself. While referencing something that was written so long ago might feel old fashioned, I find that these values are just as relevant now as when they were first created. In software years, 2001 was a very long time ago; and while it was not quite the Dark Ages, it might well be analogous to the Atomic Age. After all, 2001 was the year that many overvalued dotcoms went under, the first-generation iPods were introduced, Microsoft released XP, and several years ahead of the introduction of the ubiquitous Facebook. UX (user experience) practitioners are working today who have no memory of that time. With all the focus on Agile in recent years and the birth of so many variations on the theme, it is fair to assume that the movement has evolved beyond its original manifesto. After all, how many software concepts still hold water over a decade later? That assumption is false. All the children of the original Agile movement still share the core values expressed in the Agile Manifesto and really just use different tactics to create an environment that embodies the spirit of the original statement. All these years later, software production teams still struggle with processes that often focus on the milestone deliverables instead of keeping their eyes on the shipping product. Rarely is a release cycle not subject to changing needs from stakeholders, but rarer still is the process that can support responding to such a change—unless you are working in an Agile environment. The intention of the Agile Manifesto is to define a value system that allows for the creation of a culture that can respond to these situations, while recognizing the value of the individual team member, and produce good software. While the Agile Manifesto lays out the core values of an Agile environment, many techniques can build a process and a framework to support those values. Examining these values through a UX lens can show that there is a natural relationship between the two.

Unfortunately, at no time have UX professionals gotten together and hashed out a manifesto of UX values and principles that came to be the standard to which we all hold ourselves. In fact, despite definitions of the process for user-centered design, there is no formal expression of its value system, beyond the idea that we want to keep the user’s needs central to the design process. Things start to get even more vague regarding UX principles. It is not that no UX principles are written down, but that different UX principles are written down by many people. Quite a few people have their own spin on UX design principles, including Microsoft, which has defined the UX principles for Windows and shared these principles on its website (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd834141.aspx). Most of the definitions of UX principles tend to mention the mission of keeping the user involved in the process, then identify additional guidelines for best supporting the user. Rather than picking a favorite to use for a comparison to the Agile principles, since I have yet to see a set that did not offer some interesting food for thought, or creating yet another set of UX principles, we will review the Agile principles and values and explore the way they fit with and support the type of activities in which UX practitioners tend to engage.

Individuals and interactions over processes and tools

Despite being the first value expressed in the Agile manifesto, it can often be the first one that is forgotten as teams explore the different tools used to manage tasks, user stories, and generate burn-down charts. Excitement over various ceremonies, like daily scrums, backlog grooming, planning poker, and retrospectives, and a desire to properly execute those meetings can often distract the teams from focusing on the people and the communication these things are intended to support and inform. Add to that the fun of exploring and using new software tools to support the process, and the team’s attention can be easily aimed in the wrong direction. If a daily standup meeting needs to run for 20 minutes while the team becomes accustomed to the brevity of the status reports, that can be okay as long as the teams are learning how to give brief status reports and they are improving their ability to share only the relevant information. The point of 15 minute meetings is less about that specific amount of time, although it is a very good target, and more about providing the least amount and most relevant information in a meeting short enough to not create a burden for the team to attend. If the team is consistently allowing such meetings to run for 30 or 45 minutes, then it has a problem that needs to be resolved. Similarly, if planning poker is taking too long, does not feel productive, or is causing team members to become disengaged, then it is time to look at whether planning poker is the best technique for the team to use, or if there might be a better way to estimate effort. While it is fun to play with a set of cards, the event is just one way to get the team to participate in effort estimations, and it is not the only way to do that. If the team is several sprints into the cycle and members put more time and energy into the task management tools than they get out of them, the team needs to talk about a different way to handle and track tasks. Even if it would be too disruptive to switch process managment tools during the release, a healthy discussion about the tool will identify problems and potential solutions and help determine if something different needs to be used in the future. It is a critical part of the Agile method to refine the process throughout rather that pick an approach and stick to it no matter what. All these techniques are meant to be the means to an end; and if they are not moving the team toward increased and improved communication, then it is time to revisit the Agile Manifesto and think about how to actually be more Agile.

From a user experience perspective, the idea of treating the process with the same iterative design techniques used on the product should feel very comfortable. We ask customers for their feedback on the product and refine it accordingly; the product team is the consumer of the process and should be able to provide input into its design. Additionally, designers and usability specialists are used to thinking about the individual end user rather than a set of features; this lends itself well to a process built around the idea of user stories. Improving the interaction between the end user and the system is always foremost in our thoughts. After all, some of us have even had “interaction designer” as part of our job title. Going Agile means taking the same perspective that we have on our users and applying it to our teammates and our work. Some UX folks do this naturally and focus on relationship as a matter of course. Since UX teams are rarely able to realize their designs and implement them for the shipping product on our own, we rely on the development team to do so; and it is always in our best interest to build healthy relationships with the team and other functional groups with which we work. However, it also happens that there are team who perhaps have fallen into a more “us vs. them” mentality with their colleagues from other functional areas. Practicing Agile is a great opportunity to let go of any divisive mentalities and focus on team building. The good news is that this particular Agile value gives everyone on the team permission or instruction to focus on communication and the individual team members rather than on the process. Recognizing that each team member brings a unique set of skills to the team is also a change from traditional processes, where the developers often are seen as interchangeable code producers. Valuing individual skills provides an opportunity to recognize what the user experience team members bring to the table. It also allows the process to be tailored to the individuals that constitute the team.

Working software over comprehensive documentation

Obviously, the highest priority in any production cycle should be the thing that is created, sold, and generates revenue. However, if a functional area is rated and rewarded more for the artifacts it produces than for the shipping software, this priority can easily get lost. People want to do the right thing, but they also want to be recognized for their work; and if such recognition is given to only a very specific piece work or deliverable, then that is where their energy and attention will go. Unfortunately, many traditional methods also require so much documentation that they end up creating environments where it is more important to generate the items that support the process than to produce the software itself. Obviously, the well-intentioned thought is that the whole of the software is made better by the increased quality of its parts, but the myopic focus on the production of the bits and pieces can create silos that inhibit the communication that might bring this hope to fruition. The idea of putting the attention on the development of the software over generation of the supporting documentation can represent an interesting challenge for UX practitioners who want to take this value to heart. While we certainly contribute to the product, in most cases we usually are not responsible for building it, but we can and do create plenty of supporting artifacts.

In many ways, this principle is asking us to let go of our most visible and tangible contribution to the release. But, if we can make peace with that idea and recognize that the product is more important than the detailed internal deliverables, we can also see that this could positively affect our relationship the other functional areas, as it can reduce barriers to communication and put our efforts toward attending to what gets implemented rather than being satisfied with achieving a good design. Designers, despite our best efforts to remain open to all solutions, often get focused or attached to a particular design solution and wrapped up in the process of creating and documenting that design. However, if little or none of that elegant solution makes it in to the product, was it a good investment for the company or the designer and did it do anything to improve the end user’s experience? This does not mean that a...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Introduction
• About the Author
• Chapter 1. Introduction to Agile
• Chapter 2. Agile Methods + UX = Agile UX
• Chapter 3. Case Studies
• Chapter 4. Common Success Factors
• Chapter 5. Frequently Asked Questions
• Chapter 6. Using Agile Concepts for UX Teams
• Index