are agile projects doomed to half-baked design? alex chaffee alex@pivotallabs.com leslie chicoine...

Post on 28-Dec-2015

217 Views

Category:

Documents

2 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Are Agile Projects Doomed to Half-Baked Design?

Alex Chaffeealex@PivotalLabs.com

Leslie Chicoineleslie@GetSatisfaction.com

Introduction

What is DesignWhat 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

InteractiveInteraction

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

CodingRuby

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

FeedbackCommunicationSimplicityCourage

XP Defined

XP Practices

Collective Ownership

Pairing

Continuous Improvement

Continuous Integration

testing

refactoring

simple design

High code quality

Sustainable PaceOn-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

ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts

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

ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts

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.

ConceptBusiness GoalsUser Tasks / MotivationsSite Flow & WayfindingSupporting SystemsNavigationWidgetsGlobal StylesLanguageButtons GraphicsFonts

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 Chaffeealex@PivotalLabs.com

Leslie Chicoineleslie@GetSatisfaction.com

Say Hi.

top related