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. Web 2.0 = play

5. Web 2.0 = play faster

6. Design Methods
Design

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

8. Design Methods
I design.

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

10. Coding Methods
Coding

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. Coding Methods
I code.

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

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

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. 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. XP Defined
Extreme Programming is an Agile Process
• Values
§Feedback
§Communication
§Simplicity
§Courage

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. 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. XP Meets Waterfall Design
Extreme Waterfall
Programming Design

21. XP Meets Waterfall Design
Extreme Programming Waterfall Design

22. XP Meets Waterfall Design

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. Agile Design
Agile Design

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

26. Agile Design
Embracing change
Communal design ownership
Evolving solutions

27. Agile Design

28. Agile Design

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. Agile Design
“He’ll take good ideas from wherever
they come from.”
“He asks you, he wants to know what
you think.”

31. Scales of Design
Scales of Design

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. Scales of Design
The Large Scale is tested in the Small
Scale.
The Small Scale reveals if the Large
Scale ideas are solid.

34. Scales of Design
Play faster.

35. Scales of Design
Play faster.

36. Scales of Design
Play faster.

37. Scales of Design
Play faster.

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. Problems vs. Solutions
Problems vs. Solutions

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

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

42. Problems vs. Solutions

43. Problems vs. Solutions

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

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

46. Open Design
Open Design

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

48. Open Design
Expose to create depth.

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. Open Design

51. Open Design

52. Open Design

53. Open Design
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. Say Hi.
Alex Chaffee
alex@PivotalLabs.com
Leslie Chicoine
leslie@GetSatisfaction.com