1. Are Agile Projects Doomed to Half-Baked Design? Alex Chaffee alex@PivotalLabs.com Leslie Chicoine leslie@GetSatisfaction.com

2. Introduction What is Design What is Coding XP and Agile Programming Agile Design: How to merge Agile processes and design principles Q&A

3. Web 2.0 = ?

4. play

5. Web 2.0 = play faster

6. Design Methods Design

7. Strategy Graphics User Centered Front End Coding User Interface Information Architecture Interactive Interaction Research User Flow Concepts Design Methods Design

8. I design. Design Methods

9. Research Thought Modeling Communication Play Re-design Design Methods I design.

10. Coding Coding Methods

11. Model-View- Controller Databases JavaScript Java Debugging CSS Version Control IDEs Research Coding Ruby Design Patterns UML Diagrams Deploying Perl Object-Oriented Design Best Practices Scripting Coding Methods

12. I code. Coding Methods

13. I code. Research Thought Modeling Communication Play Re-design Coding Methods

14. “Design is finding the problem, not the solution.” —Leslie Chicoine The Big Idea

15. The hard problems are… people problems –(mis-) communication –(not enough) feedback –(not fully) comprehending constraints process problems –deadline and resource management –design flexibility in the face of frequent change Where can we find a people-oriented process, and process- oriented people?

16. Extreme Programming is an Agile Process –Motto: Embrace Change –Other Agile Processes include Scrum, Crystal Clear, Adaptive Software Development, Feature Driven Development, DSDM, Agile Modeling XP Defined

17. Extreme Programming is an Agile Process Values  Feedback  Communication  Simplicity  Courage XP Defined

18. XP Practices Collective Ownership Pairing Continuous Improvement Continuous Integration testing refactoring simple design High code quality Sustainable Pace On-site Customer design by discussion frequent spontaneous working sessions Suggest and agree to process changes ”Ask the room” “Don’t be stupid.” retrospectives Incremental design, development, deployment Weekly demos XP Practices

19. XP Cycles –Rapid Iteration, small releases –Frequent planning/design sessions Iteration Planning, Release Planning Break down requirements into stories into tasks Daily Standup Regular All-Hands Retrospectives –Frequent (weekly) demos of deployed, 100% functional software real code, real db, real ui, but only some of the stories coders, clients, designers, PMs are all in the room XP Cycles

20. XP Meets Waterfall Design Extreme Programming Waterfall Design

21. XP Meets Waterfall Design Extreme ProgrammingWaterfall Design

22. XP Meets Waterfall Design

23. The three things we do in XP that any team should do  Weekly demos  Daily standups  Pairing Caution: May provoke resistance and hostility XP Staples

24. Agile Design

25. “Plans are useless, but planning is indispensable.” -Dwight D. Eisenhower Agile Design

26. Embracing change Communal design ownership Evolving solutions Agile Design

29. “Make it OK for people to challenge an idea or two, the good ideas can withstand it and the weaker ideas fall away and make room for something [better].” -Brad Bird, Writer/Director of the Incredibles Agile Design

30. “He’ll take good ideas from wherever they come from.” “He asks you, he wants to know what you think.” Agile Design

31. Scales of Design

32. Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Fonts Large Scale Small Scale Scales of Design

33. The Large Scale is tested in the Small Scale. The Small Scale reveals if the Large Scale ideas are solid. Scales of Design

34. Play faster. Scales of Design

35. Play faster. Scales of Design

36. Play faster. Scales of Design

37. Play faster. Scales of Design

38. Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Fonts Large Scale Small Scale Scales of Design

39. Problems vs. Solutions

40. “Design is finding the problem, not the solution.” Problems vs. Solutions

41. Documents as communication space Not as blueprints Problems vs. Solutions

44. Expose and flesh out the problems While manage constraints Problems vs. Solutions

45. Suggest solutions Share the outcome to create buy-in Problems vs. Solutions

46. Open Design

47. Agile demands open: it’s got to be flexible and extensible. Open Design

48. Expose to create depth.

49. Concept Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Fonts Large Scale Small Scale Scales of Open Design

50. Open Design

53. Small Scale as reflection of Large Scale Design emerges from simple rules

54. Designers should… Design a week in advance of coding Not make your mockups pixel-perfect Work literally side-by-side with coders when implementing mockups Allow coders to participate in IA/UI design — Especially after the coding has already started

55. Coders should… Coders should ask designers… or else –time is wasted re-working solved issues –solutions are implemented that don't work with other parts of the designed system –coders make assumptions based on mockups Coders should give frequent live demos… or else –designers don't know what parts of the design are/aren't working –designers don't know what parts of the design aren't working together –coders don't know their code has bugs or needs tweaking

56. How to integrate with an outside design company? Communication and feedback are naturally more stretched out Some unnatural (or at least un-Agile) barriers are imposed –Time and space –Signoff procedures –Documentation / specs –Perfectionism –Mistrust Bring them in to your process as much as you can Don’t force them to adapt too much or they’ll resent and demonize you Iterate per-month at first, then per-week Invite them to your demos (remotely if need be)

57. Alex Chaffee alex@PivotalLabs.com Leslie Chicoine leslie@GetSatisfaction.com Say Hi.