Are Agile Projects Doomed To Halfbaked Design


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Are Agile Projects Doomed To Halfbaked Design

  1. 1. Are Agile Projects Doomed to  Half­Baked Design?  Alex Chaffee  Leslie Chicoine
  2. 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. 3. Web 2.0 =  ?
  4. 4. Web 2.0 =  play
  5. 5. Web 2.0 =  play faster
  6. 6. Design Methods  Design
  7. 7. Design Methods  Graphics  Information Architecture  User Flow  Concepts  User Centered  Strategy  Design Front End Coding  Research  User Interface  Interactive  Interaction 
  8. 8. Design Methods I design. 
  9. 9. Design Methods  Thought  Modeling  Research  I design. Play  Communication  Re­design 
  10. 10. Coding Methods Coding 
  11. 11. Coding Methods Scripting  Databases  CSS  Ruby  UML Diagrams  Design  JavaScript  Patterns  Coding  Deploying  IDEs  Java  Research  Debugging  Best  Object­Oriented  Practices  Design  Perl  Model­View­  Version Control  Controller 
  12. 12. Coding Methods I code. 
  13. 13. Coding Methods Thought  Modeling  Research  I code.  Play  Communication  Re­design 
  14. 14. The Big Idea “Design is finding the  problem, not the solution.”  —Leslie Chicoine 
  15. 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. 16. XP Defined 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 
  17. 17. XP Defined Extreme Programming is an Agile Process  •  Values  §Feedback  §Communication  §Simplicity  §Courage 
  18. 18. Collective  XP Practices ”Ask the room”  Ownership  Continuous  frequent  Integration  spontaneous  working sessions  retrospectives  Pairing  testing  XP  Continuous  Practices  simple design  Improvement  refactoring  High code quality  Weekly demos  Suggest and agree to  process changes  Incremental  design,  On­site Customer  Sustainable Pace  development,  deployment  design by discussion  “Don’t be stupid.” 
  19. 19. XP Cycles 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 
  20. 20. XP Meets Waterfall Design  Extreme  Waterfall  Programming  Design
  21. 21. XP Meets Waterfall Design  Extreme Programming  Waterfall Design
  22. 22. XP Meets Waterfall Design
  23. 23. XP Staples •  The three things we do in XP that any team  should do  § Weekly demos  § Daily standups  § Pairing  Caution: May provoke resistance and hostility 
  24. 24. Agile Design Agile Design 
  25. 25. Agile Design “Plans are useless, but  planning is indispensable.”  ­Dwight D. Eisenhower 
  26. 26. Agile Design Embracing change  Communal design ownership  Evolving solutions 
  27. 27. Agile Design
  28. 28. Agile Design
  29. 29. Agile Design “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 
  30. 30. Agile Design “He’ll take good ideas from wherever  they come from.”  “He asks you, he wants to know what  you think.” 
  31. 31. Scales of Design Scales of Design 
  32. 32. Scales of Design Large Scale  Concept  Business Goals  User Tasks / Motivations  Site Flow & Wayfinding  Supporting Systems  Navigation  Widgets  Global Styles  Language  Buttons  Graphics  Small Scale  Fonts 
  33. 33. Scales of Design The Large Scale is tested in the Small  Scale.  The Small Scale reveals if the Large  Scale ideas are solid. 
  34. 34. Scales of Design Play faster. 
  35. 35. Scales of Design Play faster. 
  36. 36. Scales of Design Play faster. 
  37. 37. Scales of Design Play faster. 
  38. 38. Scales of Design Large Scale  Concept  Business Goals  User Tasks / Motivations  Site Flow & Wayfinding  Supporting Systems  Navigation  Widgets  Global Styles  Language  Buttons  Graphics  Small Scale  Fonts 
  39. 39. Problems vs. Solutions Problems vs. Solutions 
  40. 40. Problems vs. Solutions “Design is finding the problem,  not the solution.” 
  41. 41. Problems vs. Solutions Documents as communication space  Not as blueprints 
  42. 42. Problems vs. Solutions
  43. 43. Problems vs. Solutions
  44. 44. Problems vs. Solutions Expose and flesh out the problems  While manage constraints 
  45. 45. Problems vs. Solutions Suggest solutions  Share the outcome to create buy­in 
  46. 46. Open Design Open Design 
  47. 47. Open Design Agile demands open: it’s got to be  flexible and extensible. 
  48. 48. Open Design  Expose to create depth.
  49. 49. Scales of Open Design Large Scale  Concept  Business Goals  User Tasks / Motivations  Site Flow & Wayfinding  Supporting Systems  Navigation  Widgets  Global Styles  Language  Buttons  Graphics  Small Scale  Fonts 
  50. 50. Open Design
  51. 51. Open Design
  52. 52. Open Design
  53. 53. Open Design  Small Scale as reflection of Large Scale  Design emerges from simple rules
  54. 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. 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. 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. 57. Say Hi. Alex Chaffee  Leslie Chicoine