Pre-Conference Course: UX and Agile: Making a Great Experience -

UX and Agile:
Making a Great Experience
UXPA, June 22, 2015, Coronado, California

Introductions
• Thyra
• John
• Carol

Review of Agile and Language Used

Agile History
• February 2001:The Agile Manifesto written
at Snowbird Ski Resort in Utah
• Authors:14 male software engineers
• Agile, as originally conceived, understood nothing
of UCD or UX processes

Agile Manifesto (abbreviated)
• Uncovering better ways of developing software…
• 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
There is value in the items on the right,
we value the items on the left more.
http://agilemanifesto.org/

Agile Qualities
• Iterative
• Incremental
• Continuous
• Collaborative
• Transparent

Agile Frustrations
Scaling Agile at Spotify via Slideshare of Vlad Mysla
http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14

Agile
• Agile is a philosophy, not a specific set of tools
• Scrum, Kanban, XP, etc. are software development
methods that meet the criteria for Agile – “Waterfall”
does not.
• 12 Principles are not mandates
UX is not deliberately excluded
Can work to make a good fit

We Come from Different Places
By Jeff Patton as interpreted by Jim Laing – Source: http://www.agileproductdesign.com/blog/user_experience_relevance.html

Agile UX:The Good
• Contextual inquiry & usability testing on actual product
• User data has effect on current release
• Satisfying to see designs in real use
• Enables requirements iteration
• Issues get fixed
• “Done” includes design
• Most important features are done first

Agile UX:The Good (continued)
• Less “design drift”
• Less wasted design
• Working together (face-to-face) is better than “over the wall”
• Keep up with technology and environmental changes

UX Must Adapt or Risk Exclusion
• Don’t be selfish
• Distribute the work
• Agile is reactive – no time for predictive work
• Prepare to react
• Falling short of end goals is a constant
• Empower teams to meet user’s primary needs
• Constant Improvement is key
Jim Laing at UX Pittsburgh, May 2014

Story Myths
• Story = feature
• Story = specification
• Story must fit in one iteration
• Stories are time limited
• All stories have firm estimates and specs in Iteration Zero
(or even Iteration One)
• These are NOT true.

“Story”
=
User Problem
with acceptance criteria

Story Examples
Advantages of the “As a user, I want” user
story template. By Mike Cohn
http://www.mountaingoatsoftware.com/blog/a
dvantages-of-the-as-a-user-i-want-user-
story-template

Customer Feedback – in Traditional Agile
• “Customers” give feedback at the end of each
iteration/sprint, after seeing a demo by a product owner
or engineer (“User AcceptanceTesting”)
• Not typically a member of the Agile team (good!)
• Rarely the users the system is being designed for (ugh!)

Customer Feedback – in Traditional Agile
• Fails to find most learnability and usability issues
• Misses opportunity to inform future design
• Misses opportunity to gain better user insight through
observation

Bring Users into Agile
• UX brings the end-user into Agile and expands the
meaning of “Customer” to extend to the end-user

Getting Agile Teams to Care About Usability
Your Place at theTable

So Now What?
• If Agile doesn’t care about UX, why should my Agile team
care about what I do?

Getting Developers to Care
• UX Fail strategies:
• “I’m just going to keep doing my job the way I always have and
telling the team what they need to do.”
• “I’m just going to let them go ahead and fail. Then they’ll come
to me begging and let me do my job.”

Be Part of theTeam
• They’re not going to “stop the train” for you
• Make UX processes Agile
• Build trust by providing tangible proof of the value of
your work
• Attend daily standups/scrums

Get Ahead of theTrain
• Always design one iteration ahead, so you have designs
ready to go when they are needed
• Regular usability testing (iteration-aligned)
• Test whatever is ready that day
• Plus your look-ahead designs
• Plus user research for existing issues and potential future work
• Test designs before developers build them – saves
arguments

Welcome the Team to yourWorld
• Invite developers to observe tests of features they wrote
• Seeing someone struggle is strongly motivating to them
• Even more so for product managers
• Engage developers in helping you to figure out solutions
• Their knowledge of code and systems provides ability to come
up with innovative solutions
• Credit developers when features they wrote work well
(even if you designed it)

BringYourWorld toThem
• No time or inclination to watch your testing?
• Record the tests
• Bring key clips to the next meeting(s)
• Provide easy access to sessions (always consider ethics)
• Share information – information radiators
• Put it on the walls
• Use online tools
• Get it in the backlog

Fit into the Process
• Time your testing so that results are in when it will be
most useful to your team
• Track usability metrics on the team dashboard
• Ensure they are reported upwards
• Help prioritize usability problems to simplify backlog grooming
• Have preemptive cards added to the schedule for
“problems we will find while testing”

Participate in Retrospectives
• Encourage retrospectives if they aren’t happening
• Great learning experience for all
• Was what you provided the team enough/too much?
• What questions still open?
• Still confusing/frustrating?
• More effectively communicate user
needs in a just-in-time situation?
Image: http://intland.com/blog/project-management-en/tips-and-tricks-to-make-the-
most-of-your-retrospectives/

Let’s Get to Know Each Other
• Who has had agile training?
• Reading, no formal training
• Other team members trained
• No training
• Some training
• How long have you been doing Agile?

Who’s Here?
• Roles?
• UX practitioner, UX manager -- is this who we all are?
• Resources?
• Single UX resource on a single Agile team/project
• Single UX resource on 2+ Agile teams/projects
• Part of a UX team on a single Agile team/project
• Part of a UX team on 2+ Agile teams/projects

What’sYourTeam Like?
• Distributed/remote?
• Large/small?
• Who else is on the team?
• How long have you been together?

BalancingTeamWork
• Within UX team
• Research
• Wires/clickable prototypes
• Usability testing preparation
• Usability test facilitation
• UX Issue wrangling
• Visual design
• What else?
• Split team up on different items or attack together

Marketing, Sales and Business Analysts
• Have customer access
• Knowledge
• Business rules
• Usage patterns, what other tools customer has
• Can support
• Research (users/stakeholders)
• Wires
• Demos/Clickable prototypes

Developers and UX
• Trust is key
• FED (front end developers) and UI Developers
• Can provide
• Clickable prototypes
• Coded “prototypes”

product owner
=
product manager
+
dev lead
+
interaction designer

Scaling Agile at Spotify via Slideshare of Vlad Mysla
http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
Squads,Tribes, Chapters and Guilds

Break
30 Minutes (back at 11 am)

Parallel-TrackWorkflow
a.k.a. Staggered Sprints

Agile Design Timing: ParallelTracks
• Developer track: Focus is on production code
• Interaction designers track: Focus is on user contact

Iteration 1: DeveloperTrack
• Underlying architecture work
• Critical features with little user interface design required

Iteration 1: Interaction Designers
• Design, create prototypes, usability test (UTest),
and iterate (RITE method)
• Field studies to understand user needs (contextual inquiry)

Iteration 2: Developers
• Take the verified designs and start making them a reality

• UTest completed code for integration and
implementation issues

• UTest completed code for integration and implementation
issues
• Use data gathered in the last iteration to create designs for
next iteration

• UTest completed code for integration and implementation issues
• Use data gathered in the last iteration to create designs for next iteration
• Field studies for detailed information needed for upcoming iterations

And so on…
• Constant communication between the two tracks is
essential for success
• These are not just hand-offs

During Each Iteration
• Be Present
• Face to face with developers
• Are they building what you expect?

Look back
• Validate the work done in previous iteration

Look ahead
•Design for next iteration (n+1)
•Research for future iterations (n+2, n+3…)

CombineYour Investigations
Maximize your time with users
• Test completed code
• Test paper prototypes of upcoming design
• Elicit data for future design

Agile Roles and ParallelTracks
UXTakesTime
• Having multiple roles (e.g. UX + product owner, UX +
scrummaster) leads to overload
• Working on multiple teams is a bad idea

Kanban and Just-In-Time
• All work is a collaboration with engineering/development
• Share information on walls – information radiators
• Lean UX
• Less time to conduct research and think through problems
• Handled as a “spike” if needed
• Rely more on early research early and usability testing (learn as
you go)

Story Points and ParallelTracks
Should UX activities be estimated as part of team
velocity?
•A hotly debated topic
•Our positions:
• No. They should be tracked separately, in parallel
• Yes. Especially when part of active work.
•“Working software is the primary measure of progress”

Spikes - Parking Lots
• Used to get to a firm estimate (where applicable)
• Able to respond Go/No Go
• Parking lot – simpler problems to solve in a single
conversation
• Spike – not enough information
• Intense focus on issue with multiple resources
• While other work continues

Design Spikes
• Multiple resources (not just design)
• Must continue to support ongoing development

Incremental Implementation
Getting to complete workflows, one DONE at a time

• Iterative
• Incremental
• Continuous
• Collaborative
• Transparent
Agile Qualities

What if your story is too big?
• If work can’t be completed in one iteration
• Need to break it down
• Where are the break lines?
• How do you prioritize the feature cards?

Big Design - Waterfall
• One big design document contains everything
• Everyone signs off before Dev begins
• Dev builds it until they run out of time
• QA doesn’t test until Dev has run out of time
• Result:
• whatever they built first is completed
• details are left out, quality issues identified too late
• holes are left in the design
• Much of your design effort is wasted

Big Design - Agile
• Break the story into small pieces, where each piece
confers incremental value to the user.
• Story mapping (discussed later)
• Determine the minimum first step
• Schedule the pieces in order of importance
• Design incrementally, as if the each piece were the final
one
• Change your future plans between iterations if you have
learned new things

Via Spotify (original presentation not available). More at: http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-
4383-9673-9e715ff47a75&v=default&b=&from_search=14 and https://labs.spotify.com/

Benefits of being incremental
• When development runs out of time/resources, the
shipped solution
• Delivers maximum value
• Has a complete design without holes
• Has much higher quality
• Has no wasted design work

Mistakes to avoid
• Designing all the detail up front
• Not thinking about the full design up front
• Not breaking things down far enough
• Not delivering a complete (sub) story each iteration –
“now the user can…”

Example: Doorway
• User story: The user can get in and out of her house
easily.
• Completion Criteria:
- Secure
- Insulated
- Lets light in
- Allows large furniture items to pass
- Fits with house décor
- Works even without keys

Example: Doorway
• Initial Rough Design:
- Beautiful Colonial Door
- Unbreakable translucent window
- Programmable digital lock
- Steel deadbolt
- Metal-clad on the outside
- High R-Value

Example: Doorway
• What is the minimum work that will give the user
incremental value towards their goal?
• What needs to be designed for that?
• What is the next smallest item that will give the user an
added capability?
• What needs to be designed for that?

Activity: Early Story Selection
• Select the first 10 stories that should be done.
• How many do you have to complete before you would be
willing to try it with real customers?
• See handout

FittingThis toYour Process
• The purpose of incremental implementation is to get
feedback early and often.
• After each iteration, gather feedback.
• These questions can affect your breakdown:
• Who evaluates your product?
• Is it always the same people?
• Are your target users internal or external?

• You may get feedback from:
• Internal ‘expert users’
• Beta/Usability testers under NDA
• The general public (after release or open beta)
• Internal users in a protected ‘sandbox’
• Internal users after general deployment

• Before releasing, consider:
• Are you getting the feedback you need?
• Is there enough completed for an external user to
evaluate?
• Sometimes you may want to hold back certain work until
more is done.

Make it Easier for theTeam
• Write staged specifications -- a best guess at breaking the
design into 1-iteration Story increments
• “Break” the Stories with developers intoTasks.
Remember: they own the Tasks. But you need to know
how to map those back to Stories & Capabilities. (See
story mapping)

Ways to Break a Story Down
• Workflows
• Stories with many “mini-workflows”
• e.g., Channel changer
• Allowed inputs
• Story that applies across different data types
• e.g., Image file reader
• Capacity
• Completion criteria involve extreme size or speed
• e.g., File transfer of large files

Example: OrderingYour Sub-Stories
• Big Story: User can move, duplicate, or remove selected
text in a document.
© Copyright 2014 Desirée Sy & John Schrag.All rights reserved.

Example: Story Breakdown
text in a document.
• Note: there are many possible designs that achieve this
user capability

text in a document.
• The selected design is to provide 4 menu items with
hotkeys: Cut, Copy, Paste, and Delete.

• Written out as proper stories:
• The user can move selected text out of the document and into
an off-screen clipboard.
• The user can copy selected text into the off-screen clipboard.
• The user can replace selected text with the contents of the
off-screen clipboard.
• The user can delete selected text.

• Stories: Cut, Copy, Paste, Delete
• How engineering breaks it down:
• Sprint one: create memory buffer system
• Sprint two: add menu items, tooltips, etc
• Sprint three: Copy
• Spring four: Cut, Paste, Delete
• What is wrong with this?

• Stories: Cut, Copy, Paste, Delete
• How do you order these four stories?
• Which one comes first?Why?
• Which one comes second? Why?
• Which one comes third?Why?

Activity: Story Breakdown
• Chandra needs all the application functions available to
him in his native language or another language he
understands well.
• Which of these breakdowns is/are Agile? Why?
• What factors would determine which breakdown you
should choose?
• See handout

What if no breakdown is possible?
• You can have a story with one single capability that takes
more than a sprint to build.
• For example, a calculation with a difficult algorithm.
• This is an engineering problem, not a UX problem.
• If possible, see if the work-in-progress can be validated
using partial results.

Discussion
• What are your story breakdown problems?

Shared Documents Aren’t Shared Understanding
Cartoon by Luke Barrett © Jeff Patton, all rights reserved, www.AgileProductDesign.com

User Story Mapping
• Organizing user stories
into a map that
communicates experience
Book: User Story Mapping, Discover the whole
story, build the right product. By Jeff Patton (with
Peter Economy)

Visible Depiction of Available User Stories
• Frame questions such as
• What is needed?
• When is it needed?
• Where is there value?
• What is really important?

Depth and Breadth of Entire System
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
time
Below each activity, or large
story are the child stories that
make it up
Arrange spatially to tell bigger stories

Represents Complexity and Size of Work
time
Refine the map and test for
completeness with the entire
team - developers, designers,
BA’s etc.

Conversations to Understand
• Relationships between stories
• Structure and hierarchy of related stories
• Functionality that is being built
• Conversations to share knowledge and clarify
assumptions

Clarity ofWhat is to be Built
• Organizes stories
• Context of use for product
• Clear understanding of use makes prioritization easier
• Backlog completeness can be verified
• Can be overwhelming to see entire product
• Important to know information now rather than later

Enables Better Releases
• Select relevant, high priority stories in releases
• Valuable functionality
• Complete sets of functionality
• Plan, at a high level
• What would come next
• What is for “later”

Activity: Story Mapping
• What were all the things you did to get ready to be here
today?
• Starting from the moment you woke up until you arrived here
• Write one item per sticky note

Activity: Story Mapping
• In a small group (3 to 5) merge stickies into a single
model
• Arrange left to right in order that makes sense to group
• Eliminate duplicates
• Cluster items that seem similar and create labels for the
clusters if items that seem to go together

* from Cockburn’s Writing
Effective Use Cases
Story Detail – Level of Fidelity
Functional or “Sea level”
I’d reasonably expect to complete this in a single sitting
Sub-Functional or “Fish level”
Small tasks that by themselves don’t mean much. I’ll do several
of these before I reach a functional level goal
Activity or “Kite level”
Longer term goals often with no precise ending. I’ll perform
several functional tasks in the context of an activity
Too abstract
Too detailed
Think about user
experience at this
level
Be sensitive to your user task’s “altitude”

Discover as Much as Possible,
as Quickly as Possible
• Prototype early
• Learn from prototypes and iterate

Tell the Story
• Strive for “Caterpillar to Butterfly”
• Show progressions of key sections of the interactions
• Use more screenshots – less words
• Explain what changes were made and why
101

Capture the Evolution
• Helps avoid making same mistakes later
• Helpful to capture first, middle and end screenshots:
• primary pages
• primary features
• contentious issues
• Don’t sweat the small stuff
• Use final prototypes as a base for recommendations
(vs. written documentation and/or comps)
102

Provide Details as Appropriate
• Archive prototypes and other deliverables
• Regulatory environment or complex interactions
• Test plans and guides
• Detailed changes
• Participant information as needed, but avoid sharing with
wider team
103

Don’t Overwhelm Audience or You
• Document in Wiki or similar (avoid PPT)
• Just enough to understand the “why”
• Always challenging due to:
• Limited time
• Multiple changes over time
• Findings building upon one another
104

Agile UX Prioritization
Knowing what’s important

Timing for Prioritization
• When grooming the backlog
• During formative usability testing

Prioritizing Problems
• It’s better to fix the few most important issues than to
find every issue because:
• Big problems can mask other problems
• Every fix changes user behavior

High Value
Low Cost
High Value
High Cost
Low Value
Low Cost
Low Value
High Cost
UX/Product Management
determines “Value”

High Value
Low Cost
High Value
High Cost
Low Value
Low Cost
Low Value
High Cost
Development determines “Cost”

High Value
Low Cost
High Value
High Cost
Low Value
Low Cost
Low Value
High Cost
A B
C Seriously?

“If a user can’t find or use feature, it’s the same
as if the feature is broken.”
VS.
“It’s more important to fix things that really
don’t work. The user can learn the hard stuff.”
Prioritizing UX vs “real” bugs

Prioritizing UX vs “real” bugs
• You cannot win this argument on a case-by-case basis
• Instead, adopt a strategy for getting required
investment in UX work

Strategies for Getting Investment in UX
• Political strategy: Create a formal equivalence of UX
versus bug priorities.
• Investment strategy 1: Block out fixed time
• Investment strategy 2: Block out people
• End-run strategy: get your own engineer
• Fix UX problems early, if possible.

Detail Matters
• Users are usually more delighted by low-cost annoyance
fixes than by big flashy new features

Focus and Negotiation
• Keep an intense focus on fixing the most important things
• Negotiate on behalf of users
• Represent their needs as best you can

Research Balancing Act
 Understand users, context, etc.
 Create personas, mental models, etc.
 Prepare for story mapping
and other sessions thoroughly
Strive for
UX Best
Practices
 Engineers need designs
to develop - will move on without
UX involvement
 Research cannot continue
forever
Meet
Production
Needs
Agile requires leaner methods

How much is good enough?
• What is being developed?
• What do you know?
• What questions are still open?
• Meet goal when users starting to talk about colors
and icons (not functionality)

Light Design - Lean UX
• Familiar UX methods made lean:
• Iterative (flexible, change as needed)
• Repeatable (easy to do, expected next steps)
• Incremental (lead into next, small changes over time)

Tips for Lean
• UsabilityTesting
• Insert questions to find out more for open issues
• Schedule regular testing to reduce preparation time
• Reach users quickly for meaningful information
(panels, remote testing, surveys etc.)
• Incentives as needed
• Put all data together quickly – no big reports

Lean Reporting
• Put all data together quickly
• No big reports
• Information as needed
• Get it to the team – quickly (Evernote, Mural.ly,Trello,
Story/Bug tracker, etc.)
• Tell the story – pertinent information – who, why?
• Provide solutions (wireframes, etc.)

Activity: Make it Lean (45 minutes)

Activity: Determine User Expectations
• Early stages of a project - defining scope.
• Stakeholders:“Users will never sign a catering contract on their
phone!” Doesn’t need to work on the phone.
• UX team: Not likely to be their primary access choice, but will
be desired to be done on their phone.
• You have 2 days: Determine if common/critical use case
• Teams of 3 people
• Make a plan for what to do (10 minutes)
• Share your plan

Guidelines
• What do you need to know?
• What resources do you have?
• How much effort/time do you have?

Activity: Part 2
• Take roles and act them out
• Discuss ramifications of findings
• What's in and what's out?
• Make tradeoffs – conversations
• Vote within teams
• See handout

Sprint Zero for ScrumTeams
• Time to do initial research, setup usability testing, etc.
• When technical teams are setting up environments
• Back end that doesn’t hit front end
• Getting alignment on business goals –WHY??
• All bought in across board
• Do just enough work to get development started

Alternatives to Sprint Zero
• Can be in parallel sprints while other teams are wrapping
up previous work
• Do work in Sprint 1
• Planning, story mapping, etc. (or already done)
• Story creation (or not done yet, or will do later)
• Create initial wires and prototypes (or in Sprint 1)
• Goal is to have initial questions answered
– doesn't matter what you call it.

Pros and Cons - Sprint Zero
• Pros
• Gives UX a head start
• Lot of backend work needs to be done anyway
• Establish common vision
• Who for?
• Common “elevator statement”
• Cons
• Can be a trap leading to Waterfall
• Big Design Up Front (BDUF)
• Time box to avoid this

Requirements
• Change in presence of the artifact
• Questions change as you learn more
• Pointless to do ALL requirements gathering up front
• Works better iteratively – unless have it in hands of those
that will use it
• Don't know what we don't know

Make it Quick!
• Proxies as needed
• Quick enough analysis
• Get to 80% confidence
• Continued learning with additional contacts
• Usability testing
• Customer visits (enterprise software)

Setting Expectations
• Developers
• Only get a little bit of information at a time
• Need to fit work in
• May need to rework as we learn
• Repeat it as we go

Arguments About UX
• Not done (what is “done?”)
• Indecisive (make up your mind!)
• Never right (“more feedback already?”)

Eric Ries @ericries via @MelBugai on Twitter at
LeanStartupMI in 2011
"The biggest waste of all
is building something
no one wants“
- Eric Ries @ericries

UX Made “Agile”
• Any UX method can be adapted
• Don’t have to give up our favorite methods
• Don’t have to learn new ones
• Doesn’t take much effort to adapt our methods to fit the Agile
process
• Think about “lean” and “iterative” methods
• RITE is a good place to start

RITE Overview
• Qualitative user feedback
• actions + comments
• Series of small usability tests
• 3 participants each day
• Minimum of 3 days of testing
• Iteration between testing days
• Total of 5 days

RITE Process
Test Update Test
1
2
3
High
Medium
Low
Priority
& Level of Effort

WhatWorks for RITE
• Best used early in project lifecycle
• Early concepts
• Need to be vetted with users
• Can assist in quickly shaping designs
• Doesn’t this sound “agile”?
139

Evaluation + Testing
• Think evaluation → testing throughout the product
development lifecycle
• Start with design evaluations and move onto testing the
deliverables for each Sprint/Iteration
• Start with the big questions and narrow down quickly
(what would be the top 3 things to fix/improve? would
you use it? Would it be a “wow”? which of 3 approaches
do you prefer?)

Number of Participants
• Think fast and iterative
• For example ~5 participants for each, and iterate if needed
• Key is to get the needed feedback, iterate, and move on
• Do you really need 10 participants to tell you it’s something
they would never use?
• Know when enough is enough
• If 3 participants so far have “failed”, do you need to test the
other 2?
• Note: personas can be agile too: top 1, confirm, test

Testing Cycles
• Set a schedule and expectations with the team early
• User testing days (e.g., every Friday, we’ll have 3 hours set
aside for testing)
• Schedule set to Sprints/Iterations (e.g., at end of every
Sprint, schedule a round of testing to cover what has
been completed)
• Also consider combining sessions for multiple goals (e.g.,
test what was done last Sprint, get early feedback on
what you are working on now)

Testing Materials
• Use the lowest fidelity method possible to get the needed
information (the time spent in developing the materials is
time you won’t have for iterating and testing)
• Use sketches and wireframes to work on basic concepts
and keep attention focused away from details
• Use higher fidelity when you are testing the details and
interactions

Test Only Until “Done”
• Stop testing when you know enough to move forward
• Test for the big stuff first: when you start hearing about
icons and colors, not function or layout, you know it’s
“enough”

Light Reporting
• Don’t write a report
• Focus on most important changes
• Record change decisions and reasons why (for future
reference, and for onboarding new designers)
• Explain changes to the team face-to-face
• Tell the story

Discussion
• Additional topics
• Bringing work in – how do you select the right thing(s)?
• Backlog grooming and where UX fits in
• Types of prototypes
• Other frameworks for Agile
• Working with PM’s, and leadership
• What are your experiences?

• Adapting Usability Investigations for Agile User-
Centered Design by Desirée Sy
• Journal of Usability Studies,Volume 2, Issue 3 (the
most-cited paper in JUS)
• http://www.uxpajournal.org/

Principles behind the Agile Manifesto
• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Face-to-face conversation is the best form of communication (co-location)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done—is essential
• Self-organizing teams
• Regular adaptation to changing circumstance
http://www.agilemanifesto.org/principles.html

Pre-Conference Course: UX and Agile: Making a Great Experience -

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Pre-Conference Course: UX and Agile: Making a Great Experience -

Similaire à Pre-Conference Course: UX and Agile: Making a Great Experience - (20)

Plus de UXPA International

Plus de UXPA International (20)

Dernier

Dernier (20)

Pre-Conference Course: UX and Agile: Making a Great Experience -