Agile & UX
I'm a user experience specialist that came into a company already using
agile practices. When I first got there I tried to jump straight into the
sprints with interaction designs. This resulted in a lot of confusion,
unnecessary changes, and a less than ideal user interface.
We took a step back on a recent project and held a relatively long "sprint
0" - I spent 2 months conducting user research, defining the major design
problems and solutions, defining UX/branding vision and strategy, and
developing the basic design architecture (navigation and interaction style)
with the help of paper prototype testing. The graphic designer also took
this time to develop a set of icons and visual style for the new system. We
now work one sprint ahead to define the detailed screenshots, acceptance
criteria, and conduct user visits to get feedback on features. I also work
as the product owner defining the stories on the backlog.
Although I am a very strong proponent of agile methods, I am still not
entirely sure how we could have reconciled the large amount of UX work that
we did upfront with the agile rule of thumb that suggests only spending 2
weeks on Sprint 0. Perhaps it is because I am working alone - a team of 3-4
designers could probably work much faster and also be able to handle much
more design work during the sprints. A shorter sprint 0 might also have been
doable in a company with an established UX infrastructure (e.g. a style
guide/UI standards and a good understanding of user needs), but we didn't
have this and had to start from scratch.
I think it is important to attend the sprint planning meetings and work
within the sprints with the development teams. Jeff Patton talks about the
difference between incremental development and iterative development. I'm
not sure if I can explain it perfectly, but basically incremental
development is how you described in your email Jessica, where you have a big
picture of the UI and you break it down into small pieces and feed it to
development. Iterative development, on the other hand, would involve
developing the system in small parts and reevaluating the design at each
step. Iterative development as used in agile methods gives more room for
flexibiliy and to take advantage of oppurtunities. For example, if it comes
out in a sprint planning meeting that a feature that you have designed would
take 4 weeks development time, you might work together with development to
understand the technical problems and redefine the feature so that it only
takes 1 or 2 weeks development time. Incremental design does not work in
this case, because changing the nature of this feature might also mean you
have to adapt other parts of the interface to maintain consistency or to
take into account the technical constraints that you just became aware of.
Agile methods aim to create the most business value in the least amount of
time. I find that this means that I sometimes have to be flexible in my
ideals regarding the perfect UX design, just as the developers have to be
flexible on their ideas of what would be the fastest system to develop. We
do spend a good amount of time defining "in-between" steps where the
developers will not be able to create the complete feature (as designed) in
this sprint, but only a part of it.
It would be great to hear the experiences of others on this list in
resolving design and agile methods.
- Liz
--
Elizabeth Whitworth
User experience specialist
TRANSPOREON GmbH
Ulm, Germany
On Tue, Nov 4, 2008 at 6:26 AM, Kim Mc <kimmc_68 at yahoo.com> wrote:
> My experience is that you as a UX person need to be involved in the product
> definition or 'backlog' throughout the entire development process and not
> just the beginning definition phase. Sometimes you will need to be more of
> a product manager than a UX person, and be willing to limit or streamline
> the amount of documentation you end up doing (not necessarily a bad thing).
> Just In Time Design is an Agile mantra.... Be flexible and work directly
> with developers as a team, not just delivering specs and wireframes then
> moving on.
>
> It is important, however, to have a good strategic vision to build from,
> which can often be the most challenging part to fit into an agile process.
> There is the concept of "sprint 0" - that this is the intial sprint where
> you work out all of the high-level strategy and IA structure then create
> your backlog from there. I personally like to have specific UX deliverables
> or demos in each sprint so that UX and possibly design stay 1 sprint ahead
> of the development team. The demo for the UX team is wireframes or a
> clickable prototype that is presented to the group.
>
> Jeff Patton has some interesting ideas and tips about UX and agile
> http://agileproductdesign.com/blog/
>
> Hope this is helpful.
>
> Kim
>
>
>
> ----- Original Message ----
> From: Jessica Petersen <JPetersen at omniture.com>
> To: discuss at ixda.org
> Sent: Monday, November 3, 2008 4:50:45 PM
> Subject: [IxDA Discuss] Agile & UXD
>
> What are your experiences in an agile environment? What has worked for
> you and what hasn't?
>
>
>
> My organization is considering employing agile, and I tend to be of the
> opinion that UXD needs to be at the forefront of the process thinking
> about things holistically - then breaking the project into chunks that
> will eventually result in a complete user experience. However, I have
> received quite a bit of push back in this regard and have found it
> difficult to find other experiences which support my thoughts.
>
>
>
>
>
> Thanks,
>
>
>
>
>
>
>
>
> Jessica Petersen
> Senior UX Designer
> jpetersen at omniture.com <mailto:jpetersen at omniture.com>
> 801.722.7000 x 1483 tel
> 801.722.7001 fax
>
>
> 550 East Timpanogos Circle
> Orem, UT 84097
> www.omniture.com <http://www.omniture.com>
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
Get the feed
Comments
My experience is very similar to Elizabeth's, except we spent about 8
weeks on "sprint 0" when we built the groundwork for our core
product.
I came at my current company from a waterfall-driven environment,
I'm the only designer, and found the same hurdles in the beginning.
I spent 2-3 weeks prior defining prototypes, wireframes, and mockups
before diving into stylework, which helped tremendously.
Also, as Elizabeth stated, we do iterative work, which means I keep a
big-picture concept in my head, we build features one step at a time,
and I am constantly evolving various parts of the interface toward
that big picture (which also changes every few weeks as we discover
new capabilities and limitations from our work).
It's been one of the most rewarding teams I've worked on, as a
designer (heck, as a developer). Our rule is that our development
team doesn't do any UI work, and I promise not to do any controller
or model work. They get the functionality working, throw it on a
page, and I take it from there. They love that arrangement, and I
have more than enough to do without getting into the nuts and bolts.
Our particular variety of agile is a variant of Extreme Programming,
with one-week "sprints", 3x5 cards for each simple feature, and
stories and specs written before any programming is done. We deploy
weekly but are capable of (and hoping to) move to a daily deployment
schedule - after I get over the willies considering what that
actually means.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35254
>
> My experience is very similar to Elizabeth's, except we spent about 8
> weeks on "sprint 0" when we built the groundwork for our core
> product.
Much has been said on this list about Agile and UX already, so I won't get
into it. I just wanted to say one thing:
You two are incredibly lucky. I never came even close to getting an 8-week
Sprint 0 in Agile environments. I was lucky if I had 3 days advance notice
that I'd be starting work with a dev team on a new app, and even luckier if
that team hadn't already started back-end development based on shaky
assumptions.
-r-
Good point, Robert...
Full disclosure: The '8 week sprint' was the beginning of the
project, my second 8 weeks with the company, and my development
team's first 8 weeks. That is, they brought the agile methodology
in and I did my best to keep up with them as much as humanly possible
the entire time, often designing behaviors and prototypes minutes
before they were to begin working on them.
My last environment was very similar to yours, but it wasn't agile,
and I frequently had about negative 6.5 days to deliver 20 pages of
biz requirements, mockups, graphics and javascript to a team buried
in their waterfall model.
Both were stressful, but since we left the original ramp-up behind, I
try to stay about 2 weeks ahead of the development team, which
doesn't always work out.
-- Bryan
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35254
On 4 Nov 2008, at 21:24, Robert Hoekman Jr wrote:
>> My experience is very similar to Elizabeth's, except we spent about 8
>> weeks on "sprint 0" when we built the groundwork for our core
>> product.
>
> Much has been said on this list about Agile and UX already, so I
> won't get
> into it. I just wanted to say one thing:
>
> You two are incredibly lucky. I never came even close to getting an
> 8-week
> Sprint 0 in Agile environments. I was lucky if I had 3 days advance
> notice
> that I'd be starting work with a dev team on a new app, and even
> luckier if
> that team hadn't already started back-end development based on shaky
> assumptions.
Or possibly you've been unlucky?
(at least I've been fortunate enough to have agile/ux experiences much
more like Elizabeth's)
Adrian
On 4 Nov 2008, at 20:58, Elizabeth Whitworth wrote:
[snip]
> It would be great to hear the experiences of others on this list in
> resolving design and agile methods.
[snip]
The biggest change I've noticed in my own behaviour was a move away
from producing "documentation" in the form of hi-fi wireframes,
prototypes, etc. - instead spending much more time in conversation
with individuals/groups, producing lo-fi prototypes, and explaining
the "whys" behind decisions face to face with the team.
Much more of a UX educational/evangelist role than I was previously
used to.
I think somebody already mentioned Jeff Patton's article on emerging
best practices - most of which agree with my experiences:
http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
The main difference in my personal experiences is I find as much need
for UX input on the developer side of agile teams as on the customer /
product owner side. For me I find it more of a bridging role.
The abstractions we create in the design need to run through into the
code that's built. This is especially important in agile teams when
the design->implementation cycle is so short it can go quickly off the
rails if folk aren't keeping an eye on those issues. Having more UX
experience on the dev side helps a hack of a lot here - hence me
spending more time doing educational/evangelism.
Possibly that's just my personal experience speaking since I've got
got a pretty heavy development background myself - but I've seen
problems when the UX folk have just kept on the customer side.
Cheers,
Adrian
So the methodology (I actually mentioned it on a previous post on this list) we use within Adobe Consulting, is all about harmonizing the perceived tensions that exist between user-centered design and agile methods (we use SCRUM/XP) so that "build the right thing" and "build things right", so that design-thinking leads and technology and platforms follow.
Our "3D" (Discover, Define, Deliver) approach can be summarized as:
Discover - "build the right thing"
Huge focus in discovery on UCD exercises, ethnography, user interviews, experience audits, and all manner of UX insights being gathered. This is in addition to insight gathering around business goals (success criteria, stakeholder identification, ROI objectives, business context, etc) and technology landscape. There's nothing "Agile" happening yet; we're setting ourselves up for future agile delivery success.
Define - "build the right thing and build things right"
In define, we'll undertake the planning activities of agile - writing user-stories (using personas from discovery as the actors for user-stories is helpful) and estimation of user-stories. However, during define we will do the big-thinking about the UX; we'll focus on information architecture for the overall application, we'll create wireframes and visual language and visual design, we'll create our choreography specs (for Rich Internet Applications, we design with time and motion also; there's a z-axis as well as an x- and y-axis to think about). What we find is that "design informs requirements, and requirements inform design", so it's critical that before we complete story writing, we're doing the innovative big-thinking, informed by our "Discover insights" around UX and business goals, and creating and advocating the user-experience. That will in turn inform our requirements gathering process.
Agile often advocates "epics, themes and stories", and we find that design work can often be undertaken at the theme-level; the UX team have broad-requirements understanding and deep user-insight, to be able to propose innovative user-experiences without yet being at the story level of detail (ie the username will be an email address and password will be between 6 and 8 characters; that's perhaps a technical/business requirement, but it's more detail than necessarily needed for innovative design). It's only as we move into iterations/sprints that we need to really lock on the pixel-level detail in the UX.
So we close out define with all of our stories for a release, with high-level IA and UX for the entire release, and with more detailed user-experience for the initial iterations/sprints of development, at the high-fidelity pixel-level design and with the choreography and motion design nailed (indeed pixel-level comps and choreography deeply impact the estimates/points assigned to a story during iteration and release or sprint planning/backlog prioritization).
Deliver - "build things right"
Deliver is agile development. Stories are planned into 2-3 week iterations/sprints. A story is not available for development unless:
* It is estimated
* User-experience design at pixel- and choreography-level is in place for the story
* Customer/Acceptance tests are in place for the story
An anti-pattern that we've found, is that if UX is being undertaken in parallel to development, our velocity tails off (our ability to realize business value over time) dramatically. That's why it's so critical that the UX team are ahead of the development team by several iterations; and the more UX work that can be undertaken during define, during elaboration of stories, the more likely we are to sustain implementation pace (velocity) because estimates include the complexity of implementing the UX.
I also find "Sprint 0" or "Iteration 0" to be an anti-pattern; the aim of an iteration or sprint is to allow a customer to prioritise features according to business value, and to measure the pace (velocity, burn down) that we deliver that business value at, as a measure for the future pace of how we'll continue to deliver business value. If we undertake a Sprint 0 where the activities are not software delivery activities (ie doing UX work, or doing installation of software/environment/etc) then we're not measuring anything of worth, with which to project our velocity for future iterations. It's a pedantic point, but if we're sprinting, then we should be able to measure our speed over a distance as a gauge of how much further we might run over the same time.
I think for this list, the experience I'd most share is that in our methodology described above:
Discover is where the magic happens; that's where we are unlikely to unlock and discover the insights that will lead to the "soul" or the "spark" of the user-experience.
Define is where the most effective products are designed; but if and only if we have a highly-collaborative technology and user-experience team, where we don't have a "design" process and an "engineering" process, but instead have a collaborative process where we are collectively responsible for delivering unambiguous requirements, estimated relatively according to the implementation complexity, with a corresponding user-experience design at the pixel- and motion-level.
Design and development, UX and Agile, is a handshake not a handover.
Steven
Steven Webster
Director of Technology and User Experience
Adobe Consulting
m: +44 7917 428 947
Registered Office: 151 St Vincent Street, Glasgow G2 5NJ. Company No. SC101089
-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Robert Hoekman Jr
Sent: Tuesday, November 04, 2008 9:24 PM
To: Bryan Minihan
Cc: discuss at ixda.org
Subject: Re: [IxDA Discuss] Agile & UX
>
> My experience is very similar to Elizabeth's, except we spent about 8
> weeks on "sprint 0" when we built the groundwork for our core
> product.
hey jessica
i work for an organization that recently moved from RUP to Agile, it
can be a really exciting transition.
before you decide on where you fall on this fence i would soak up all
you can about the ideal agile team and then look at your organization
itself and identify/forecast pain points: see where you are set up
for success and where you could fail. depending on how your teams
work currently you might want to start out with this elusive 8 week
sprint 0 (i just got a whiff of big design upfront) or you might just
dive deep into a UX *1 sprint ahead* model (bring your helmet for this
ride it might be more like just-in-bloody-time the first go round).
i would specifically look at the following:
communication style: do you talk everyday with your sponsors and team
members? can you call someone up and ask questions quickly? are you
co-located or dispersed? will you be sitting side by side or in your
own walled cubes?
documentation preferences/style: can you give general instruction or
do you devs need pixel perfect documentation with step by step
annotations? is documentation used mainly as CYA or is it biblical?
can you hand over a quick and dirty sketch to your dev, talk through
it and walk?
staffing: how is your team staffed and/or rotated? are you on
multiple projects at any given time? will you have a stable team or
are team members rotated off frequently?
political landscape: lastly your role (and your team members roles)
will change, as Kim and others suggest. you will become not just the
UX person but as product owner you will "manage" development to a
large degree - through prioritization etc. you would be wise to
consider how this redistribution rubs people, who's on the give and
who's on the get? who's feathers do you need to tend to and how to
reframe your relationship when them and the team so that they work
with you and not against you.
lastly try to bring in a coach who understands UX and Agile, the ROI
will be expotential to the cost.
my two.. fb
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35254
Hiya,
Folks interested in this topic might like to read Lane Halley's
recent journal post at http://tinyurl.com/5t6m4y. She makes some
really coherent points there, IMHO!
Also, I thought that Alan Cooper's keynote presented at the Agile
2008 conference was pretty ground-breaking. And it may well carry the
weight of authority that Jessica (& others) are looking for. See
http://www.cooper.com/journal/agile2008/
Cheers,
Liz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=35254
Thanks all for the input, and Adrian and Liz for the links.
I have been reading through some (not yet all) of the agile threads on this
list, and a number of people seem to be saying 'yes we do start just one
sprint ahead of development, but it is usually very painful'...especially if
there is no pre-existing style guide or ux infrastructure set up.
This is what I'm struggling with. A lot of agilists talk about big design up
front as if it is anathema to successful product development. But what about
spending time doing user research up front? Is time spent on user research
bduf or is it an essential clarification of the problem before design
starts? I get the feeling that existing agile methods rely heavily on
supporting structures in an organization - for example, on good up front
strategy and leg-work done by a product manager before a project starts.
Jeff Patton states in his article (
http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html) "if
you're a user experience professional, you will need to adapt your current
practice to work within an Agile value system and lifecycle." I agree with
this statement but I'm not sure this should be a one-way street. If there is
a UX team or person working in the group, then the team should evaluate
their process and work in a way that is optimally efficient, not just ask
the uxers to adapt to fit into agile processes (which were 'created by
developers for developers').
In my example, my company has a number of factors working against a quick up
front design. 1. we are working on complex logistics software with a huge
range of uers/usage patterns, and 2. I am a relatively junior ux designer
and the only ux practitioner in the company, and 3. we have no product
manager or business analyst working on the product. In our case, starting
design just a 2 week sprint before development was a disaster, and I'm happy
that my boss realized that it would to step backwards and spend the time on
research and strategic/conceptual design. It also helped that our devs had a
lot of complex technical stories to work on while the designwork was going
forward; so there was actually no delay in starting with development, but
instead a delay in starting the development of the UI.
Sooo...I guess the what I'm trying to say in my rather long-winded mail is
that I appreciate that my company took a more flexible appraoch to agile
methods to accomodate our particular circumstances. I feel that blind
adherence to agile practices and rules such as "Sprint 0 should be no longer
than a regular sprint" can nullify a lot of the value that good ux work can
bring, as well as place undue stress of the ux practitioner/team. Up front
UX work is aimed at reducing the risk of developing the wrong product -
exactly the same reason why agile methods suggest that teams avoid bduf and
start development asap. I think that both tactics are methods that can be
used to optimize development and bring value in a project. Our director of
IT, for example, was really impressed with paper prototyping efforts done
during our 8 week design phase, and noted that we saved a lot of development
time doing these design activities up front.
Feel free to argue - perhaps I am just going through the agile denial phase
that Jeff talks about in his article ;-).
Cheers,
- liz
--
Elizabeth Whitworth
User experience specialist
TRANSPOREON GmbH
Ulm, Germany
There should be NO 8-week sprint 0! - The first sprint really is no
different to all the other sprints. It should follow the same rules as of
the other sprints as well. If anything it should be SHORTER (shorter sprint
is good to form teams, team goals and rules, finding impediments, and doing
that faster).
But wait, I think there is confusion here. The project don't have to and
probably should not start out with the developers crunching code. You still
have to create the backlog, you still have to develop a vision of what you
actually want to achieve with the system. You still have to understand the
user, find out about the goals and the environment.
If it sounds like interaction design work, it's because it is. But what
about doing that work in sprints, starting out with a backlog of what has to
be done in interaction design, business analysis, work process. Planning and
performing studies in sprints, decide what gives most business value before
each sprint planning. When the developer backlog starts to form, bring in a
few developer that helps out with some concepts - you will start to learn
from each other what is technically possible and what you are trying archive
.
As the backlog items will get more stories focused on what should really go
into the final product, get some more developer and start churning out the
final application. But this does not have to be sprint 0 or 1 this might
very well be sprint 4 or 5.
I really think there are two sides to interaction design, the analysis work
for the backlog and the detailed interaction work with the team. And also, I
think the interaction designer will still be the link between the user and
the developer, helping out in the communication.
---
Håkan Reis
Dotway AB
+46(768)510033
My blog || http://blog.reis.se
My company || http://dotway.se
Our conference || http://oredev.org - See you in 2009
On Sun, Nov 9, 2008 at 21:34, Elizabeth Whitworth <
elizabethwhitworth at gmail.com> wrote:
> Thanks all for the input, and Adrian and Liz for the links.
>
> I have been reading through some (not yet all) of the agile threads on this
> list, and a number of people seem to be saying 'yes we do start just one
> sprint ahead of development, but it is usually very painful'...especially
> if
> there is no pre-existing style guide or ux infrastructure set up.
>
> This is what I'm struggling with. A lot of agilists talk about big design
> up
> front as if it is anathema to successful product development. But what
> about
> spending time doing user research up front? Is time spent on user research
> bduf or is it an essential clarification of the problem before design
> starts? I get the feeling that existing agile methods rely heavily on
> supporting structures in an organization - for example, on good up front
> strategy and leg-work done by a product manager before a project starts.
>
> Jeff Patton states in his article (
> http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html)
> "if
> you're a user experience professional, you will need to adapt your current
> practice to work within an Agile value system and lifecycle." I agree with
> this statement but I'm not sure this should be a one-way street. If there
> is
> a UX team or person working in the group, then the team should evaluate
> their process and work in a way that is optimally efficient, not just ask
> the uxers to adapt to fit into agile processes (which were 'created by
> developers for developers').
>
> In my example, my company has a number of factors working against a quick
> up
> front design. 1. we are working on complex logistics software with a huge
> range of uers/usage patterns, and 2. I am a relatively junior ux designer
> and the only ux practitioner in the company, and 3. we have no product
> manager or business analyst working on the product. In our case, starting
> design just a 2 week sprint before development was a disaster, and I'm
> happy
> that my boss realized that it would to step backwards and spend the time on
> research and strategic/conceptual design. It also helped that our devs had
> a
> lot of complex technical stories to work on while the designwork was going
> forward; so there was actually no delay in starting with development, but
> instead a delay in starting the development of the UI.
>
> Sooo...I guess the what I'm trying to say in my rather long-winded mail is
> that I appreciate that my company took a more flexible appraoch to agile
> methods to accomodate our particular circumstances. I feel that blind
> adherence to agile practices and rules such as "Sprint 0 should be no
> longer
> than a regular sprint" can nullify a lot of the value that good ux work can
> bring, as well as place undue stress of the ux practitioner/team. Up front
> UX work is aimed at reducing the risk of developing the wrong product -
> exactly the same reason why agile methods suggest that teams avoid bduf and
> start development asap. I think that both tactics are methods that can be
> used to optimize development and bring value in a project. Our director of
> IT, for example, was really impressed with paper prototyping efforts done
> during our 8 week design phase, and noted that we saved a lot of
> development
> time doing these design activities up front.
>
> Feel free to argue - perhaps I am just going through the agile denial phase
> that Jeff talks about in his article ;-).
>
> Cheers,
> - liz
>
> --
> Elizabeth Whitworth
> User experience specialist
> TRANSPOREON GmbH
> Ulm, Germany
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>