Are Agile Projects Doomed To Halfbaked Design

Preview:

Citation preview

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

Strategy 

Graphics 

User Centered 

Front End Coding 

User Interface 

Information Architecture 

Interactive Interaction 

Research 

User Flow 

Concepts 

Design Methods 

Design

I design. 

Design Methods

Research 

Thought Modeling 

Communication 

Play 

Re­design 

Design Methods 

I design.

Coding 

Coding Methods

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

I code. 

Coding Methods

I code. Research 

Thought Modeling 

Communication 

Play 

Re­design 

Coding Methods

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

—Leslie Chicoine 

The Big Idea

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?

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 

XP Defined

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

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

XP Meets Waterfall Design 

Extreme Programming 

Waterfall Design

XP Meets Waterfall Design 

Extreme Programming  Waterfall Design

XP Meets Waterfall Design

•  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

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

Agile Design

Scales of Design 

Scales of Design

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

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

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

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 

Problems vs. Solutions

Open Design 

Open Design

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

Open Design

Open Design 

Expose to create depth.

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

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)

Alex Chaffee alex@PivotalLabs.com 

Leslie Chicoine leslie@GetSatisfaction.com 

Say Hi.