are agile projects doomed to halfbaked design
TRANSCRIPT
Are Agile Projects Doomed to HalfBaked Design?
Alex Chaffee [email protected]
Leslie Chicoine [email protected]
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
Redesign
Design Methods
I design.
Coding
Coding Methods
ModelView Controller
Databases
JavaScript
Java
Debugging
CSS
Version Control
IDEs Research
Coding Ruby
Design Patterns
UML Diagrams
Deploying
Perl
ObjectOriented Design
Best Practices
Scripting
Coding Methods
I code.
Coding Methods
I code. Research
Thought Modeling
Communication
Play
Redesign
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 peopleoriented 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 Onsite 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 AllHands 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 buyin
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 pixelperfect • Work literally sidebyside 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 reworking 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 unAgile) 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 permonth at first, then perweek • Invite them to your demos (remotely if need be)
