Are Agile Projects Doomed to 

Half­Baked Design?

Alex Chaffee
alex@PivotalLabs.com
 

Leslie Chicoine
leslie@GetSatisfaction.com
   
 Introduction

What is Design
What is Coding

XP and Agile Programming

Agile Design: How to merge Agile

processes and design principles

Q&A

   
Web 2.0 = ?

   
Web 2.0 = play

   
Web 2.0 = play faster

   
 Design Methods

Design

   
 Design Methods

Graphics Information Architecture
User Flow
Concepts User Centered

Strategy
Design
Front End Coding Research

User Interface
Interactive
Interaction

   
 Design Methods

I design.

   
 Design Methods

Thought
Modelin
g

I design.
Researc
h
Play

Communicatio
n Re-
design

   
 Coding Methods

Coding

   
 Coding Methods

Scripting
Databases CSS
Ruby UML Diagrams

Coding
Design  JavaScript
Patterns

Deploying
IDEs Java Research
Debugging Best 
Object­Oriented 
Practices
Design
Perl Model­View­ Version Control
Controller

   
 Coding Methods

I code.

   
 Coding Methods

Thought
Modelin
g

I code.
Researc
h
Play

Communicatio
n Re-
design

   
 The Big Idea

“Design is finding the 
problem, not the solution.”
—Leslie Chicoine

   
 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?

   
 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

   
 XP Defined

Extreme Programming is an Agile Process
• Values

 Feedback
 Communication
 Simplicity
 Courage

   
 Collective  ”Ask the room”
XP Practices

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.”

   
 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

   
 XP Meets Waterfall Design

Extreme  Waterfall 
Programming Design

   
 XP Meets Waterfall Design

Extreme Programming Waterfall Design

   
 XP Meets Waterfall Design

   
 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

   
 Agile Design

Agile Design

   
 Agile Design

“Plans are useless, but 
planning is indispensable.”

­Dwight D. Eisenhower

   
 Agile Design

Embracing change

Communal design ownership

Evolving solutions

   
 Agile Design

   
 Agile Design

   
 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

   
 Agile Design

“He’ll take good ideas from wherever 
they come from.” 

“He asks you, he wants to know what 
you think.”

   
 Scales of Design

Scales of Design

   
 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

   
 Scales of Design

The Large Scale is tested in the Small 
Scale. 

The Small Scale reveals if the Large 
Scale ideas are solid.

   
 Scales of Design

Play faster.

   
 Scales of Design

Play faster.

   
 Scales of Design

Play faster.

   
 Scales of Design

Play faster.

   
 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

   
 Problems vs. Solutions

Problems vs. Solutions

   
 Problems vs. Solutions

“Design is finding the problem, 
not the solution.”

   
 Problems vs. Solutions

Documents as communication space

Not as blueprints

   
 Problems vs. Solutions

   
 Problems vs. Solutions

   
 Problems vs. Solutions

Expose and flesh out the problems 

While manage constraints

   
 Problems vs. Solutions

Suggest solutions

Share the outcome to create buy­in

   
 Open Design

Open Design

   
 Open Design

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

   
 Open Design

Expose to create depth.

   
 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

   
 Open Design

   
 Open Design

   
 Open Design

   
 Open Design

Small Scale as reflection of Large Scale

Design emerges from simple rules

   
 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

   
 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

   
 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)

   
 Say Hi.

Alex Chaffee
alex@PivotalLabs.com

Leslie Chicoine
leslie@GetSatisfaction.com