WIXLIB

Are Agile MethodsGood for Design?Illustrations by mwienerarts.comJohn ArmitageDirector of User ExperienceBusinessObjects SAJohnarmitage1@hotmail.com: / 14i n t e r a c t i o n s/j a n u a r y f e b r u a r y2 0 0 4

design In a recent series of consulting projects, I servedThis seemingly anti-design approach is anathe-as the designer for a software development teamma to most designers, whose very existence dependsworking with agile development methods, widelyon representing what is to be built. Although myknown through the most severe of these methods,experience was frustrating at times, I tried to keepExtreme Programming, or XP. The most salientan open mind and was curious to learn why agileaspect of the agile methods movement [1] and ofmethods are gaining popularity. I came away withXP is emphasis on rapid, iterative releases ofinsights about software development and the designworking products at the expense of sophisticatedprocess that spurred me to write this article.planning and design.I believe that agile methods, however threatening or ridiculous they may seem, can benefit design.XP Guidelines[2,10]To understand how, let’s briefly go back to the draw- Complete product pieces sequentially, in relativeisolation of one another.ing board. Refactor the product periodically to ensure thatthe pieces fit.A Product Development MetaphorAs a kid learning to draw, I would often indulgent- Apply efforts to product construction versusrepresentations of the product.ly render small parts of a drawing in rich detail, and Create little or no documentation or specifications. Keep code and design simple and easy to change. Break down complex features until manageable.pay less attention to how these parts related to eachother. Lacking an overall spatial plan, I often endedup with gross inaccuracies that ruined the drawing.i n t e r a c t i o n s/j a n u a r y f e b r u a r y2 0 0 4: / 15

My instructional books recommended startingchange course during development, agile methodswith a light sketch to plan the composition, and thenseek to produce finished, working, reliable code forto gradually commit to areas of light and shade overwhat has been worked on. These results can bethe entire surface to evenly develop the composition.more valuable to a customer than an unfinished,Maintaining such a balanced overview of the draw-poorly written, and unreliable shadow of an initial,ing would reveal planning flaws sooner and allowoverall design.their correction. Initially I resisted drawing theseThe agile movement was instigated and pio-lines that would later need to be erased, but theneered by software developers in reaction to a frus-advice eventually worked; results became more pre-trating history of projects being delayed, going overdictable and the eraser became my friend. I still usebudget, and eventually collapsing under their ownthis fundamental approach to design complex soft-weight [6]. Tired of working stressful jobs with longware systems, and in fact it is ideal in most formalhours on doomed projects, the founders blameddesign instruction.volatile requirements and efforts to create sweeping,For digital product development, these drawingstages roughly correspond to the product’s migrationambitious, improperly targeted product designsbefore any real code had been written.through three basic forms or phases: requirements, spec-Even though development models had maturedification, and builds resulting in the final product.from being primarily ad hoc (little or no structuredCommercial development processes, however, are rarelyprocess) to waterfall phases (sequenced handoffsideal. Many approaches have been tried, and all involvefrom discipline to discipline) to more interdisciplinaryrepresenting the end product in these forms and in thisblended phases (e.g., having designers advise on theorder. Each form represents a “current version” of therequirements and developers advise on the design),product expressed in different media and detail.project results were still disappointing. Ad hocprocesses typically resulted in chaos. WaterfallAgile Methodsprocesses, and to a lesser degree blended phases,Agile methods are unique primarily in their approachexperienced trouble and delays because disciplinesto the quantity, scale, and frequency of these phases.made incorrect feasibility assumptions or acted inAgile projects are implemented more or less as aabsence of a shared product vision, or both.series of small projects (called stories in the XP lexi-If large projects could be reduced to a series ofcon), strung together into a larger, ongoing project.mini-projects that are started, finished, tested, andEach story has its own requirements, specification,delivered to the customer in quick succession, perhapsand product phases.risk could be minimized. Customers could provideAcknowledging that large, long projects often: / 16i n t e r a c t i o n s/feedback on delivered work to inform the next mini-j a n u a r y f e b r u a r y2 0 0 4

Ad hoc development. Large structural errorsare possible.Staged progression from low to high fidelity.project. Iterations would be built on one another overtime, resulting in software systems that “grow” intoexistence while actually being used, versus being“determined” ahead of time. Iterations would be testedfor reliability. In the end, customers would be able toThe ideal XP result: a series of finished piecesassembled serially into a cohesive whole.get more of what they wanted faster, because theywould have had more flexibility with the requirements.The risk of this approach is the inability to modelahead of time what is to be built (to design) and endingup with a well-crafted and reliable final product thatlacks a coherent structure and vision.One risk of phased processes:Design is accurate but implementation ispoorly crafted or unreliable.XP may appear to be merely an ad hoc processwith a catchy name, particularly in its disregard forprescriptive design in favor of building what the customer says they want or need next. Many designershave experienced the ad hoc treadmill and work hardto instill planning and discipline in the completion ofcomplex projects. Agile literature, however, purportsAnother risk of phased processes: Design neverends and implementation is never finished, asin Ted Nelson’s Xanadu [8].highly structured, disciplined methods (not alwaysextending to professional practice). XP seeks to breakdown complex features into the simplest possibleforms and quickly build them. If the result works andthe customer likes it, the feature is kept and perhapsenhanced. Below is a simple illustrative example:A. In a standard scrolling list, you can:The risk of the XP approach. Individual pieceshave value, but the larger system is disjointed.1. Select one item2. Select multiple items3. Select discontiguous itemsXP might implement a scrolling list allowing onlyitem 1. Although items 2 and 3 are plausible functionality extensions, having item 1 released sooner andThe answer: Split your time investmentbetween overall design and detailed, iterativedevelopment.more reliably could provide more value.i n t e r a c t i o n s/j a n u a r y f e b r u a r y2 0 0 4: / 17

A key piece of XP that allows it to make theinterfaces at all, which means that either they neglectpieces fit together and adapt is called refactoring.the user experience or are focusing on projects with lessRefactoring is XP’s eraser; it involves taking time outneed for sophistication in user experience (UE).from adding new features in order to rework andWhether it occurs in a large, speculative, upfrontintegrate what has been done. It’s a bit like cleaningeffort, or in small, steady steps that grow into a coher-up the mess after a long run of construction (orent product, design needs to occur nonetheless.doing redesign after much has already been builtPerhaps the main benefit provided by UE designers isand learned).the ability to imagine and represent how a disorderedXP resembles iterative design, in that bothset of functions and meanings can be synthesized har-processes use short cycles of output and feedback. Amonically. Unfortunately for designers, XP relegatesmajor difference, however, is that while iterativethe design role to short-term efforts to design andTo professional designers,agile methods are likely to bethreatening.design typically seeks to model, assess, and reviseredesign small, isolated elements. Less severe agilelarger systems at low and high fidelities, XP buildsmethods, however, can benefit from both the design-and releases smaller systems strictly at extremely higher’s vision and the practicalities of XP.fidelities.Agile Project ExperienceImplications for Design: / 18In a series of three client-server software developmentTo professional designers, agile methods are likely toprojects, our consulting team (two designers, onebe threatening. In agile proponent Martin Fowler’sproject manager, one analyst, two to four developers)essay “Is Design Dead?” [4] his rhetorical answer isworked with a client-driven agile process that fea-actually “no.” However, his use of design refers totured one- to two-week release cycles. The productstechnical design versus user experience design [5]. Inwere a touchscreen-based, media search-and-playfact, the agile community rarely mentions users or usersystem for general recreational use and two relatedi n t e r a c t i o n s/j a n u a r y f e b r u a r y2 0 0 4

Figure 1. Multi-layered design efforts in a six-story agileproject. Dedicated UE design efforts are in red.cataloging applications for use by a small group ofmedia librarians. All the products had high standardsfor usability and appeal, so we were reluctant to abandon our user-centered design practices.We evolved a hybrid approach that requireddesign work on three levels, done in parallel. The lowlevel effort (typical for XP) supported the short-termFigure 2. The component planning process.iterations by providing detailed component designsto drive construction. A second level presented lowfidelity redesigns of existing builds in order to informrefactoring effort. This split duty limited the designer’s ability to optimize either effort with just “onepass,” but because all design and product assets wereflexibly built, it was easy to layer on improvements asthe project progressed. In the later efforts, as detailedlater, we were able to design on a third level to provide overall product vision (see Figure 1).Usage scenarios drove our design effort, takingthe form of linear, Shockwave-based ryboards showed how users would use a series ofcomponents, or groups of user-interface (UI) functionality (such as a browser tree, a form, or a dialogbox), to complete a task. In the storyboards, thedesign would show typical (not comprehensive)depictions of these components, just enough to gatherfeedback from users and stakeholders on the design’soverall merit. Concurrently, and upon design validation, the customer and engineering team would prioritize components for development and assign them toiterations (see Figure 2).Components chosen for an iteration were theni n t e r a c t i o n s/j a n u a r y f e b r u a r y2 0 0 4: / 19