Copyright
Acquisitions Editor: Meg Dunkerley
Development Editor: Heather Scherer
Project Manager: Mohanambal Natarajan
Copyeditor: Gnomi Schrift Gouldin
Morgan Kaufmann is an imprint of Elsevier
225 Wyman Street, Waltham, MA 02451, USA
First edition 2013
Copyright 2013 Elsevier Inc. All rights reserved
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of the publisher Permissions may be sought directly from Elseviers Science & Technology Rights Department in Oxford, UK: phone (+44) (0) 1865 843830; fax (+44) (0) 1865 853333; email: , and selecting Obtaining permission to use Elsevier material
Notices
Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.
Library of Congress Cataloging-in-Publication Data
Application submitted
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
For information on all Morgan Kaufmann publications visit our website at www.mkp.com
Printed and bound in USA
13 14 15 16 1710 9 8 7 6 5 4 3 2 1
ISBN: 978-0-12-415953-2
Dedication
To my daughter, my best creation
Introduction
When I found out that I was going to be supporting a project using Scrum, I was immediately wary. I did not really know much about Scrum or Agile but had the sense that these things moved at a fast pace and did not really take UX into consideration. However, I had no choice about which development process my team chose, so I set my trepidations aside and got ready to support my team.
I was fortunate that some internal experts who were advocates of the UX team were working in parallel sprints, or working a sprint ahead, to the development team. Their model seemed very logical and comfortable, and I was happy to apply the technique. Once I got started though, I noticed that a lot of factors in my situation did not match their experience and I was not entirely sure how to modify the technique to fit. My team was not colocated (although not extremely so), the team was larger than recommended, and the project had a significant infrastructure piece in addition to the user interface. None of the issues was a deal breaker, but I needed to adjust my process and I was always very uncertain about whether I was being Agile enough.
After finishing the project, I shared my experience at a local usability professionals conference, and it was eye-opening. People were so hungry for insight and guidance and had many of the same questions. However, since there was a wide variety in situations, the answer to those questions might be different for everyone. I was blown away by the different implementations of Agile UX and felt like I was not seeing enough of that diversity reflected in the dialog happening around Agile and UX. I felt that had I known there were so many ways to do Agile UX and what they were, this would have given me more confidence about my approach. I thought, Someone should write a book. Then, a few years later, I did.
The goal of this book is to show that there are many ways for a UX team to succeed, and fail, at being Agile and to illustrate that using the same set of tactics could lead to either outcome, depending on the situation. The case studies show that there are many ways to be Agile and more than a few ways for a UX team to do well in an Agile environment. I examine what contributes to a teams success and what factors to consider to determine the best path for your team to take to achieve a positive outcome. After reading this book, you will have the tools you need to determine what Agile UX means for you in your situation.
Acknowledgment
Doug DeMarco of DeMarco Interactive created the fantastic illustrations in this book.
About the Author
Diana Brown has been designing interactions and software interfaces for over a decade. She spent a good portion of that time talking to end users and finding ways to encourage them to talk to her. Much of the rest of her time has been spent talking to her development teams and finding ways to encourage them to talk to her. She continues to be amazed by all the cool things that software can do.
Chapter 1
Introduction to Agile
Contents
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.