Read an Excerpt
Agile User Experience Design
A Practitioner's Guide to Making It Work
By Diana DeMarco Brown
ELSEVIER
Copyright © 2013 Elsevier Inc.
All right reserved.
ISBN: 978-0-12-391409-5
Chapter One
Introduction to Agile
CONTENTS
Introduction 2
Agile Values + UX 4
Individuals and interactions over processes and tools 5
Working software over comprehensive documentation 6
Customer collaboration over contract negotiation 7
Responding to change over following a plan 8
Agile Principles + UX 9
Principle 1 10
Principle 2 11
Principle 3 11
Principle 4 12
Principle 5 13
Principle 6 14
Principle 7 15
Principle 8 16
Principle 9 17
Principle 10 18
Principle 11 19
Principle 12 19
Common Methods 20
Crystal 20
Extreme Programming (XP) 20
Scrum 21
Hybrid agile, or custom agile 23
Kanban 25
Scrumban 26
Lean UX 27
Common Terms 28
Chickens and pigs 28
Product owner 28
Scrum master 29
Sprint 30
Product backlog 30
User stories 31
Epic 32
Planning poker 32
Story-point estimation 32
Acceptance criteria 34
Burn-down chart 34
Spike 35
AgileFall 35
Jeff Patton 36
Summary 38
References 38
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
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 changed—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/enus/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.
(Continues...)
Excerpted from Agile User Experience Design by Diana DeMarco Brown Copyright © 2013 by Elsevier Inc.. Excerpted by permission of ELSEVIER.All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
