On Nov 30, 2006, at 10:44 AM, Desilets, Alain wrote:

> I agree that this comparison is not fair, because I am comparing two
> nurses working in the same unit, whereas I am comparing two arbitrary
> users of the photo manager. But that's the kind of the point. With
> corporate software, there is an existing structure that groups
> people by
> function, education, and those introduce a minimal amount of
> uniformity
> (again, I'm not saying that individual differences don't exist
> within a
> same work unit... Just saying that there is a bit more uniformity
> there).

I don't believe that's true in most cases. The "uniformity" always
exists at some level ("we're all made of meat" - http://
www.terrybisson.com/meat.html ), but when you get into the
particulars that will inevitably affect design, you rarely see
uniformity across a role.

Two nurses in the same unit could have substantially different needs
from the CBC Blood Order page. One nurse, new to the unit, primarily
spanish speaking, with tremendous familiarity with computer
technology, but no previous experience with other parts of this
particular system, could have very different design requirements than
another nurse, familiar with the unit's practices and the existing
system, primarily english speaking, and timid with anything but basic
mouse functions. One role, two personas.

Look closely at anything and uniformity disappears. ( http://
www.despair.com/individuality.html )

> For consumer products, you have to discover these groupings the
> hard way. All the pre-established categories like Age, geographical
> region, language, revenue, etc... are not likely to be useful by
> themselves for predicting the needs and behaviours of the user
> w.r.t. to
> the system.

Having worked in "consumer products" (which I still think you've
misnamed) for a long time, I can tell you that demographic
categories, such as age, geographical region, language, and revenue,
are rarely useful in determining design requirements. (How do wealthy
people use a photo editing tool different than poverty-level folks?)

What we need to look for are factors which determine differences in
behavior, which our design will then need to compensate for.

I have the advantage that I switch frequently between the
environments you claim are distinct. In those travels, I see few
differences in how you approach design. At least, when there are
differences in approaches to design, they don't divide on the lines
you've described.

Jared

> > With corporate software, there is an existing
> > structure that groups people by function,
> > education, and those introduce a minimal amount
> > of uniformity (again, I'm not saying that
> > individual differences don't exist within
> > a same work unit... Just saying that there
> > is a bit more uniformity there).

> Look closely at anything and uniformity disappears.
> ( http://
> www.despair.com/individuality.html )


I do find that I use personas less often in the
enterprise and more often in the consumer world, but I
would attribute this to the relative "horizontal-ness"
of the system under consideration, rather than the
"enterprise-ness" of system.

When you have a very vertical application in the
enterprise context, roles can go a long way and are
often a good enough model to use--especially when
combined with feedback from actual users.

But when the system is more horizontal--a phone system
perhaps--personas become more useful because the role
"phone user" doesn't get you very far.

I agree with Jared that the closer you look, the less
uniformity you have. Thus "horizontal-ness" is
something of an artificial distinction. If are
motivated to look at any vertically-defined role
closely enough, if you spend enough money and time,
you can make a vertical role as horizontal as you
would like.

So what determines "horizontal-ness?" I would argue
that (in terms of deciding whether you use personas as
a design tool) you consider both the intrinsic
differences of behavior and motivation, but also the
extrinsic factors: namely the relative value of
investigating those differences on any given project,
and the relative motivation of the client to pay for
that value.

JS

Hi everyone out there! I'm currently designing a team that will have
to build an off-the-shelf application. I don't have much knowledge on
usability, but I intuitively consider it crucial to have some expert
on that field inside the team. I have asked to the HR person in the
company to go hire someone, but she said she hadn't ever heard the
term "usability" before. The company is located in Costa Rica, which
makes a simple post on Monster not very realistic an approach. Do you
know of any usability group in Costa Rica? Should I look for a
graphical designer specialized in that field? A computer scientist?
Neither? Both? Have you had any experience with "usability consulting"
offshoring?

Thanks in advance for your help,
Alan

You could post a call to the Discuss list hosted by
the Interaction Design Association. See www.ixda.org.

You could also post a call to the CHI-JOBS list.

Finally, SIG-IA has an active mailing list, and you
could do worse than posting there.

The alphabet soup of names and acronyms in this field
is quite remarkable. One place to start sorting them
out is at http://www.uxnet.org/organizations.php. The
User Experience Network is dedicated to bringing
together people who do "user experience" work,
regardless of the acronym by which they identify.

Good luck!

JS


>
> Hi everyone out there! I'm currently designing a
> team that will have
> to build an off-the-shelf application. I don't have
> much knowledge on
> usability, but I intuitively consider it crucial to
> have some expert
> on that field inside the team.

Question, take 2...

Have any of you worked with/heard of a set of tools for doing
application life cycle software development that you liked? You know,
usual soup-to-nuts quest for something to handle *or* support project
mgt/visibility, release mgt, through to iterative development, testing...

My preference is jira and confluence, etc., it would work, but company
is fearful of it being "too" lightweight :-)

However, we just looked at MKS (completely customizable) and VSTS (of
course very centered around VS). Both would probably do the job,
obviously costs $$$.

I am about to look into Rally this afternoon. Anyone have any insights
into Rallydev's tools? Also $$$.

jon
blog: http://technicaldebt.com

I don't think I'm the right person to answer your question but I think
my experience is somehow related to the problem you are mentioning.

HTML and CSS is good for middle-fidelity prototypes, for my case. When
I needed higher fidelity I used javascript and DHTML and implemented
some mock dynamic behaviours. The turn-around time is quite short.

I also tried XUL. It was about two years ago. There was a high cost in
climbing up the learning curve, particularly due to the lack of
experience and proper documentation. In addition to that, there were
hidden pitfalls, like undiscovered bugs and etc. We used to google all
day long to solve problems.

Recently I used Python and wxWindows (wxPython) for rapid
high-fidelity prototyping tool. That was very pleasing. What could've
taken a week for us to do in other options could be done in ten
minutes.

After learning many lessons from all those experiences and quest for
the-right-prototyping-tool, I keep in mind the danger in chasing
high-fidelity prototypes and value lo-fi protos even higher than
before. After all, all protos are wastes(in the sense of Lean), aren't
they?

Watching Robert Rodriguez' DVDs helped me challenging my old beliefs.


2006/12/8, Theo Mandel, Ph.D. <theo@...>:
>
>
> I've been creating high-fidelity prototypes using HTML and CSS for a client PC
application. The system architect says they are moving toward using Windows
Presentation Foundation (WPF) and XAML (Extensible Application Markup Language).
We are discussing how this will affect how we prototype and build the
application in the future.
>
> Prototyping with HTML has been quick and easy for turnaround time and for
remotely reviewing with user groups. I'm concerned about the learning curve and
programing aspects of prototyping using WPF and XAML. I'd like to hear from
other UI and interaction designers about their experiences with low- and
high-fidelity prototyping in HTML vs. WPF and XAML.
>
> Please respond to the list or to me directly.
>
> Theo Mandel, Ph.D.

Hi,

Background:

I am in the unique position of working at a company that is growing
rapidly and is ready to establish a software development process
(feels like a start-up to me). We have a multi-national workforce
with offices and developers in St. Louis, Montreal, and Hyderabad
(India).

Our VP of Engineering is an advocate for agile and XP practices. The
issues with implementing these practices include a very small group
of Product Managers and training in these methods. Our VP has done
some initial training and introduced UML, patterns, and unit
testing. We have 2 product managers and one VP of Product
Management. In the best case scenario, the product manager would be
the "user in the room" with software engineer. Let me just say that
Product Management and Engineering  were once the same small group
of people - now they are two groups and we have to decide who does
what.

In Engineering we have one User Experience specialist and a QA group
in addition to the large group of software engineers. I am the lone
Technical Writer (and I have some usability experience).

We are doing some informal brainstorming and I am gathering the
ideas. On the way to work this morning I was wondering if card
sorting would be a useful technique to help capture this process we
are trying to define.

I expect that our process will have as many elements from agile as
possible(and maybe rational unified process - RUP) massaged a bit
here and there. We have access to users (alpha and beta sites and
some internal folks) which is wonderful. We have a UI styleguide
started and the User Experience specialist and I have visited our
alpha site. The Client Services folks are doing some task analyses.
I would love to make some personas.

Questions:

1. Has anyone used card sorting to define a business process? If so,
was it helpful?

2. If we could only include one thing from the usability world in
our as agile as possible process, what should it be?

Thanks for your help!
Esther

> 1. Has anyone used card sorting to define a business
> process? If so,
> was it helpful?

Card sorting is very useful for creating
categorization schemes, and for identifying the way
people think about the relationships between various
elements. I have never seen it used to solve the
problem you describe.

> 2. If we could only include one thing from the
> usability world in
> our as agile as possible process, what should it be?

Watching people work.

--- In agile-usability@yahoogroups.com, "eklay" <eklay@...> wrote:
> Questions:
>
> 1. Has anyone used card sorting to define a business process? If so,
> was it helpful?
>
> 2. If we could only include one thing from the usability world in
> our as agile as possible process, what should it be?
>

Hi Esther,

A couple of thoughts...

Beware trying to define your process entirely up front to accomodate
anything and everything that comes up during brainstorming.

In the spirit of "as agile as possible", you may want to start with a
very simple process, and do bi-weekly retrospectives to see what's
working and what might need some improvement.

In other words, be agile in defining your process in the first place.
  Some good places to start (which you may already have in place):

- Communciate frequently with your customers since you actually have
some.  The most useful way to do this is to deliver and demonstrate
working software to them. Failing that, the second most useful way is
to show them prototypes of proposed functionality to get feedback.

- In terms of usability, I've found paper prototypes to be an
effective way of this kind of initial communication.  For more remote
customers, some sort of HTML low or medium fidelity prototype can be
really effective as well.

- Let the team have as much say as possible in HOW they will work.
It's much more effective to let the people doing the work specify
their own process rather than trying to dictate it up front.

Good luck!

--Dave

Dave Churchville
http://www.extremeplanner.com/blog

--- In agile-usability@yahoogroups.com, "eklay" <eklay@...> wrote:
> I am in the unique position of working at a company that is growing
> rapidly and is ready to establish a software development process
> (feels like a start-up to me). We have a multi-national workforce
> with offices and developers in St. Louis, Montreal, and Hyderabad
> (India).

One critical question is: do development efforts span time zones - and
by that I mean "concept to cash" - the ideas about what to build and
the actual construction of the thing.  Separating ideas from
construction is sort of a risk.  It forces your process to have more
elements to effectively capture and communicate ideas, and later
evaluate the software built based on those ideas.

>
> Questions:
>
> 1. Has anyone used card sorting to define a business process? If so,
> was it helpful?

Not card sorting, but card modeling.  It was Larry Constantine that
infected me with my love of card modeling.  In my current work we use
cards to model most anything.  Random information can be clustered by
affinity.  Cards can be arranged in sequence to form business
processes.  Standard swimlane style business processes can be easily
built using cards.

As a tool, cards will help.

But using cards won't solve your problem - just like me recommending
you use a hammer won't solve a house-building problem.  You've got
lots of other concerns to balance.

I'd echo Larry's statements about starting with end, or successful
outcomes in mind.  Identify "deliverables" to communicate from one
group to another.  Keep them as light as possible - and favor face to
face communication.  Identify "consumables" as models or artifacts you
build to help you progress your level of understanding.  Insert
validation or feedback loops wherever you can to validate decisions
made a forwarded to others.  Remember the only real deliverable is the
finished software to the consumer.  Real validation is made by their
sucessful use of the product to meet their goals.

> 2. If we could only include one thing from the usability world in
> our as agile as possible process, what should it be?

I'm not sure.  Larry makes a good point about task and activity
modeling.  But, part of me is concerned that thinking about tasks and
activities seems a bit abstract for some folks - though I wish it
wasn't.  I struggle when teaching it to some groups.  I've had very
good luck teaching paper prototyping as a technique.  I think Dave
brought that up.  Look at this paper from Gerrard - which I've likely
mentioned before:
http://www.agileproductdesign.com/useful_papers/meszaros_agile_usabilty.pdf
Handouts for classes I teach are here:
http://www.agileproductdesign.com/presentations/usage_to_user_interface/index.ht\
ml
  I've stolen Larry's abstract prototyping ideas and combined them with
Carolyn Snyder's prototyping and testing basics.

Also, to further confuse you, this recent blog entry about process and
methodology might be worth looking at since it reports on statements
made by Christine Perfetti of UIE fame:
http://www.agileproductdesign.com/blog/there_is_no_spoon.html

Looking back there's lots of self promotion in my response to you.
(I'm just so damn excited to actually have a website to point people
to.  ;-)  )  But, if I were constructing a process, I'd really suggest
getting a coach - someone who's done it before to help out.  (I'd
probably choose Alistair Cockburn.)  Processes are a different type of
user centered design.  Just as your software needs to meet user goals
and context of use, so does the process you adopt.  You need to
understand your company's goals and lots about their context.  Think
of techniques, deliverables, and consumables as possible problem
solutions, then seek to assemble a process solution that helps your
organization reach its goals.

Thanks for your post!

-Jeff

Esther wrote:
> I expect that our process will have as many elements from agile as
> possible(and maybe rational unified process - RUP) massaged a bit
> here and there.

In that case I encourage you to read an article I wrote for the ASIS&T Bulletin
in 2005:
"StUX - integrating IA deliverables in a software development methodology"
http://www.asis.org/Bulletin/Feb-05/boersma.html (site is down at the moment of
writing, see below for alternative)

It deals with how, at a previous employer, I helped introduce user centered
design activities into a RUP-based software development process. Both were
documented but, compared to some RUP implementations, pretty light-weight.
(the material was also presented at the 2005 IA Summit. The presentation can be
found here:
http://www.peterboersma.com/blog/2005/03/my-ia-summit-presentation-stux_10.html
)

> 1. Has anyone used card sorting to define a business process? If so,
> was it helpful?

No, but I can recommend a group session where each stakeholder places
cards/post-it notes on a large surface. Sorting them in order and discussing
their definitions, placement, input and output should get you a good first look
at a potential process.

> 2. If we could only include one thing from the usability world in
> our as agile as possible process, what should it be?

The mantra "research, design, evaluate". Implementation is important but design,
founded on good research and evaluated with users in mind (personas help, real
people are also good) is crucial to arrive at a well thought-through product
that can be the basis for a long and happy product life-cycle.

And I second Jeff's(?) suggestion about getting a coach. I have now helped 4
companies develop their processes and I notice I am getting better at guiding
the rest of the organization into the flow. Expect obstruction, rejection,
conservatism. But stay enthusiastic, because it is worth it in the end!

Peter
--
Peter Boersma | Senior Experience Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

I was recently in a phone conference with two of my main client's
managers-responsible-for-usability. That was despite my protestations
that I was totally unqualified to have opinions about (1) how Agile
projects should make use of user experience experts and (2) what
would be a good transition path from up-front-design toward iteration-
by-iteration design.

During the conversation, I had a thought. In my world, the testing
world, someone asking those questions on agile-
testing@yahoogroups.com usually gets pointed to two books (_Testing
Extreme Programming_, and _Fit for Software Development_) and a
somewhat patchy list of links here: <http://www.testing.com/agile/>

Perhaps we could assemble such a list. Someone - oh, perhaps someone
who newly started blogging - could maintain that list at a URL.

What do you tell newbies to read?

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.testing.com/cgi-bin/blog

Ron Jeffries has an interview on InfoQ
(http://www.infoq.com/interviews/jeffries-running-tested-features) that is
nothing short of brilliant in its elegance in making the case for an agile
development process based on the concept of "running tested features." It is
so persuasively focused that one can hardly imagine anyone ever doing things
any other way. (I personally think the visitor comments are overly harsh and
unappreciative of the intelligence of Ron's restatement.)

Apropos to this list, Ron's interview made clearer than ever to me what has
too long been a sort of disconnect between us. In a wonderful bit of verbal
prestidigitation Ron attributes to the business and product owners the
ability and responsibility to "know" what features are needed both initially
and as the software develops. Which, as we know, is precisely the problem.
To always be able to deliver useful and usable software at every cycle, one
must know not only what features are actually needed by users but what is
the minimum set of these to comprise a first delivered working solution.
Such insight into the support needs for specific roles within actual human
activities is non-trivial and does not spring Athena-like from the head of
the local Zeus. If it is to be trusted, it comes from the very research,
analysis, modeling, and yes, design efforts that are so often dismissed by
managers (and some methodologists) who want to make programming and testing
the whole story.

Anyway, I found myself mentally amending Ron's talk and diagrams to take
into account what happens when the features that are being correctly
implemented by an agile process based on "running tested features" but in
which the features are the wrong ones incorrectly prioritized and
inappropriately organized because there was no upfront process, agile or
otherwise, to pin down the nature of genuine user needs within the
activities to be supported. The developers can still win--they deliver what
is asked at the pace projected and promised--but the product and project is
still a failure because of a different form of hidden "negative features,"
namely all the stuff that is not needed or incomplete or just outright wrong
from the end-user perspective.

--Larry Constantine, IDSA

On 11 Dec 2006, at 18:31, Brian Marick wrote:

> I was recently in a phone conference with two of my main client's
> managers-responsible-for-usability. That was despite my protestations
> that I was totally unqualified to have opinions about (1) how Agile
> projects should make use of user experience experts and (2) what
> would be a good transition path from up-front-design toward iteration-
> by-iteration design.
>
> During the conversation, I had a thought. In my world, the testing
> world, someone asking those questions on agile-
> testing@yahoogroups.com usually gets pointed to two books (_Testing
> Extreme Programming_, and _Fit for Software Development_) and a
> somewhat patchy list of links here: <http://www.testing.com/agile/>

Unfortunately I don't think there are books that are as directly
applicable to agile ux work as those are to agile testing.... oh for
some spare time and a vague approximation of writing talent :-)

The only thing I've come across that's explicitly talking about
usability issues in an agile environment is a few chapters in
37Signals "Getting Real" - but that's very much focused on web
development in a pretty narrow context.

> What do you tell newbies to read?

General:

* The Psychology of Everyday Things, Don Norman
* Interaction Design: Beyond Human-Computer Interaction by Jenny
Preece, Yvonne Rogers, Helen Sharp (bias warning - I used to work in
the same building as Yvonne many years back, but I still think it's a
darn fine book :-)
* Jesse James Garrett's The Elements of User Experience
* Software For Use, Constantine & Lockwood

Books on specific practices:

* Handbook of Usability Testing, Rubin (and oldie but a goodie)
* The User Is Always Right, by Steve Mulder & Ziv Yaar (on Persona -
web focused, but most of the material is pretty general)
* The Persona Lifecycle, by John Pruitt, Tamara Adlin
* Designing Interfaces,  Jenifer Tidwell (an UI "patterns" book)
* Paper Prototyping, by Francis Snyder

If it's somebody who already "gets" agile I'd also recommend:

* The Inmates are running the asylum, Cooper
* About Face 2.0, Cooper & Reimann

(I like both of these books, but the language Cooper uses about
developers will, I imagine, annoy people in agile groups quite a bit.
The problems identified are spot on. The solution proposed is a very
un-agile approach in my opinion - but they're still well worth reading.)

Cheers,

Adrian

Hello, Larry.  On Monday, December 11, 2006, at 5:06:38 PM, you
wrote:

> Ron Jeffries has an interview on InfoQ
> (http://www.infoq.com/interviews/jeffries-running-tested-features) that is
> nothing short of brilliant in its elegance in making the case for an agile
> development process based on the concept of "running tested features." It is
> so persuasively focused that one can hardly imagine anyone ever doing things
> any other way. (I personally think the visitor comments are overly harsh and
> unappreciative of the intelligence of Ron's restatement.)

Thank you for those very kind words, Larry. I consider praise from
you to be high praise indeed.

> Apropos to this list, Ron's interview made clearer than ever to me what has
> too long been a sort of disconnect between us. In a wonderful bit of verbal
> prestidigitation Ron attributes to the business and product owners the
> ability and responsibility to "know" what features are needed both initially
> and as the software develops. Which, as we know, is precisely the problem.

Indeed, it is. Once a team gets to the point where they can deliver
features more or less at will, it becomes harshly visible that
"which features" is the real question ... and often a much more
difficult one than "just" learning how to build software on demand
that actually works ... though that's difficult enough for me!

> To always be able to deliver useful and usable software at every cycle, one
> must know not only what features are actually needed by users but what is
> the minimum set of these to comprise a first delivered working solution.

Yes ... though I would say that in general, while we might not be
able to tell the tens from the nines, and the ones from the twos
when it comes to feature "value", we can probably tell the big ones
from the little ones, which means that the product is more likely to
be "pretty darn good" rather than "really terrible".

I would also mention that although the final responsibility rests
with the customer / product owner, the full resources of the team
are available to help figure out what's important and what's not.
Though I run into a lot of teams that need improvement -- that is,
after all, my work -- I haven't ever run into one that was entirely
clueless. So all I'm saying is that we aren't necessarily doomed.

> Such insight into the support needs for specific roles within actual human
> activities is non-trivial and does not spring Athena-like from the head of
> the local Zeus. If it is to be trusted, it comes from the very research,
> analysis, modeling, and yes, design efforts that are so often dismissed by
> managers (and some methodologists) who want to make programming and testing
> the whole story.

While doing these things well requires people of skill, I've
encountered many products that are better than just "good enough",
so while your remarks here, Larry, are a good case for staffing for
these skills, and including practices to apply them well ... I'd say
it's "very valuable" but not "absolutely essential".

> Anyway, I found myself mentally amending Ron's talk and diagrams to take
> into account what happens when the features that are being correctly
> implemented by an agile process based on "running tested features" but in
> which the features are the wrong ones incorrectly prioritized and
> inappropriately organized because there was no upfront process, agile or
> otherwise, to pin down the nature of genuine user needs within the
> activities to be supported. The developers can still win--they deliver what
> is asked at the pace projected and promised--but the product and project is
> still a failure because of a different form of hidden "negative features,"
> namely all the stuff that is not needed or incomplete or just outright wrong
> from the end-user perspective.

I think this is an overly dark view. We see "agile" projects succeed
all the time, without a high incidence of what you're describing
here as "failure".

Of course I could just be lucky ...

Ron Jeffries
www.XProgramming.com
Reason is and ought only to be the slave of the passions.  -- David Hume

2006/12/13, Ron Jeffries <ronjeffries@...>:
> Hello, Larry.  On Monday, December 11, 2006, at 5:06:38 PM, you
> wrote:
>
> > Ron Jeffries has an interview on InfoQ
> > (http://www.infoq.com/interviews/jeffries-running-tested-features) that is
> > nothing short of brilliant in its elegance in making the case for an agile
> > development process based on the concept of "running tested features." It is
> > so persuasively focused that one can hardly imagine anyone ever doing things
> > any other way. (I personally think the visitor comments are overly harsh and
> > unappreciative of the intelligence of Ron's restatement.)
>
> Thank you for those very kind words, Larry. I consider praise from
> you to be high praise indeed.
>
> > Apropos to this list, Ron's interview made clearer than ever to me what has
> > too long been a sort of disconnect between us. In a wonderful bit of verbal
> > prestidigitation Ron attributes to the business and product owners the
> > ability and responsibility to "know" what features are needed both initially
> > and as the software develops. Which, as we know, is precisely the problem.
>
> Indeed, it is. Once a team gets to the point where they can deliver
> features more or less at will, it becomes harshly visible that
> "which features" is the real question ... and often a much more
> difficult one than "just" learning how to build software on demand
> that actually works ... though that's difficult enough for me!
>
> > To always be able to deliver useful and usable software at every cycle, one
> > must know not only what features are actually needed by users but what is
> > the minimum set of these to comprise a first delivered working solution.
>
> Yes ... though I would say that in general, while we might not be
> able to tell the tens from the nines, and the ones from the twos
> when it comes to feature "value", we can probably tell the big ones
> from the little ones, which means that the product is more likely to
> be "pretty darn good" rather than "really terrible".
>
> I would also mention that although the final responsibility rests
> with the customer / product owner, the full resources of the team
> are available to help figure out what's important and what's not.
> Though I run into a lot of teams that need improvement -- that is,
> after all, my work -- I haven't ever run into one that was entirely
> clueless. So all I'm saying is that we aren't necessarily doomed.
>
> > Such insight into the support needs for specific roles within actual human
> > activities is non-trivial and does not spring Athena-like from the head of
> > the local Zeus. If it is to be trusted, it comes from the very research,
> > analysis, modeling, and yes, design efforts that are so often dismissed by
> > managers (and some methodologists) who want to make programming and testing
> > the whole story.
>
> While doing these things well requires people of skill, I've
> encountered many products that are better than just "good enough",
> so while your remarks here, Larry, are a good case for staffing for
> these skills, and including practices to apply them well ... I'd say
> it's "very valuable" but not "absolutely essential".
>
> > Anyway, I found myself mentally amending Ron's talk and diagrams to take
> > into account what happens when the features that are being correctly
> > implemented by an agile process based on "running tested features" but in
> > which the features are the wrong ones incorrectly prioritized and
> > inappropriately organized because there was no upfront process, agile or
> > otherwise, to pin down the nature of genuine user needs within the
> > activities to be supported. The developers can still win--they deliver what
> > is asked at the pace projected and promised--but the product and project is
> > still a failure because of a different form of hidden "negative features,"
> > namely all the stuff that is not needed or incomplete or just outright wrong
> > from the end-user perspective.
>
> I think this is an overly dark view. We see "agile" projects succeed
> all the time, without a high incidence of what you're describing
> here as "failure".
>
> Of course I could just be lucky ...
>
> Ron Jeffries
> www.XProgramming.com
> Reason is and ought only to be the slave of the passions.  -- David Hume
>

Ron, I want to learn the secret for your constant success. Really.

I have a kind of sympathy with Larry.

I have seen a few teams, which believed they were agile and did their
best to be agile very eagerly and dilligently, succeeded as a
development team but failed as a part of the whole business. The level
they achieved technically(speed of building features, the quality of
the code and tests, and etc) was very admirable, even the culture of
the team was so powerful and healthy(compare the team with another
team next to it, you would see heaven and hell) but after a couple of
months their product has vanished from the market, their team
disappeared.

Why does this happen from time to time? Sometimes people want to feel
safe by ignoring bigger pictures. You could use focusing on running
tested features to make that fake safety. I have seen some teams which
lack the explicit guidance of avoiding those pitfalls.

For a project to succeed(in a longer term), what we need, as I think,
is much more than the running tested features. I don't know if RTF has
the generativity for bigger success that Alexander speaks of.
Strategy, usability, marketing, development and all(the WHOLE team)
have to align well. It is not easy for me and I am trying very hard to
get better every month and week.

Recently I read a blog post with similar point.
http://www.artima.com/weblogs/viewpost.jsp?thread=183405 Valuing
Outcomes over Features. I agree.

Larry mentioned in his original post some upfront process, agile or
not. I think a kind of small upfront exploration and setting-up is
beneficial many times, and more important than that is continously
adjusting the direction on the road and trying to see bigger pictures.
For example, I have done light-weight user research upfront and then
iteratively a la Alias, which is usually done before the project start
or after the project(to justify the project) conventionally.

June

I am new to this board, but not new to team building and tckling wicked
problems. I might have a couple of things to offer here:

1) Features > Benefits > Outcomes (this chane reaction is prevalent in the
marketplace as well as process.

2) Culture beats Strategy every time in organizations - particularly small
stressful, high output groups.

Mark



>Why does this happen from time to time? Sometimes people want to feel
>safe by ignoring bigger pictures. You could use focusing on running
>tested features to make that fake safety. I have seen some teams which
>lack the explicit guidance of avoiding those pitfalls.
>
>For a project to succeed(in a longer term), what we need, as I think,
>is much more than the running tested features. I don't know if RTF has
>the generativity for bigger success that Alexander speaks of.
>Strategy, usability, marketing, development and all(the WHOLE team)
>have to align well. It is not easy for me and I am trying very hard to
>get better every month and week.
>
>Recently I read a blog post with similar point.
>http://www.artima.com/weblogs/viewpost.jsp?thread=183405 Valuing
>Outcomes over Features. I agree.
>

On Dec 12, 2006, at 9:03 AM, Adrian Howard wrote:

> The only thing I've come across that's explicitly talking about
> usability issues in an agile environment is a few chapters in
> 37Signals "Getting Real" - but that's very much focused on web
> development in a pretty narrow context.

I'd certainly add Jeff Patton's papers at
<http://agileproductdesign.com/writing/index.html>
He has a chapter (?) in Cockburn's _Crystal Clear_, which I have not
read. Jeff: does it contain material beyond what's on your website?

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.testing.com/cgi-bin/blog

On 13 Dec 2006, at 15:35, Brian Marick wrote:

>
> On Dec 12, 2006, at 9:03 AM, Adrian Howard wrote:
>
>> The only thing I've come across that's explicitly talking about
>> usability issues in an agile environment is a few chapters in
>> 37Signals "Getting Real" - but that's very much focused on web
>> development in a pretty narrow context.
>
> I'd certainly add Jeff Patton's papers at
> <http://agileproductdesign.com/writing/index.html>
> He has a chapter (?) in Cockburn's _Crystal Clear_, which I have not
> read. Jeff: does it contain material beyond what's on your website?

Good point. And Jeff's new blog too.

(I was fixated on paper books for some reason - sorry)

I've a whole bunch of stuff bookmarked in delicious under http://
del.icio.us/adrianh/agile+ux - although some of that may only make
sense when filtered through my brain :)

Adrian

This is more for the upfront end of the process than the back end.
Holtzblatt, Wendell, and Wood wrote "Rapid Contextual Design" about
trying to fit user research and contextual design into an agile process.

daveb

Adrian Howard wrote:
> On 11 Dec 2006, at 18:31, Brian Marick wrote:
>
>
>> I was recently in a phone conference with two of my main client's
>> managers-responsible-for-usability. That was despite my protestations
>> that I was totally unqualified to have opinions about (1) how Agile
>> projects should make use of user experience experts and (2) what
>> would be a good transition path from up-front-design toward iteration-
>> by-iteration design.
>>
>> During the conversation, I had a thought. In my world, the testing
>> world, someone asking those questions on agile-
>> testing@yahoogroups.com usually gets pointed to two books (_Testing
>> Extreme Programming_, and _Fit for Software Development_) and a
>> somewhat patchy list of links here: <http://www.testing.com/agile/>
>>

On 13 Dec 2006, at 16:11, david broschinsky wrote:

> This is more for the upfront end of the process than the back end.
> Holtzblatt, Wendell, and Wood wrote "Rapid Contextual Design" about
> trying to fit user research and contextual design into an agile
> process.

Thanks! Not come across this before - another one for my Amazon wish
list :-)

Adrian

2006/12/14, Brian Marick <marick@...>:
>
> On Dec 12, 2006, at 9:03 AM, Adrian Howard wrote:
>
> > The only thing I've come across that's explicitly talking about
> > usability issues in an agile environment is a few chapters in
> > 37Signals "Getting Real" - but that's very much focused on web
> > development in a pretty narrow context.
>
> I'd certainly add Jeff Patton's papers at
> <http://agileproductdesign.com/writing/index.html>
> He has a chapter (?) in Cockburn's _Crystal Clear_, which I have not
> read. Jeff: does it contain material beyond what's on your website?
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.testing.com/cgi-bin/blog
>

When it comes to the explicit intersection between usability and agile
there aren't many resources.

As I remember, Jeff is writing a book on that intersectional subject.

Mostly papers and general usability books(which Adrian has already
recommended several of) have been great resources to me.

Search in the agile/xp conference materials. For example, Lynn's paper
at http://www.agile2005.org/XR19.pdf is often cited here.

I second this recommendation.

Karen Holtzblatt recently visited Korea (with Don Norman) for an open
lecture. She was very confident of her way of doing work.

I like RCD and I have applied it to web projects along with Lynn's
parallel track method. RCD fits well with agile(there is even an
chapter for applying RCD in agile environments).

2006/12/14, david broschinsky <daveb@...>:
> This is more for the upfront end of the process than the back end.
> Holtzblatt, Wendell, and Wood wrote "Rapid Contextual Design" about
> trying to fit user research and contextual design into an agile process.
>
> daveb
>
> Adrian Howard wrote:
> > On 11 Dec 2006, at 18:31, Brian Marick wrote:
> >
> >
> >> I was recently in a phone conference with two of my main client's
> >> managers-responsible-for-usability. That was despite my protestations
> >> that I was totally unqualified to have opinions about (1) how Agile
> >> projects should make use of user experience experts and (2) what
> >> would be a good transition path from up-front-design toward iteration-
> >> by-iteration design.
> >>
> >> During the conversation, I had a thought. In my world, the testing
> >> world, someone asking those questions on agile-
> >> testing@yahoogroups.com usually gets pointed to two books (_Testing
> >> Extreme Programming_, and _Fit for Software Development_) and a
> >> somewhat patchy list of links here: <http://www.testing.com/agile/>
> >>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

On 13 Dec 2006, at 16:12, June Kim wrote:
[snip]
> Search in the agile/xp conference materials. For example, Lynn's paper
> at http://www.agile2005.org/XR19.pdf is often cited here.
[snip]

There's an agile-toolkit podcast with Lynn, Jeff & Rebecca Wirfs-
Brock that's worth a listen too:

	 http://agiletoolkit.libsyn.com/index.php?post_id=15584

Adrian