Agile webinar 2012


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • In theory agile & UX points of view are compatibleAgile depends on setting out in a direction (to do planning, write story cards)—UX provides directionAgile depends on reliable user feedback—UX provides the feedbackSo it’s hard to see how agile could possibly work without UX techniques
  • Discuss the difference between business value and user value
  • A different way to think about development – not module by moduleRequires revisiting the same implementation for eachBenefits: More modular codeCode is easier to modify (because you did it a few times)[bring in stories one at a time]
  • A different way to think about development – not module by moduleRequires revisiting the same implementation for eachBenefits: More modular codeCode is easier to modify (because you did it a few times)[bring in stories one at a time]
  • A different way to think about development – not module by moduleRequires revisiting the same implementation for eachBenefits: More modular codeCode is easier to modify (because you did it a few times)[bring in stories one at a time]
  • A different way to think about development – not module by moduleRequires revisiting the same implementation for eachBenefits: More modular codeCode is easier to modify (because you did it a few times)[bring in stories one at a time]
  • Agile webinar 2012

    1. 1. Adopting Agile:Successful UX in an Agile WorldHugh R. BeyerCTOInContext DesignConcord, Massachusetts, Hugh Beyer, CTO 978.823.0100 Twitter: @hughrbeyer
    2. 2. UX and Agile: The promiseAgile says development in steps – and iterateUX says work with users to create value – and iterate The “ideal” product User Test What users really need
    3. 3. What is Agile development?Agile principles  Satisfy the customer with early and continuous delivery of value  Welcome changing requirements  Deliver working software frequently  Communicate through face-to-face conversation, not heavy documentation  Reflect on process regularlyAgile in practice  Goal is to deliver working software quickly  Short iterations permit management visibility into team progress  Up-front planning is minimized or nonexistent  Any work that doesn’t involve coding is downplayed
    4. 4. Core Agile processesProcesses Development Practices  Short sprints  Co-located teams  Plan each sprint at the start  No code ownership  Plans based on story cards  Test-driven design  Each sprint delivers useful  Continuous build value  Pair programming  Daily standup meetings  Validation of sprint and re-evaluation of direction at end of sprint  Reflection on process at the end of sprint
    5. 5. Phase 0
    6. 6. Driving Phase 0Issue: Getting trustworthy user insight  Customers, stakeholders, surrogates, product owners are not users • They can’t tell you what users need  Even users can’t tell you what users need  Even with a demo, users can’t tell you what they need or what to change  Users are hard to get to and rarely can be put on the team  User-centered techniques to find out how users work, invent appropriate solutions, validate and iterate those solutions  UX people on the teamIssue: figuring out what’s useful  The frame for a design comes from somewhere  Significant new functionality needs “think time”  The release planning session is not the right place for design  Even the customer/user doesn’t know what the right thing is  Even a concept needs to be tested
    7. 7. Key skill: Driving Phase 0 Phase 0 brings it together  User research, visioning, conceptual design with iteration Phase 0 Build Iterate concept with Iterate SW understanding with users with users users User Research Concept Iteration Agile Development
    8. 8. Example schedule of CD Agile Phase 0 User-centered Agile Week 1 – Gather data from 8-10 users  Compressed into a short Sprint Phase 0 • For constrained project Week 2 – Consolidate data focus only! Week 3 – Vision and storyboard Phase 0 sprints Sprint using Scrum as a process framework Week 4 – UED and UI Week 5 – Release planning & validation (2-4 users) Sprint Week 6 – Validation & redesign Sprint Development Sprint 1
    9. 9. User Stories
    10. 10. User storiesWhy user stories  Convenient structuring technique for development  Small stories enable short iterations  ―User value‖ as opposed to features – fights feature creepWhat they are  Short descriptions of functionality  Each provides user value  Rated by business value  Business value incorporates user value from Phase 0But…  Chopping the design into small stories makes it easy to lose coherence
    11. 11. Writing user storiesEach story captures one element of user value  Written to describe what is done for the user by the system  Collects features that aren’t useful on their own into one story  Splits features that can be partially or more simply implemented • Build up complex functionality over several stories • Break large stories – ―epics‖ – into smaller storiesA guide for story format  As a <role or persona> I want to <do something supported by the system> so that I <achieve something of value>  ―So that‖ clause may not be needed if working from a designEngineering tasks are not user stories  Keep the focus on value to the user
    12. 12. Examples of good user storiesGood  As a traveler, I want to see all the trips I have scheduled so I can orient to the upcoming weeks • No indication of UI at this point  As a traveler, I want to see key flight information at a glance so I can glance at it while in a hurry • Including what? Airline, flight number, departure time? Gate? Details may not be captured in the story.  As a traveler, I want to see if the flight is delayed and the current departure time so I can tell if I’m going to miss a connection • Implies lots of back-end work, so it’s split into its own story  As an admin or spouse I want to see the traveler’s itinerary so I can coordinate with them • Stories can support different user types
    13. 13. Common errors in user storiesBad  As a traveler, I want to see upcoming trips so I can know my upcoming trips • Rewritten functional requirement – do you understand the user need?  As a traveler, I want a list of all the events in my trip with an icon showing what the event is, the title of the event, its location, and key information specific to the event • Writing the design into the story  As the system, I want to collect flight information from airlines so I can present it to the user • Technical requirement masquerading as a user story  As a traveler, I want the app to be highly usable so I don’t waste my time • Non-functional requirement with no tangible deliverable
    14. 14. Fitting stories into sprintsTraditional division by layer UI Step 3 Presentation layer Step 2 DB access layer Step 1
    15. 15. Fitting stories into sprints Completed UI Story 1 (TripIt) Chicago, IL UIAs a traveler Wed, Sep 7I can see the 7:45am London to Chicagomain events 11:00am The Drake Hotelof my Presentation Thu, Sep 8itinerary to 8:30am Meetinggive anoverview ofthe trip DB access Sprint1: Minimal UI, get data to the screen
    16. 16. Fitting stories into sprints Completed UI Story 2 (TripIt) Chicago, IL UIAs a traveler Wed, Sep 7the main 7:45am London to Chicago (air, AA 99)events of my 11:00am Directions to the Drake Hotelitinerary are Presentation 11:00am The Drake Hotelshown in a Thu, Sep 8collapsibleview so I can 8:30am Meetingfocus on thepart of the DB accesstrip thatmatters Story 1: Minimal Story 2: UI structures UI, get data to the information, provides screen more info
    17. 17. Fitting stories into sprints Completed UI Story 3 (TripIt) UIAs a travelerthe mainevents of myitinerary are Presentationshown withicons andkeyinformationso I get DB accessquick details Story 1: Minimal UI, Story 2: UI structures Story 3: Fully get data to the information, provides rendered UI, full screen more info data access
    18. 18. Fitting into a sprint
    19. 19. Integrating UX and developmentWork out the interface for a story before development starts  Detailed UI design  Final iteration with usersWork with development during the iteration  Communicate design to developer  Consult on detailed behaviorTest implementation with users in the following iteration Sprint 1 Sprint 2 Sprint 3 Sprint 4 UX team UX team UX team designs designs designs story 1 story 2 story 3 UX team UX team UX team consults consults consults on story 1 on story 2 on story 3 UX team UX team tests tests story 1 story 2 Dev team Dev team Dev team builds builds builds story 1 story 2 story 3
    20. 20. Kanban view of work-in-progress Work Step 1 Buffer Work Step 2 Buffer Max size = n Max size = m  Buffers mediate between work steps  Buffers control flow—maximum size limits work in progress
    21. 21. Kanban view of 1-ahead/1behind Sprint n-1 Sprint n Sprint n+1 UX Design Development Test Limit = velocity In progress In progress In progress Buffer (Release Development Test Buffer backlog) Buffer• Release backlog acts • Stories ready to start • No need to as initial buffer development wait for next• Stories defined but • Number must be = velocity by sprint to start not in progress = start of sprint testing waste • UX works 1 ahead to fill buffer
    22. 22. In-sprint user feedbackUser-centered techniques within the sprint  Targeted interviews to understand specific tasks  Paper prototypes to work out designs and alternatives • Use rough prototypes in situ to explore options and define low-level requirements  Online prototypes and skeleton code to test user interaction • Remote testing with screen sharing can be used • Test details of appearance, layout, and behavior  User tests of running buildsAll supporting  Fast iteration of design before coding starts  Quick check of design as implemented  Close collaboration between UX designers and developers
    23. 23. Maintain a coherent UI
    24. 24. Maintain a coherent UIEngineering breaks everything into parts  Short timeframe of a sprint  Small functionality of a storyDesign has to keep things coherent  One large view of the user experience  UI and behavior consistency across the interface  Tasks supported coherently, end-to-endUX activities maintain coherence  Start with a real Phase 0  User interviews focused on work practice  UI track to look across sprints and teams  UI representations to show the coherence • User Environment Design from Contextual Design • Site maps from web development
    25. 25. Maintain a coherent UI Phase 0 for Release Sprint Sprint Sprint component planning Scope Strategic design: Initial development user effort; Phase 0 for Release Sprint Sprint Sprint research, ideation, conc plan parallel component planning ept testing streams; define roadmap Interaction Architecture Ongoing UX stream for cross-system coherence planningStrategic design phase to define roadmapParallel development streams for each component  Each stream starts with a Phase 0 for that componentParallel UX stream to maintain system coherence
    26. 26. Be a team member
    27. 27. UX as a team memberYou are a part of the team  Your problems are the team’s problems • Borrow and co-opt people  The team’s problems are your problems • Support team priorities. Be there at team meetings.  Your tasks are the team’s tasks • Track them as team tasks
    28. 28. The UX roles on an Agile project Agile activity UX role User research: field interviewsPhase 0: Setdirection & project Concepting: high-level designgoals Validation: prototyping Prioritization: customer value for releaseRelease planning User story generation Prioritization: customer value for the sprintSprint planning UX task generation and estimation UI design and detailed behavior for each user storySprint Prototyping with users for detailed behavior and lookimplementation Validation testing of completed code
    29. 29. Put the customer at the center of AgileKaren Holtzblatt, CEO Hugh Beyer,