Making Sense of UCD and Agile

Making Sense of UCD and Agile Jeff Patton Agile Product Design [email_address] Lane Halley Cooper [email_address] Chifoo, May 6 th , 2009

Things you may have heard about “Agile”

“ no planning!”

“ no up front design!”

“ no documentation!”

“ no handoff!”

“ self-managed teams!”

“ a fad that’ll go away soon!”

“ undisciplined!”

“ only works with small teams!”

“ an excuse for poor quality!”

Software development has always been difficult

There’s a long history of software project failures

Standish Group’s Chaos Reports still report most projects fail or finish challenged

Agile’s strongest themes in response to years of failure in death march projects following waterfall -style processes

Yourdon’s 1997 book “Death March” characterized under-staffed under-budgeted projects doomed to failure

Agile ideas germinated during the 1990s

1970: Royce’s paper describes waterfall process and explains missing feedback loops

1986: Brook’s “No Silver Bullet” describes iterative and incremental development

1994: DSDM published (Dynamic Systems Development Methodology)

1995: Schwaber & Sutherland document Scrum (based on 1986 HBR Paper)

1997: Cockb u rn describes Crystal Methodologies

1998: Coad describes FDD (Feature Driven Development)

2000: Highsmith describes Adaptive Software Development

2000: Beck publishes Extreme Programming

The term “agile” coined by lightweight process reps

February 2001: 17 Representatives gather at Snowbird Ski Resort in Salt Lake City

The outcome wasn’t a common process, but a common set of values: The Agile Manifesto

Since then the manifesto has attracted other

like-minded groups

Lean Software Development

Product Management

Portfolio management

Non-software projects

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding To Change over Following a Plan

That is, while there is value in the items

on the right, we value the items on

the left more.

Agile values motivate agile process

Agile values are articulated in the Agile Manifesto and 12 Principles

Agile success is measured through value alignment, not process compliance

May 6, 2009 Individuals & Interactions Working Software Customer Collaboration Responding to Change Sustainable Development Technical Excellence Simplicity Self-Organizing Teams Reflection Early and Continuous Delivery Welcoming Changing Requirements Business People and Developers Work Together Motivated Individuals Face-to-Face Conversation © 2006-2009 Jeff Patton, Lane Halley All rights reserved

Today Scrum dominates as the simple agile process framework of choice

Scrum describes only 3 simple roles:

The Product Owner

Describes that the product should be, and is ultimately responsible for its success

The Team

Everyone responsible for constructing the product

The Scrum Master

Makes sure the process is working, and all roles are collaborating effectively

The Scrum process (snowman) May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved Daily Planning Meeting (the Daily Scrum) The team synchronizes daily in a short morning standup meeting or daily scrum Product Owner identified a potential product idea In Sprint Planning the Product Owner & team plan the next sprint or iteration The team works towards the iteration/sprint goals in a 1-4 week time box In a Product Review the product owner and team gather to review the results of the last sprint and reflect on how the product and process could improve Product Backlog Product Goals Sprint Backlog Working Evaluated Software Product Owner supported by others creates the product backlog Iteration or Sprint 1-4 week cycle The team keeps progress visible with burndown charts and task boards.

Today’s agile processes mix-and-match techniques from a growing agile buffet

You may hear people using these agile techniques

User Stories

Product backlog

The Planning game

Planning poker

User stories

Burndown chart

May 6, 2009

Task board

Test driven development

Refactoring

Daily Stand-Up

Retrospective

The Scrum mantra “inspect and adapt” applies to your growing product , your project plan, and the process you follow

Teams add and remove techniques flexibly

Agile process is tailored to the organization and team within the organization

Consider a Venture-funded startup

Developing a product from scratch

Small team of developer/generalists

Work together in the same space

“ Customer” is the Founder/CEO

Users hard to identify precisely

Consider a Large internal IT organization

Maintaining/extending an existing system

Large team with more specialized roles (developers, BAs, UE, PMs, QA, etc.)

Some members co-located, some remote

“ Customer” is a business owner

Users are well known and accessible

What’s different about these contexts that would require specific process changes?

Mature consumer product companies

Large multi-national banks

Small collocated teams

Large distributed teams

Bringing UCD and agile together iStockPhoto.com/eyeidea

Some aspects of Agile cause frustration

Agile lacks tools to define business and customer needs and measure product success

An agile “ product owner ” may not accurately represent the user needs

It’s hard to see the “ big picture” when you’re building incrementally

Finding the right level of design documentation

Common ground

Interaction Designers share many values with agile practitioners:

Desire to build successful products

Focus on providing what people value

“ User stories ” instead of “ features ”

Agile work styles have many benefits

Agile is about shared responsibility

Agile is about effective communication

Agile helps you fail quickly

Agile is a more humane way to work

Agile processes lead to good partnerships

No edicts – “A user story is an invitation to a conversation”

Visual communication – “working code over comprehensive documentation,” prototypes, wireframes, mockups

Transparent process – stand ups, backlogs, information radiators

Two different sets of expertise

Ingrid, Interaction Designer

Dave , Developer

May 6, 2009 HCI degree Paper, Visio, Axure Knows UI design patterns Likes to spend time with users

CS degree

Ruby, CSS, Pivotal Tracker

Knows Web dev. best practices

Likes to write code

Two different comfort zones

Interaction designers and developers each have a different “comfort zone” when solving problems.

Designers focus on the probable

Developers focus on the possible

Some tips for a good working relationship

If you’re an interaction designer

Be a facilitator

Conversations, not directives

Use visual communication

Help the team understand user needs, behaviors and attitudes

Some tips for a good working relationship

If you’re a developer

You are not the user

Look for the common case

Learn design principles and patterns

Ask “who is this for?” and “what problem does this solve?”

Agile has changed the role of testing

Before…

Testing was a specialized role

Testing was done at end of the process

Now…

Testing integrated in agile process

Testers participate in new ways :

Write code alongside developers

Work with the product owner to define acceptance criteria

How will agile change the role of IxD?

Now…

Interaction design is a specialized role

Interaction design done at the beginning of the process

Later?…

Interaction design integrated in agile process

Interaction designers participate in new ways :

Front-end UI development alongside developers

Work with product owner to articulate and validate the product concept

The role of the interaction designer

Help product managers and other business stakeholders understand and balance business and user goals

Identify patterns of user behaviors and attitudes and model them through personas, workflows and scenarios

Help developers understand the underlying product framework and define interaction and visual design patterns

The role of the interaction designer

Facilitate brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions

Quickly iterate through different design solutions as low-fidelity sketches to help developers save time and make good decisions

Be the team member responsible for user experience throughout the process

Patterns for success iStockPhoto.com/rmfox

Patterns for success

Put UX in the navigator’s seat

UX is an important part of the product owner team

Become a design facilitator

Do just enough research and design to get started

Research, model, and design up front, but lightly

Plan for continual ongoing user contact for research and validation

Focus on the big picture

Identify and communicate the overall story of the interface so you can work on smaller parts while maintaining context

Use good UX practices to support product development

Use parallel track develop-ment to work ahead, and follow behind

May 6, 2009 See Miller’s Case Study of Customer Input For a Successful Product: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf © 2006-2009 Jeff Patton, Lane Halley All rights reserved

Patterns for success May 6, 2009 implement iteration 1 features

support iteration 1 development

design iteration 2 features

gather user input for iteration 3 features

implement iteration 2 features fix iteration 1 bugs if any

validate iteration 1 features

implement iteration 3 features fix iteration 2 bugs if any

validate iteration 1-2 features

planning

data gathering

high level design

design for iteration 1 features

development environment setup

architectural “spikes”

iteration 0 Iteration1 Iteration 2 Iteration 3 feature design coded features feature design + bugs found in usability testing support dev support dev See Miller’s Case Study of Customer Input For a Successful Product:: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf © 2006-2009 Jeff Patton, Lane Halley All rights reserved Product Owner Team time