Agile User Experience Design. A Practitioner�s Guide to Making It Work

178 Pages·2012·1.749 MB·English

by  Diana Brown (Eds.)

Agile User Experience
Design
’
A Practitioner s Guide to
Making It Work
Diana DeMarco Brown
AMSTERDAM(cid:1)BOSTON(cid:1)HEIDELBERG(cid:1)LONDON(cid:1)NEWYORK(cid:1)OXFORD
PARIS(cid:1)SANDIEGO(cid:1)SANFRANCISCO(cid:1)SINGAPORE(cid:1)SYDNEY(cid:1)TOKYO
MorganKaufmannisanimprintofElsevier
AcquisitionsEditor:MegDunkerley
DevelopmentEditor:HeatherScherer
ProjectManager:MohanambalNatarajan
Copyeditor:GnomiSchriftGouldin
MorganKaufmannisanimprintofElsevier
225WymanStreet,Waltham,MA02451,USA
Firstedition2013
Copyright(cid:1)2013ElsevierInc.Allrightsreserved
Nopartofthispublicationmaybereproduced,storedinaretrievalsystemortransmittedinanyformorbyanymeanselectronic,
mechanical,photocopying,recordingorotherwisewithoutthepriorwrittenpermissionofthepublisherPermissionsmaybe
soughtdirectlyfromElsevier‘sScience&TechnologyRightsDepartmentinOxford,UK:phone[phone];fax
([phone];email:[e-mail]tyourrequestonlinebyvisitingthe
Elsevierwebsiteathttp://elsevier.com/locate/permissions,andselectingObtainingpermissiontouseElseviermaterial
Notices
Knowledgeandbestpracticeinthisfieldareconstantlychanging.Asnewresearchandexperiencebroadenourunderstanding,
changesinresearchmethodsorprofessionalpractices,maybecomenecessary.Practitionersandresearchersmustalwaysrelyon
theirownexperienceandknowledgeinevaluatingandusinganyinformationormethodsdescribedherein.Inusingsuch
informationormethodstheyshouldbemindfuloftheirownsafetyandthesafetyofothers,includingpartiesforwhomthey
haveaprofessionalresponsibility.
Tothefullestextentofthelaw,neitherthePublishernortheauthors,contributors,oreditors,assumeanyliabilityforany
injuryand/ordamagetopersonsorpropertyasamatterofproductsliability,negligenceorotherwise,orfromanyuseor
operationofanymethods,products,instructions,orideascontainedinthematerialherein.
LibraryofCongressCataloging-in-PublicationData
Applicationsubmitted
BritishLibraryCataloguinginPublicationData
AcataloguerecordforthisbookisavailablefromtheBritishLibrary
ForinformationonallMorganKaufmannpublications
visitourwebsiteatwww.mkp.com
PrintedandboundinUSA
1314151617 10987654321
ISBN:978-0-12-415953-2
To my daughter, my best creation
Introduction
WhenIfoundoutthatIwasgoingtobesupportingaprojectusingScrum,Iwas
immediately wary. I did not really know much about Scrum or Agile but had
thesensethatthesethingsmovedatafastpaceanddidnotreallytakeUXinto
consideration.However,Ihadnochoiceaboutwhichdevelopmentprocessmy
teamchose, soI set my trepidations asideand got ready to supportmy team.
IwasfortunatethatsomeinternalexpertswhowereadvocatesoftheUXteam
wereworkinginparallelsprints,orworkingasprintahead,tothedevelopment
team. Their model seemed very logical and comfortable, and I was happy to
applythetechnique.OnceIgotstartedthough,Inoticedthatalotoffactorsin
mysituationdidnotmatchtheirexperienceandIwasnotentirelysurehowto
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 adeal breaker,but Ineededtoadjust myprocess andI was always
veryuncertain about whether Iwas beingAgile enough.
After finishing the project, I shared my experience at a local usability profes-
sionals’conference,anditwaseye-opening.Peopleweresohungryforinsight
andguidance andhadmanyofthesamequestions.However,sincetherewas
awidevarietyinsituations,theanswertothosequestionsmightbedifferentfor
everyone.IwasblownawaybythedifferentimplementationsofAgileUXand
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, afew 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
studiesshowthattherearemanywaystobeAgileandmorethanafewwaysfor
aUXteamtodowellinanAgile environment.Iexaminewhatcontributesto xi
xii Introduction
a team’s success and what factors to consider to determine the best path for
your team to take to achieve apositive outcome.After reading thisbook, you
willhavethetoolsyouneedtodeterminewhatAgileUXmeansforyouinyour
situation.
ACKNOWLEDGMENT
DougDeMarcoofDeMarcoInteractivecreatedthefantasticillustrationsinthisbook.
About the Author
DianaBrownhasbeendesigninginteractionsandsoftwareinterfacesforover
a decade. She spent a good portion of that time talking to end users and
findingwaystoencouragethemtotalktoher.Muchoftherestofhertimehas
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.
xiii
CHAPTER 1
Introduction to Agile
CONTENTS
Introduction...................................................................................................2
Agile Valuesþ UX........................................................................................4
Individualsandinteractionsoverprocessesandtools..................................................5
Workingsoftwareovercomprehensivedocumentation................................................6
Customercollaborationovercontractnegotiation..........................................................7
Respondingtochangeoverfollowingaplan..................................................................8
Agile Principles þ UX...................................................................................9
Principle1..........................................................................................................................10
Principle2..........................................................................................................................11
Principle3..........................................................................................................................11
Principle4..........................................................................................................................12
Principle5..........................................................................................................................13
Principle6..........................................................................................................................14
Principle7..........................................................................................................................15
Principle8..........................................................................................................................16
Principle9..........................................................................................................................17
Principle10........................................................................................................................18
Principle11........................................................................................................................19
Principle12........................................................................................................................19
Common Methods.......................................................................................20
Crystal................................................................................................................................20
ExtremeProgramming(XP).............................................................................................20
Scrum..................................................................................................................................21
Hybridagile,orcustomagile..........................................................................................23
Kanban...............................................................................................................................25
Scrumban...........................................................................................................................26
LeanUX..............................................................................................................................27
Common Terms...........................................................................................28
Chickensandpigs............................................................................................................28
Productowner...................................................................................................................28
Scrummaster.....................................................................................................................29
Sprint..................................................................................................................................30
Productbacklog.................................................................................................................30
Userstories........................................................................................................................31 1
AgileUserExperienceDesign.http://dx.doi.org/10.1016/B978-0-12-415953-2.00001-7
Copyright(cid:1)2013ElsevierInc.Allrightsreserved.
2 CHAPTER 1: Introduction to Agile
Epic.....................................................................................................................................32
Planningpoker..................................................................................................................32
Story-pointestimation......................................................................................................32
Acceptancecriteria...........................................................................................................34
Burn-downchart...............................................................................................................34
Spike...................................................................................................................................35
AgileFall.............................................................................................................................35
JeffPatton..........................................................................................................................36
Summary......................................................................................................38
References...................................................................................................38
INTRODUCTION
TounderstandwhatitmeanstopracticeanAgileformofuser-centereddesign,
itisimportanttohaveasenseofwhatexactlyAgilemeansandwheretheterm
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,conferencepresentations,andwebsites,allofwhichhavetheirowntake
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
experiencepractitioner.Iencourageeveryonetospendsometimeexploringthe
manyresourcesthatareavailable to geta deeper understandingof thephilos-
ophyandthevariousmethodsforapplyingitthathavegrownupalongtheway.
It is also important to recognize that there is no one single right way to
implementAgiledesign.Atitscore,“Agile”isasetofvaluestouseascompassto
guideateamthroughtheproductionofsoftware.Whateverprocessortoolsare
usedandhowtheyareappliedaresecondarytotheoverallgoalsofempowering
ahighlyfunctionalteamasitbuildsgreatsoftwaretothedelightofitsendusers.
Agileisatermthatgrewoutofeffortsinthe1990stofindabetterdevelopment
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
satisfyendusers.Additionally,productioncyclesneededtobeabletoadaptand
accommodate the reality of shifting requirements. Waterfall development
makesitespeciallychallengingforteamstorespondtoissues,mostlybecauseit
isinherentlyunabletodiscoverseriousproblemswiththedesign,architecture,
orthecodeitselfearlyinthecycleandcanreallyidentifythemonlywhenitis
toolateforacorrection.Notknowingwhatproblemsmightexistuntiltheend
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
specificationsoverthewalltodevelopmentteams,whothrowtheircodeoverto
Introduction 3
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 eachdeliverable,eachteam is playinga game of telephone and
putting its own interpretation on the requirements or the specifications. As in
thetelephonegame,theendresultveryrarelymatchestheoriginalintention.
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
checkonwhetherornotyouareontrackwithyourownAgileimplementation.
Whilethemethods,techniques,andterminologyhaveevolvedsince2001,the
core values of Agile havenot. Themanifesto eloquentlystates:
“Weareuncoveringbetterwaysofdeveloping
softwarebydoingitandhelpingothersdoit.
Throughthisworkwehavecometovalue:
Individualsandinteractionsoverprocessesandtools
Workingsoftwareovercomprehensivedocumentation
Customercollaborationovercontractnegotiation
Respondingtochangeoverfollowingaplan
Thatis,whilethereisvalueintheitemson
theright,wevaluetheitemsontheleftmore”
TheManifestoforAgileSoftwareDevelopment,agilemanifesto.org
FIGURE1.1
Theagileprocess.
4 CHAPTER 1: Introduction to Agile
AGILE VALUES D UX
The manifesto provides the best guidancefor and is the most succinct expres-
sionofthevaluesthatshoulddriveanAgileorganization.Adescriptionofthe
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
expressedinthemanifestoitself.Whilereferencingsomethingthatwaswritten
solongagomightfeeloldfashioned,Ifindthatthesevaluesarejustasrelevant
now as when they were first created. In software years, 2001 was a very long
timeago;andwhileitwasnotquitetheDarkAges,itmightwellbeanalogous
totheAtomicAge.Afterall,2001wastheyearthatmanyovervalueddotcoms
wentunder,thefirst-generationiPodswereintroduced,MicrosoftreleasedXP,
and several years ahead of the introduction of the ubiquitous Facebook. UX
(userexperience)practitionersareworkingtodaywhohavenomemoryofthat
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
beyonditsoriginalmanifesto.Afterall,howmanysoftwareconceptsstillhold
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
productionteamsstillstrugglewithprocessesthatoftenfocusonthemilestone
deliverables instead of keeping their eyes on the shipping product. Rarely is
areleasecyclenotsubjecttochangingneedsfromstakeholders,butrarerstillis
the process that can support responding to such a changedunless you are
working in an Agile environment. The intention of the Agile Manifesto is to
defineavaluesystemthatallowsforthecreationofaculturethatcanrespond
tothesesituations,whilerecognizingthevalueoftheindividualteammember,
andproducegoodsoftware.WhiletheAgileManifestolaysoutthecorevalues
ofanAgileenvironment,manytechniquescanbuildaprocessandaframework
to support those values. Examining these values through a UX lens can show
that there is anatural 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
whichweallholdourselves.Infact,despitedefinitionsoftheprocessforuser-
centered design, there is no formal expression of its value system, beyond the
ideathatwewanttokeeptheuser’sneedscentraltothedesignprocess.Things
start to get even more vague regarding UX principles. It is not that no UX
principlesarewrittendown,butthatdifferentUXprinciplesarewrittendown
by many people. Quite a few people have their own spin on UX design prin-
ciples,includingMicrosoft,whichhasdefined theUXprinciplesfor Windows
andsharedtheseprinciplesonitswebsite(seehttp://msdn.microsoft.com/en-
us/library/windows/desktop/dd834141.aspx). Most of the definitions of UX