Abstract
Winds of change are blowing across software development. Discuss how agile methods,
XP, or even web development cycles are impacting your user-centered design efforts
and what we need to do to adapt. Some methods will work better than others --
what are the best practices we can use?
Duration
One day
Participant selection criteria
Participants will be selected based on the quality of submitted position papers.
Position papers should describe one or more case studies or experiences using
UCD in an agile/XP environment or in an “agile design process” such
as fast turn-around web development projects. While we are interested in your
thoughts to all of the following questions, for the position paper please select
the 4-6 most important to you.
- What agile/XP project(s) have you been involved in?
- Describe your experience adapting UCD methods to fit the development
team’s process.
- What UCD tools or methods did you use?
- What UCD processes were the easiest to adapt? The hardest? Why?
- What modifications to the UCD tools or methods did you make?
- How do you determine when it is too much adapting/compromise, that
is, the situation would not allow you to do the minimum quality acceptable of
UCD work? What were those tradeoffs?
- What were the reactions from development?
- What are the advantages to the UCD practitioner of agile/XP software
development? What are the disadvantages?
- What will you do differently the next time?
- What are your desired outcomes of this workshop? What do you expect
to learn?
Desired number of participants
This workshop will accomodate up to 15 participants.
Workshop description and Facilitators’ Position
Agile methods and Extreme Programming (XP) represent a radical shift in software
development. But even before that, the shift from more traditional platforms
to the Web has shrunk development cycles drastically, leaving us less time for
user-centered design (UCD). The challenge to UCD is to adapt and create tools
to complement these styles or risk losing a place at the table – we need
to get agile in our design. A major problem even with traditional software development
and UCD was the perception that development was held up until all of the front
end work was completed and this front end work contained a lot of UCD activities.
As a result, UCD is sometimes thought of as being “too costly” for
development – after all, they have a schedule they have to meet.
Do we have to abandon our proven methods to successfully integrate with these
new development styles? NO! Instead our work is even more critical. A hallmark
of these approaches is to get something in front of the customer as quick as
possible, get responses, and then build the next increment. One way of looking
at is to think of painting a picture starting from one corner and gradually
working your way across the canvas. Traditional software development differs
in that the entire picture is done in stages: discovery, design, development,
and deployment. In each stage work on the entire product is completed before
the next one starts. In contrast the other styles create minimal documentation
and then generally just in time for the current development iteration. There
may be at most a general idea of the end goal.
How do we, UCD, mesh into this new world? First, we need to support establishing
a long-range target for the product – e.g., what do we want it to do for
whom in what environment by Release 2 (not iteration 2). Second, we need to
make use of the wealth of data already at hand. Yes, it may not be the closest
match or the most rigorously gathered, but by leveraging the short development
cycle we can get an increment of design in front of customers and evaluated
before too much time has elapsed. Third, we need to take advantage of this emphasis
on getting things to the customer fast to further refine our information and
help direct the design. (See below under “Facilitators'
Position Paper” for the position/method the facilitators will bring
to the workshop as their contribution to the mix.).
In this workshop, we hope to learn from others what
experiences they’ve had, what worked, and what
didn’t. We’d like to start to develop an
“Agile UCD” processes guide and map and
to start to build a UCD process trade-off matrix relating
to the “Agile Programming” world.
Applying to Participate in This Workshop
A workshop is a closed session. Admission to a workshop
requires an approved position paper from you addressing
the issues suggested by the coordinator(s). Please send
your position paper (which should be roughly 1 to 3
pages) to Gary Macomber, macomber@sbcglobal.net.
Position papers received by April 25 will be accepted
or rejected by April 30, in time for you to register
before the early registration deadline on May 2. Position
papers received by May 24 will be accepted or rejected
by May 29, in time for the May 31 registration discount.
Papers received after May 24 will be evaluated at the
facilitator's discretion.
Pre-workshop participant activities
Participants are asked to submit a position paper (see Facilitators'
Position Paper for an example)of 2-3 pages as described
above under “Participant Selection Criteria”.
We will summarize the position papers and send the summary
to all participants prior to the workshop. Participants
are encouraged to bring samples or case studies, and to
also be prepared with questions and issues they wish to
explore.
Pre-workshop facilitator activities
The workshop facilitators will review all submitted position papers and select
up to 15 participants who provide a variety of experiences that they can draw
upon in the workshop. They will notify participants of their selection. The
facilitators will summarize the position papers and distribute the summary with
the position papers to the participants. Prior to the workshop, the facilitators
will prepare a list of questions and discussion topics for use in the workshop,
and will prepare example situations and topics to be used in the small group
discussions.
Workshop session timeline
The workshop will be divided into two main activities: collecting ideas/brainstorming
ideas for best practices based on experiences and collecting/synthesizing those
ideas into the best practices for “agile UCD”.
Time Activity
8:30 – 9:00 Introductions, sharing expectations, introducing format and
logistics
9:00 – 10:00 Short presentations of key issues by participants.
10:00 – 10:30 Break
10:30 – 12:00 Breakout session # 1
Small group brainstorming based on key issues/themes
identified.
12:00 – 1:30 Lunch
1:30 – 3:00 Breakout session # 2.
Small group work on best practices for agile UCD methods.
3:00 – 3:30 Break
3:30 – 4:30 Group discussion on key findings. Summarization of findings.
4:30 – 5:00 Final discussion and wrap up
What is the key issue yet to explore?
What is the group desire for follow-up and via what mechanisms?
5.00 Adjourn
Presentation of results during the conference
The workshop facilitators will present the key results of this workshop as a
poster session during the UPA conference. Participation by any of the workshop
participants is also welcome.
Post-conference dissemination of results
The workshop facilitators will produce a report from the workshop for publication
in either the Voice or in User Experience.
Post-conference activities
Post-conference activities will be determined at the end of the workshop by
decision of the workshop participants. One example might be an ongoing discussion
group to further explore issues raised during the workshop.
Facilitators’ Position Paper: Adapting to a Mixed
Model Development Environment
One of the toughest challenges is providing UCD services to a development team
that is using a method that allows minimal time for upfront work. Examples of
this are Extreme Programming (XP), Agile Design, Rapid Application Development
(RAD), and being brought into a project that is already underway. The common thread
across these methods and many others are short iteration cycles and shortened
front-end time. This shortening of front-end time directly impacts many user-centered
design (UCD) methods.
Often a team wants to jump right into coding as soon as the project gets assigned,
without gathering or using detailed user information. But by not first understanding
the problem space, the design may miss critical factors. It is hard to imagine
development teams not using user, task, and environment information, but we
all have our stories of projects gone south or failed products. Stories give
an agreed-upon and well-understood footing upon which to continue to build and
evolve the design solution.
Stories are also easily adapted to agile design. By using existing data or
expert opinion a preliminary story can be developed quickly and then reviewed
with users. By integrating the story validation into the iteration user evaluations
you can progressively validate and improve the user information.
Now let’s take a brief look at how we might modify a UCD method to work
in this fast-paced world. For this example we chose to look at Story-Based Design
and how to modify it to fit “Agile Design”. We also chose the “11th
hour request” as the development method context. Successful modification
relies on matching the modified method to the development strategy.
If you’ve been a usability person for awhile, there’s a pretty
good chance that you’ve had someone come up to you after all of the development
is done or nearly done and ask you to approve or assure the usability of their
product. Actually, you can turn this into a good example of agile UCD and set
yourself up for earlier and more inclusive involvement the next time around
by following a few simple steps.
Step 1. It is important to set the stage and expectations
properly. You probably don’t have the time, budget, or support to do what
you really should, and it is long past the point where they should have come
to you for this release. These are the constraints you will work under. We recommend
turning someone away only when you can’t come to mutual agreement on the
expectations. Otherwise, look at it as an opportunity to establish a relationship
and start building for the next iteration. The things you can do for them fall
into two categories:
1. Critical and/or easy fix items in the current release/iteration
2. Initial background, requirements, and vision for the next release.
To accomplish the second thing, you need to understand who the user is, what
they are trying to accomplish, and what is the environment they are working
in. In short, you need to have the story.
Step 2. Build a story sketch and fill in critical pieces.
So how do you build an adequate story with no time and no resources? Easy, set
your expectations at having a first draft story that you’ll validate as
you do your analysis. This means gathering information from wherever you can
get it immediately. The existence of a group of customers who have agreed to
help you with designs makes the job easier. Use them, Marketing, Sales, and
the developers as sources of information. Quickly sketch together a story that
will allow you to prioritize the tasks. This will help you chose what to test
and what not to in this limited time scenario. Taking the story sketch and the
test tasks you can start to flesh out the story as it relates to those tasks.
So the story has some sketchy areas and some filled out ones. After you finish
setting up your test materials and line up participants, you are ready for Step
3.
Step 3. During the usability testing spend some time with
the participants validating and refining the story. This means using a variety
of methods with the participants. Start out by reviewing the story sketch and
ask them about the task frequencies and how critical those tasks are in their
environment. Then, during the testing, ask about the steps they use in performing
the tasks and about the relationships between tasks. Don’t forget to ask
them to review the user descriptions you’ve written.
Step 4. Take all of the information gathered and update the
story, adding and changing as necessary. This will provide you with the overall
context for your recommendations and the baseline story for the next iteration.
Now, what are some of the general results we’ve seen from our efforts?
An example of a mixed model development environment recently provided an opportunity
for one of us to use stories as a way to blend the two processes together. This
was a project involving two different development teams – one using XP
and the other using traditional software development. The development team using
XP had already had a bad experience with UCD and had decided to do it without
much UCD involvement.
This was a good chance to show what could be done quickly using user profiles,
task analysis, stories, and low-fi prototyping. Adapting the methods wasn’t
too difficult, though some things were sketched in first and validated/revised
later after user data could be gathered. More problematic was explaining to
development what was the result of adapting to the programming environment –
doing several of the methods at once and still keeping up with the iteration
cycle. Traditional task analysis was probably the hardest to adapt because it
is the most rigid in what has to be done.
Modifications to the methods were mainly in their timing. Instead of being
able to gather the information up front, I had to discover what information
was already available and what questions it was pointed at as well as other
characteristics. Then I had to determine what UCD results the development teams
were expecting and what their schedules were. From that I was able to derive
preliminary user descriptions and stories, as well as the UCD plan.
So, when does the amount of adaptation required not allow for minimum quality
UCD work? This is a difficult question. Walking away from the table is hard
and may negatively impact development coming back next time. The same can be
said about demanding that a rigid process be followed. Several of the developers
pointed to the UCD roadmap mounted on the wall and asked how we could possibly
follow all of those steps and still deliver a product on schedule. It gave me
an opportunity to do a little on the spot (short) discussion of how UCD can
be modified to fit XP. Another way of dealing with this is to describe the impact/risk
of the different options for gathering/reporting UCD information.
Reactions from development were mixed. There was initial skepticism, then gradual
acceptance. They were skeptical about getting information they could use in
a timely manner. They expected pushback on the schedule. By presenting them
with a plan and risk analysis of not doing some of the activities, they were
included in the decisions and therefore more receptive.
Development wasn’t the only stakeholder. Product management also was
a big player. A lesson learned was that you have to consider and include all
of the players. Understanding and factoring in the expectations and goals of
the different groups adds another level of complexity to adapting to “agile
programming”.
Looking back at this project, one of the things that I could have done better
is to get a better grip on the politics and goals/expectations of the different
shareholders earlier in the process. Also needed was an increase in the clarity
of communication -- early in the process I was not as clear in voicing my perceptions
of the trade-offs.
In summary, it is our belief that the most obvious advantage to the UCD practitioner
of agile design is the frequent contact with users. A close second is the ability
to test small increments and repetitively test the product as it goes through
the development process. We also believe that stories are compatible with many
design processes, and can be used successfully in very “agile” processes.
|
