Everyone - thanks for all the responses. Great discussion. I just
wanted to follow up and (for what it's worth) let everyone know that
my team has decided not to pursue the introduction of personas at this
point. We agreed with many on this list who felt the impact was low
relative to the time investment. We're doing other things to bring
focus to our users - such as usability test briefings and group design
sessions where our design leads mentor our development staff and of
course advocate for our user base.

That said, I do think there is value with personas. Obviously many of
you use them with good success, and they've been helpful for me in the
past as well. Two main things drove our decision to not pursue them:
1)The context of Agile - time/resources are scarce & 2)It seems the
archetype personas are easiest to create but better for marketing and
other stakeholders. More detailed personas that focus on detailed
tasks & come accompanied with use cases or scenarios are better for
developers (our audience in this case) but take longer to use.

Thanks all,
Jeff

I'm looking for a Web Developer/Designer to join an exciting new
startup/skunkworks opportunity on my team at Corbis in Seattle.

This greenfield project will be run in a strictly extreme
programming, 1 week iteration style with a collocated development
team in a oobeya style big room office, direct customer involvement
on a daily and weekly basis (depending on level of the customer).

The project is set to run for 5 months through the end of this year,
with the hope of future extensions.

The opportunity is contract W2 or 1099 through our preferred
staffing vendor - a well known agile/Scrum consultancy based in
Redmond, WA. Given the current job market, we're paying very
competitive rates based on experience and suitability for the
position.

I'm looking for someone who is comfortable working in a startup
environment, has a track record of design and development of web
properties for startup firms or skunkworks projects within larger
companies. We're looking for a hybrid interaction design/developer
with AJAX, Flash, DHTML, CSS, graphic design skills and possibly
C#, .Net, Java and SQL.

Corbis offers a dynamic environment based in downtown Seattle. We're
building one of the best agile/Lean technology teams. The company is
well known for its stock photography and image licensing business
and its developing creative services businesses. It is a privately
held company solely owned by Bill Gates.

If you are interested in coming and joining my team and working on
an exciting new project in an extreme agile fashion, then send your
resume to me david.anderson@...

Applicants must have the legal right to work in the United States
and must be available to start in our Seattle office within the next
few weeks. No remote workers please. No agencies. No consultancies.
Thanks.

David
http://www.agilemanagement.net/

[Apologies for any duplication]

Greetings,

I am visiting San Francisco, visiting with several clients and
enjoying the Bay Area with friends while my kids are away for the
summer. If you're in this area too, I'd love to meet with you. I'm
hosting an informal cocktail hour in San Francisco on Monday,
August 6, from 5:30-7:00. (Ok, the hour is really 90 minutes, but
after a few drinks, I won't be able to tell.)

Join me and other web designers, usability professionals, information
architects, interaction designers, content managers, and other user
experience professionals as we meet, greet, and connect up with other
folks who face the same challenges we have.

I've chosen the Waterfront Restaurant on Embarcadero at Broadway.
It's got great views of the bay and is near the Embarcadero BART/Muni
station and on the famed F-Line. If the weather is nice, we'll be out
in the outside seating area, otherwise we'll take over the bar.

San Francisco Social Hour - Monday, 8/6 - 5:30-7:00 pm
Waterfront Restaurant
http://www.waterfrontsf.com/
Pier 7 at Embarcadero/Broadway
San Francisco, CA 9411
Phone: 415-391-2696
Map: http://tinyurl.com/yvmrz3
No RSVP necessary.

Hope to see you there,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool@... p: +1 978 327 5561
http://uie.com  Blog: http://uie.com/brainsparks

The Softletter/TechSmith User Experience Survey

What is Your Perspective on User Experience Research?

Participate in the survey online here:

http://www.surveymonkey.com/s.aspx?sm=zokfa7246nv7oosNOtwl6w_3d_3d

User experience and voice of the customer issues are becoming of
increasing importance to software companies. Together, Softletter and
TechSmith want to know how these issues will impact your development,
product management, and requirements management processes. This survey
consists of 12 brief questions about user experience practices in the
software industry and should take about 10 minutes to complete.

The purpose of this survey is to find out how familiar people are with
different user experience practices, who is using them, how, and which
practices are used most often.

Why should I participate?

All survey respondents will receive a free summary of the results in
the October 15th issue of Softletter. Also, TechSmith will use the
results to tailor their User Experience solutions to better meet your
needs. As an added bonus, all participants can enter to win free
TechSmith software!

Participate today here at:

http://www.surveymonkey.com/s.aspx?sm=zokfa7246nv7oosNOtwl6w_3d_3d

Sincerely,

Rick Chapman
Managing Editor, Softletter
www.softletter.com

Hi

I've been following discussions on this list with interest in the
belief that agile software development methods are the way forward.  I
regularly provide tactical ergonomics/usability support to enterprise
projects using traditional software development processes (can I say
waterfall here?) and am comfortable with applying UX methods in this
context.

I now find that I have the opportunity to provide tactical ergonomics/
usability support to an agile team for the first time.  I have a basic
understanding of how my approach must scale to fit but would be
extremely grateful if you could direct me to any introductory
resources on the web or in recommended texts.

Cheers
Richard

--- In agile-usability@yahoogroups.com, "Faith Peterson"
<f.a.peterson@...> wrote:
>
> Richard,
>
> If you haven't yet visited Jeff Patton's site at
agileproductdesign.com, I
> strongly recommend it

<blush>

Thank you Faith for the kind words.

I've been slower than I'd like at getting ideas and techniques
published - and I've found I've had to iterate lots to find ways to
explain things such that they're easy to understand and put into
practice.

My ongoing struggles at a book can be found at:
www.outside-in-development.com.  While the work is somewhat
incomplete, and much of what's there is a few iterations shy of
"done", you might find some of the collaboration techniques explained
there useful.  Also, I try to give a "non-denominational" perspective
of agile development - although I can't guarantee it's completely free
of religion.

Thanks again,

-Jeff

--- In agile-usability@yahoogroups.com, "White, Jeff" <jeff.white@...>
wrote:
> Also - what's the drama over the scrum master training? There are a few
> product managers at my company wanting to get certified.

It's a two day course that many in the Agile community don't feel
deserves the prefix "certified."  It'll give your people a quick dip
in Scrum - and a good perspective on the value system that motivates
it.  If you're unfamiliar with Agile development or Scrum to start
with, you have a lot more to learn to become proficient in it.  I say
this as a certified scrum master myself.

Thanks,

-Jeff

I wanted to do a quick opinion poll... but to answer my question, I'll
have to supply some context.

Lately I've been working hard to explain to people the difference
between iterating and incrementing.

By iterating I mean that I might design and/or build something,
evaluate it, then adjust it, then evaluate it, then adjust it... keep
doing that till I feel it's the best quality I can get - till I feel
I've reached something I can live with.  Basically the product becomes
more refined -  it likely becomes simpler, it may even shrink in size
or complexity.

By incrementing I mean I might design and/or build something, evaluate
it, then add a little more, then evaluate it, then add a little
more....   Basically the product grows and grows.

I see many people say they're doing iterative development, but really
they're incrementing.  You'll see this in agile development when you
play a user story and expect to "get it right" - not go back and play
another story to refine it.  In agile development environments that
increment, they never seem to plan for iterative refinement of
stories.  The result is every time we want to we want to play a
subsequent story to refine a previous one, we end up in a bit of a
scuffle about what story needs to be removed from the release plan.
Basically - the release plan was built with no intention of iterating
- only incrementing.

In my head increments are for releasing value to customers and
end-users.  Iterations are for building and refining until I've reach
a quality level that I can release - or run out of time, budget, or
stomach to spend more.  Of course by iterating I mean a bit of a blend
- iterate on stories till they're good, and incrementally add more
stories till you reach something releasable.

My bias is coming through clearly in the way I explain this - but try
to ignore that.  I've seen lots of environments where people increment
and seem to deliver successfully.

I'm curious which you do?

And, the reason I ask is that heard from a few sources that
incrementing might work best - especially where UI design is
concerned.  That is to say we work out the UI then hand over a user
story as a completely worked through piece of UI to simply build.  We
don't plan on making changes after we build it.  All the iteration was
done by the UI people using prototypes or other means.  Or, in yucky
cases, iteration never occurred.  We just settled on the first UI we
came up with.

Again - my bias is towards developing very simple UI in early
iterations and refining it through iterative development.  But this is
a strategy that seems to make some twitchy.  They seem to want the UI
right on the first iteration they see it.

Finally, my friend Alistair wrote a bit about his 3-card approach to
injecting some iteration back into agile development:
http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development

Thanks,

-Jeff

--- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
> Finally, my friend Alistair wrote a bit about his 3-card approach to
> injecting some iteration back into agile development:
>
http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development

Actually, this is the link I meant:
http://alistair.cockburn.us/index.php/Three_cards_for_user_rights

Hi, Jeff,

I think it is difficult to draw a clear line in reality between
iterating and incrementing, since those two co-occur and complement
each other mostly.

Thesedays I see the development of the system with the eye from
developmental biology(and evo-devo), and more specifically,
morphogenesis. (see also Christopher Alexander's recent quests at
http://www.livingneighborhoods.org )

In my recent projects, we made a system that's valuable to the
customer(or user) from day 1. This is very important. Day 1. I really
mean it. It was incrementally delivering more values to the
user/customer and iteratively refining/developing the system(first you
see a stubby stick coming out and after a while it develops into five
small sticks budding out from it to form a primitive start of a hand)
as a _whole_, in terms of "whole" in Alexandrian vocabulary. The
results of the projects were great.

I can't exactly say I was doing either iterating or incrementing, when
I'm forced to choose one between the two. However, I know that I can
confidently say that it was growing up.

June Kim

2007/8/9, Jeff Patton <jpatton@...>:
> I wanted to do a quick opinion poll... but to answer my question, I'll
> have to supply some context.
>
> Lately I've been working hard to explain to people the difference
> between iterating and incrementing.
>
> By iterating I mean that I might design and/or build something,
> evaluate it, then adjust it, then evaluate it, then adjust it... keep
> doing that till I feel it's the best quality I can get - till I feel
> I've reached something I can live with.  Basically the product becomes
> more refined -  it likely becomes simpler, it may even shrink in size
> or complexity.
>
> By incrementing I mean I might design and/or build something, evaluate
> it, then add a little more, then evaluate it, then add a little
> more....   Basically the product grows and grows.
>
> I see many people say they're doing iterative development, but really
> they're incrementing.  You'll see this in agile development when you
> play a user story and expect to "get it right" - not go back and play
> another story to refine it.  In agile development environments that
> increment, they never seem to plan for iterative refinement of
> stories.  The result is every time we want to we want to play a
> subsequent story to refine a previous one, we end up in a bit of a
> scuffle about what story needs to be removed from the release plan.
> Basically - the release plan was built with no intention of iterating
> - only incrementing.
>
> In my head increments are for releasing value to customers and
> end-users.  Iterations are for building and refining until I've reach
> a quality level that I can release - or run out of time, budget, or
> stomach to spend more.  Of course by iterating I mean a bit of a blend
> - iterate on stories till they're good, and incrementally add more
> stories till you reach something releasable.
>
> My bias is coming through clearly in the way I explain this - but try
> to ignore that.  I've seen lots of environments where people increment
> and seem to deliver successfully.
>
> I'm curious which you do?
>
> And, the reason I ask is that heard from a few sources that
> incrementing might work best - especially where UI design is
> concerned.  That is to say we work out the UI then hand over a user
> story as a completely worked through piece of UI to simply build.  We
> don't plan on making changes after we build it.  All the iteration was
> done by the UI people using prototypes or other means.  Or, in yucky
> cases, iteration never occurred.  We just settled on the first UI we
> came up with.
>
> Again - my bias is towards developing very simple UI in early
> iterations and refining it through iterative development.  But this is
> a strategy that seems to make some twitchy.  They seem to want the UI
> right on the first iteration they see it.
>
> Finally, my friend Alistair wrote a bit about his 3-card approach to
> injecting some iteration back into agile development:
> http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development
>
> Thanks,
>
> -Jeff
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

On 8 Aug 2007, at 15:12, Faith Peterson wrote:
[snip]
> I'm looking forward to learning more from all of you.

Welcome - and ditto (it's not a one way street y'know :-)

Adrian

On 7 Aug 2007, at 23:17, Richard Collins-Bye wrote:
[snip]
> I now find that I have the opportunity to provide tactical ergonomics/
> usability support to an agile team for the first time.  I have a basic
> understanding of how my approach must scale to fit but would be
> extremely grateful if you could direct me to any introductory
> resources on the web or in recommended texts.
[snip]

I'll second the recommendation of Jeff's blog & web site - great stuff.

You might also find some of the stuff under <http://del.icio.us/tag/
agile+ux> of interest.

Adrian

On 9 Aug 2007, at 05:41, Jeff Patton wrote:

> --- In agile-usability@yahoogroups.com, "White, Jeff" <jeff.white@...>
> wrote:
>> Also - what's the drama over the scrum master training? There are
>> a few
>> product managers at my company wanting to get certified.
>
> It's a two day course that many in the Agile community don't feel
> deserves the prefix "certified."  It'll give your people a quick dip
> in Scrum - and a good perspective on the value system that motivates
> it.  If you're unfamiliar with Agile development or Scrum to start
> with, you have a lot more to learn to become proficient in it.  I say
> this as a certified scrum master myself.

That's not to say that they're not good courses. Most folk I know who
have been on one say they were most useful.

They're just the start of the journey - not the end.

Adrian

Sorry Jeff, but I re-read your post twice and I still don't get the
distinction.

Can you provide a concrete example of a particular story and what it
might mean to iterate vs increment over it?

Alain

> -----Original Message-----
> From: agile-usability@yahoogroups.com
> [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
> Sent: August 9, 2007 1:04 AM
> To: agile-usability@yahoogroups.com
> Subject: [agile-usability] incrementing vs. iterating
>
> I wanted to do a quick opinion poll... but to answer my
> question, I'll have to supply some context.
>
> Lately I've been working hard to explain to people the
> difference between iterating and incrementing.
>
> By iterating I mean that I might design and/or build
> something, evaluate it, then adjust it, then evaluate it,
> then adjust it... keep doing that till I feel it's the best
> quality I can get - till I feel I've reached something I can
> live with.  Basically the product becomes more refined -  it
> likely becomes simpler, it may even shrink in size or complexity.
>
> By incrementing I mean I might design and/or build something,
> evaluate it, then add a little more, then evaluate it, then
> add a little
> more....   Basically the product grows and grows.
>
> I see many people say they're doing iterative development,
> but really they're incrementing.  You'll see this in agile
> development when you play a user story and expect to "get it
> right" - not go back and play another story to refine it.  In
> agile development environments that increment, they never
> seem to plan for iterative refinement of stories.  The result
> is every time we want to we want to play a subsequent story
> to refine a previous one, we end up in a bit of a scuffle
> about what story needs to be removed from the release plan.
> Basically - the release plan was built with no intention of iterating
> - only incrementing.
>
> In my head increments are for releasing value to customers
> and end-users.  Iterations are for building and refining
> until I've reach a quality level that I can release - or run
> out of time, budget, or stomach to spend more.  Of course by
> iterating I mean a bit of a blend
> - iterate on stories till they're good, and incrementally add
> more stories till you reach something releasable.
>
> My bias is coming through clearly in the way I explain this -
> but try to ignore that.  I've seen lots of environments where
> people increment and seem to deliver successfully.
>
> I'm curious which you do?
>
> And, the reason I ask is that heard from a few sources that
> incrementing might work best - especially where UI design is
> concerned.  That is to say we work out the UI then hand over
> a user story as a completely worked through piece of UI to
> simply build.  We don't plan on making changes after we build
> it.  All the iteration was done by the UI people using
> prototypes or other means.  Or, in yucky cases, iteration
> never occurred.  We just settled on the first UI we came up with.
>
> Again - my bias is towards developing very simple UI in early
> iterations and refining it through iterative development.
> But this is a strategy that seems to make some twitchy.  They
> seem to want the UI right on the first iteration they see it.
>
> Finally, my friend Alistair wrote a bit about his 3-card
> approach to injecting some iteration back into agile development:
> http://alistair.cockburn.us/index.php/Incremental_versus_itera
> tive_development
>
> Thanks,
>
> -Jeff
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Clearly I've asked the wrong group.  You're all too smart to simply do
one or the other – or to be unaware of which you're doing.  I hear
everyone saying they do both – and alternate between each at different
times and for different reasons.

June: iterating and incrementing are too combined to pick apart.
Emphasis on organic growth.  Great Alexander reference.  June thinks
on a higher plane than I do. ;-)

Faith: This is where I think ICD/IxD/Ux people run into trouble with
some Agle folk who have the bias for delivering index cards with "as a
shmo I want manage widgets so that I can…" stories written on them.
These clearly defer interaction design till late – and consequently
defer iterating UI to immediately before construction – and defer
iterating the /whole/ UI till after some construction – till after we
see it together as working code rather than as a prototype.

I really your the layering suggestion.  I'll try this.  When
delivering /rough/ UI I always need to explain – using big hand
gestures – how things will eventually look once we confirm this bit is
good.  Using an overlay to show a possible visual design would help.
I hate premature elaboration.   ;-)

Mark: The comments that stick in my head are around the tension
between quick turn around and keeping quality standards high, and "is
good enough what we're really after?"  You sorta get at the heart of
what I'm talking about.  Of course most people want things as good as
they can be.  For commercial software, certainly better than
competitors'.  And, "good enough" is both a subjective and relative
term.  Many people's "good enough" is my "stinky sub-standard."

For me quality is something I iterate toward both in prototypes and
later in code.  Early iterations would clearly be too rough to release
to users – later iterations – the one's before the release – I'd
expect quality to be very high.  Basically I want to start with
stories that are "not good enough" and keep adding stories till I get
to "really really good."  You're observation is correct that in many
agile environments they use stories that are "good enough" and
continue with those all the way through – never building to anything
better than "good enough."  And when you add a pile of just "good
enough" stories together, you often end up with "not so good" – the
whole being less than the sum of its parts.

So, on your comment regarding scrutinizing agile process and asking is
"good enough what really after?" – I'd encourage you to scrutinize the
agile /practitioners/ a little harder.  As I practice Agile, I usually
fish for something better than good enough.

Alain:  I think you get what I'm saying – and like everyone else you
don't easily separate the two strategies.  You're "do the simplest
thing that could possible work" comment is a good one.  That was a
mantra I used to hear a lot years ago – and less so today. Don't know
why, or if I've been hanging around in the wrong circles lately.  But,
when I do hear it – it's with developers talking about code – not the
people writing user stories using it as a strategy for putting simple
stories in first and following them up with stories that improve those
stories.

The simplest thing that could possibly work at iteration 1 is
different than the simplest thing that could possibly work at
incremental release 1.  By that I mean on iteration 1 I might want a
simple story that helps me learn something about what I eventually
need – "the simplest thing I could possibly learn from".  The quality
may be too low to release – but, it'll help me learn.  By the last
iteration of the release, I'd like the user experience to be high.
I'd like it to be the "simplest thing I could possibly release."

Thanks everyone for commenting.

-Jeff

> Alain:  I think you get what I'm saying - and like everyone
> else you don't easily separate the two strategies.  You're
> "do the simplest thing that could possible work" comment is a
> good one.  That was a mantra I used to hear a lot years ago -
> and less so today. Don't know why, or if I've been hanging
> around in the wrong circles lately. But, when I do hear it -
> it's with developers talking about code - not the people
> writing user stories using it as a strategy for putting
> simple stories in first and following them up with stories
> that improve those
> stories.

Actually, this mantra was originally coined in the context of code, not
UI. But I think it applies to both.

Note that the mantra does not say to "Stop after the simplest thing...".
It just says start with that and re-evaluate from there.

I find having quickly a minimal working version of a feature helps me
identify the pressure points that matter most.

> The simplest thing that could possibly work at iteration 1 is
> different than the simplest thing that could possibly work at
> incremental release 1.  By that I mean on iteration 1 I might
> want a simple story that helps me learn something about what
> I eventually need - "the simplest thing I could possibly
> learn from".

I like that. It exactly captures what I was talking about above.

> I'd like it to be the "simplest thing I could possibly release."

In my case, that releasable thing is always very different from what I
initially envisaged, and the quick initial build is a necessary step for
me to find out.

Alain

--- In agile-usability@yahoogroups.com, "Desilets, Alain"
<alain.desilets@...> wrote:
>
> > I'd like it to be the "simplest thing I could possibly release."
>
> In my case, that releasable thing is always very different from what I
> initially envisaged, and the quick initial build is a necessary step for
> me to find out.

That's _exactly_ what I mean by iterative development.  And you'd be
surprised at how often in agile environments I've observed people
considering that a failure.  And in particular people in the customer
or product owner role not letting a user story be written or
considered complete until it is exactly the way it should be at
release time - even if the story is played on iteration 1.  (I suspect
my bias is showing through again.)

thanks,

-Jeff

<sorry - clicked send to soon....>

--- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
>
> --- In agile-usability@yahoogroups.com, "Desilets, Alain"
> <alain.desilets@> wrote:
> >
> > > I'd like it to be the "simplest thing I could possibly release."
> >
> > In my case, that releasable thing is always very different from what I
> > initially envisaged, and the quick initial build is a necessary
step for
> > me to find out.
>
> That's _exactly_ what I mean by iterative development.  And you'd be
> surprised at how often in agile environments I've observed people
> considering that a failure.  And in particular people in the customer
> or product owner role not letting a user story be written or
> considered complete until it is exactly the way it should be at
> release time - even if the story is played on iteration 1.  (I suspect
> my bias is showing through again.)

The question for me - from an agile interaction design perspective is
/where/ does the iteration occur?  Outside of code in prototypes, or
in code as working software?

As I've been saying, I've seen an unusual resistance, particularly
from those in a customer role, to iterating in the working software.
This forces it to occur before.  And for me is sometimes problematic.
  There's only so much I can learn from paper - and for my money higher
fidelity prototyping quickly approaches diminishing returns when
compared to working code (at least for the domains I often work in).
But, when I say working code - I mean working code that's not much
better than a prototype.  I don't mean releasable working code.  For
some it may be crystal clear - for others it all seems to confusing
and ad hoc to live with.

Thanks,

-Jeff

> > > I'd like it to be the "simplest thing I could possibly release."
> >
> > In my case, that releasable thing is always very different
> from what I
> > initially envisaged, and the quick initial build is a
> necessary step
> > for me to find out.
>
> That's _exactly_ what I mean by iterative development.  And
> you'd be surprised at how often in agile environments I've
> observed people considering that a failure.  And in
> particular people in the customer or product owner role not
> letting a user story be written or considered complete until
> it is exactly the way it should be at release time - even if
> the story is played on iteration 1.  (I suspect my bias is
> showing through again.)

I'm quite puzzled by that.

I would think that a team that a team that opted for an Agile approach
would consider reworking a story as a normal and desirable thing. If
anything, if you never need to rework a any stories, you are probably
consitently overshooting and wasting money on gold plating.

But it sounds like you have seen many teams where people (even including
developpers by the sounds of things) interpret the need to rework a
story as a sign that something was done wrong?

Makes you wonder if those people really understand Agile development
altogether.

Alain