Are Agile Projects Doomed to Half-Baked Design?

Slide 1: Are Agile Projects Doomed to Half-Baked Design? Alex Chaffee alex@PivotalLabs.com Leslie Chicoine leslie@GetSatisfaction.com

Slide 2: Introduction What is Design What is Coding XP and Agile Programming Agile Design: How to merge Agile processes and design principles Q&A

Slide 3: ? Web 2.0 =

Slide 4: play Web 2.0 =

Slide 5: play faster Web 2.0 =

Slide 6: Design Methods Design

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

Slide 8: Design Methods I design.

Slide 9: Design Methods Thought Modeling Research I design. Play Communication Re-design

Slide 10: Coding Methods Coding

Slide 11: Coding Methods Scripting Databases CSS UML Diagrams Ruby Design JavaScript Coding Patterns Deploying IDEs Java Research Best Practices Debugging Object-Oriented Design Perl Model-View- Version Control Controller

Slide 12: Coding Methods I code.

Slide 13: Coding Methods Thought Modeling Research I code. Play Communication Re-design

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

Slide 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?

Slide 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

Slide 17: XP Defined Extreme Programming is an Agile Process • Values  Feedback  Communication  Simplicity  Courage

Slide 18: Collective XP Practices ”Ask the room” Ownership frequent Continuous spontaneous Integration working sessions retrospectives Pairing XP testing Practices simple design Continuous Improvement refactoring High code quality Weekly demos Suggest and agree to process changes Incremental design, On-site Customer Sustainable Pace development, design by discussion deployment “Don’t be stupid.”

Slide 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

Slide 20: XP Meets Waterfall Design Extreme Waterfall Programming Design

Slide 21: XP Meets Waterfall Design Extreme Programming Waterfall Design

Slide 22: XP Meets Waterfall Design

Slide 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

Slide 24: Agile Design Agile Design

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

Slide 26: Agile Design Embracing change Communal design ownership Evolving solutions

Slide 27: Agile Design

Slide 28: Agile Design

Slide 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

Slide 30: Agile Design “He’ll take good ideas from wherever they come from.” “He asks you, he wants to know what you think.”

Slide 31: Scales of Design Scales of Design

Slide 32: Scales of Design Concept Large Scale Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts

Slide 33: Scales of Design The Large Scale is tested in the Small Scale. The Small Scale reveals if the Large Scale ideas are solid.

Slide 34: Scales of Design Play faster.

Slide 38: Scales of Design Concept Large Scale Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts

Slide 39: Problems vs. Solutions Problems vs. Solutions

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

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

Slide 42: Problems vs. Solutions

Slide 43: Problems vs. Solutions

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

Slide 45: Problems vs. Solutions Suggest solutions Share the outcome to create buy-in

Slide 46: Open Design Open Design

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

Slide 48: Open Design Expose to create depth.

Slide 49: Scales of Open Design Concept Large Scale Business Goals User Tasks / Motivations Site Flow & Wayfinding Supporting Systems Navigation Widgets Global Styles Language Buttons Graphics Small Scale Fonts

Slide 50: Open Design

Slide 53: Open Design Small Scale as reflection of Large Scale Design emerges from simple rules

Slide 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

Slide 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

Slide 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)

Slide 57: Say Hi. Alex Chaffee alex@PivotalLabs.com Leslie Chicoine leslie@GetSatisfaction.com

Slideshare.net (beta)