On 31 Jul 2006, at 16:30, Jeff Patton wrote:
[snip]
> I think it was Andrew who mentioned that the posture of some
> developers is
> to ask if it was part of the original story - or to suggest putting a
> delight feature in subsequent story.  I work in what should be
> pretty Agile
> environments and this happens a lot.  I didn't look at the Apple
> article,
> but if I get the idea of the feature from reading it, it does seem
> a rather
> simple feature.  And, if implemented once could be easily leveraged
> wherever
> a date appears in a table.  I've stumbled across those sorts of
> feature
> opportunities before and in practice, I routinely see push back from
> developers on implementing them.
[snip]

Wearing my developer hat, if I suggest something go into a subsequent
story I'm not saying "I don't want to implement this", I'm saying
"I'm more than happy to implement this, but don't consider it part of
the story I'm working on at the moment".

When I read "push back from developers on implementing them" I heard
"the developers don't want to implement them" - was I mishearing what
you were saying?

If not, I'm curious what kind of push back you are getting - since my
experience is that agile teams are positively eager to implement
these sorts of feature.

Is it possibly down to an environment where you're not allowed to add/
remove/change stories during an iteration?

Cheers,

Adrian

Hiya,

On 31 Jul 2006, at 15:00, marc mcneill wrote:

> From the outset of a project I look to drive out "emotional
> requirements".

I'm not sure I understand this statement since...

> Asking how important is it to delight the end users and
> prioritising this as
> a story against the functional stories helps guage the extent to
> which we
> need to focus upon making the UI "world class".  If "delight" has a
> high
> priority this will inform the product development and the way in which
> features are developed.  Having the "delight" story lends itself to
> acceptance critieria within each functional story; having it
> explicitly
> stated rather than something that is shoe-horned in at the end when
> the
> marketing department complains that the product is unusable and off-
> brand.

Seems to imply that "emotional requirements" are very much still
present - and useful.

?

Adrian

On 31 Jul 2006, at 16:36, PaulOldfield1@... wrote:

> (responding to Andrew)
>
>
> > I am a product manager, and I can honestly say that the experience I
> > described above rarely happens for me.  95% of the time I will get
> > back from the developer(s) that it was not described like that in
> the
> > story or during iteration planning.  We could put it on the next
> > iteration, but it will take time, yada yada yada.
>
> I like William's comments.
[snip]

Ditto.

For me the phrase "Responding to change over following a plan" comes
to mind.

Are the usability changes are getting a harsher reception than
changes in requirement from the customer? Would the client adding a
new row to w FIT test get the same reception?

Cheers,

Adrian

--- In agile-usability@yahoogroups.com, Jon Kern <jonkern@...> wrote:
>
> there is not a connection between a development process and adding
> "delight" features.
>
> it has nothing to do with simplest solution mantra -- that is generally
> for coding. This purely is a product management issue. the technical
> team merely provides the time and cost estimate.
>

I agree with this in principle, but in my own experience I've seen the
development team actively resist usability changes with "Agile"
justification, rather than passively recite time estimates.

I suspect there's another factor here...with the rise of test-driven
development and automated testing, perhaps features that aren't easy
to test are not as well received?

User interface changes, especially non-trivial ones, have often been a
difficult thing to push through in the Agile projects I've been
involved with.  Yes, they eventually get done, but I've noticed a
lower energy level from the development team.

I can't really explain this except that user interfaces are often
emotional and reasonable people disagree on the "best" implementation.

So unlike a business rule which is objective, UI changes are often
scorned as "stupid" or "unnecessary".  This is what I call the "messy
human stuff" that is an unavoidable part of the software process.

Thoughts?

--Dave

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

--- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>
wrote:
> > a date appears in a table.  I've stumbled across those sorts of
> > feature
> > opportunities before and in practice, I routinely see push back
from
> > developers on implementing them.
> [snip]
>
> Wearing my developer hat, if I suggest something go into a
subsequent
> story I'm not saying "I don't want to implement this", I'm saying
> "I'm more than happy to implement this, but don't consider it part
of
> the story I'm working on at the moment".
>
> When I read "push back from developers on implementing them" I
heard
> "the developers don't want to implement them" - was I mishearing
what
> you were saying?

No, you're not necessarily.  I may be guilty of practicing a very
relaxed form of agile.  For very many years I relied on nothing more
than a story written on a 3x5 card and a conversation.  What was in
and out of a story was very fluid - and almost always a matter of the
ongoing conversation between developer and customer.  Statements
like "I don't consider it part of the story I'm working on" when a
customer might consider it part of the story seem to strike an
adversarial posture I'd characterize as push-back.  Possibly a better
statement might be "this seems like a good idea, but my original
estimate hadn't accounted for it.  Should we up the estimate -
possibly jeapordizing other things in this iteration? - or should we
defer this?"  That's more of the convesation/collaboration that I'd
hope for, and one we were able to cultivate for years.  It's a subtle
difference in language.  And frankly it's often the body language of
the developers that communicates more than the actual words they
use.

Adrian, in a subsequent post you said:
"Are the usability changes are getting a harsher reception than
changes in requirement from the customer?"

This is often the case that usability changes do get a harsher
reception - are often met with skepticism.  Usability changes often
don't add functionality - they just make the functionality we have
better.  If one team member is pushing towards implementing more, and
another team member is pushing towards implementing better, there
will likely be tension.  And, I've observed the same skeptical
reception when the usability changes come directly from the customer.

I think focal to this discussion is the idea of how maleable stories
are: are they "contracts for fixed scope" or are they general goals
to be achieved during an iteration where the details of those goals
are to be worked through collaboratively during the iteration.  I've
observed both extremes in practice on agile projects - and variations
in between.

Thanks for posting and responding.

-Jeff

Hello Dave,

Thanks for your email. On Tuesday, August 1, 2006, at 11:58:37 AM,
you wrote:

> I agree with this in principle, but in my own experience I've seen the
> development team actively resist usability changes with "Agile"
> justification, rather than passively recite time estimates.

The technical term for developers resisting changes and citing
"Agile" as the reason is "bu11sh1t". There is no such transaction
defined in the Agile lexicon.

OTOH, IMO, providing time estimates is not "passive".

> I suspect there's another factor here...with the rise of test-driven
> development and automated testing, perhaps features that aren't easy
> to test are not as well received?

It would surprise me to see a team that was deeply into testing then
come up with such a counter-Agile behavior as you describe, but
anything is possible.

> User interface changes, especially non-trivial ones, have often been a
> difficult thing to push through in the Agile projects I've been
> involved with.  Yes, they eventually get done, but I've noticed a
> lower energy level from the development team.

I wonder why. Possibly they don't believe the business value is
there. Possibly they are aware of (or experiencing) the frequent
customer disfunction of fiddling the GUI while the model languishes.

> I can't really explain this except that user interfaces are often
> emotional and reasonable people disagree on the "best" implementation.

> So unlike a business rule which is objective, UI changes are often
> scorned as "stupid" or "unnecessary".  This is what I call the "messy
> human stuff" that is an unavoidable part of the software process.

I would be surprised to find the kind of debate you describe going
on in a team that has a Release Plan in front of them, with all the
stories estimated and a date in mind. I'd love to sit down with a
team that had those things in place and still had this problem, to
find out why.

Ron Jeffries
www.XProgramming.com
It is better to attempt something great and fail that attempt,
than to attempt to do nothing and succeed.
--Cookie, Garden Court Chinese Restaurant, Hamburg, MI

Dave Churchville wrote:
> User interface changes, especially non-trivial ones, have often been a
> difficult thing to push through in the Agile projects I've been
> involved with.  Yes, they eventually get done, but I've noticed a
> lower energy level from the development team.
>

Hi, Dave. Are you comparing here with non-Agile teams or just with other
features for the same team?
> So unlike a business rule which is objective, UI changes are often
> scorned as "stupid" or "unnecessary".  This is what I call the "messy
> human stuff" that is an unavoidable part of the software process.
>
> Thoughts?
>

It's definitely my experience that nobody can at first believe quite how
"stupid" users are. It's not that users are really stupid, of course;
they're quite smart. But that's a common first reaction.

When I get that reaction, I like to show people the results of user
testing. Programmers are idealists, so they don't like things that are
in principle unnecessary. But they are also pragmatists. If you show
them how users struggle and how that struggle makes them less happy with
the product, you can get them engaged in hacking human behavior.

William

--- In agile-usability@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
> The technical term for developers resisting changes and citing
> "Agile" as the reason is "bu11sh1t". There is no such transaction
> defined in the Agile lexicon.

You mean there's no "Resist stupid customer requests" practice defined
in XP? Even in the second edition???  What about Agile 2.0? ;-)

To be totally honest, I admit to having occasionally used the "Rule of
3" for requests with apparent low business value.  "Wait until they
ask for it 3 times, then you know they're serious"


> > User interface changes, especially non-trivial ones, have often been a
> > difficult thing to push through in the Agile projects I've been
> > involved with.  Yes, they eventually get done, but I've noticed a
> > lower energy level from the development team.
>
> I wonder why. Possibly they don't believe the business value is
> there. Possibly they are aware of (or experiencing) the frequent
> customer disfunction of fiddling the GUI while the model languishes.

Yes, I think it's a questioning of the business value, to be sure.  As
a dev manager, I also sometimes questioned the business value, and
made sure to have the conversation with the customer.  Nevertheless,
once the customer was committed to a course of action, I always
thought they should get the best implementation we could deliver.

A team with low energy around a feature isn't likely to deliver their
best, in my opinion.  Which can lead to lowered trust, etc.  I'm not
saying this is in any way an "agile" problem, just a problem.

By the way, I like the new "Thank you for your question" header :-)
It's funny how a little thing like courtesy can change the dynamic of
a conversation.  So I thank you for your thank you!

--Dave

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

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
> Hi, Dave. Are you comparing here with non-Agile teams or just with
other
> features for the same team?

Hi William,

No, just with other features for the same team.  ALL teams I've been
involved with seem to have reduced energy for UI changes.

Actually, Agile teams are more open to changes in general in my
experience, but still less excited about the UI ones.  So I'm not
suggesting that this is an Agile problem, but I think it's a problem
that hasn't yet been solved (in my experience) by agile techniques.

> It's definitely my experience that nobody can at first believe quite
how
> "stupid" users are. It's not that users are really stupid, of course;
> they're quite smart. But that's a common first reaction.

Yup.  I had to train myself to think "OK, it *seems* like a stupid
request, but there's probably a real need at the heart of it"

In fact, translating between "user-suggested implementation" and
"underlying pain" has turned out to be one of my more useful skills.

> When I get that reaction, I like to show people the results of user
> testing. Programmers are idealists, so they don't like things that are
> in principle unnecessary. But they are also pragmatists. If you show
> them how users struggle and how that struggle makes them less happy
with
> the product, you can get them engaged in hacking human behavior.

Yes, I totally agree with that as a programmer myself ;-)

I've also been fairly successful at motiviating other programmers
around this issue, but it can be exhausting.

--Dave

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

Hello Dave,

Thanks again for your email. On Tuesday, August 1, 2006, at 2:02:36
PM, you wrote:

> --- In agile-usability@yahoogroups.com, Ron Jeffries <ronjeffries@...>
> wrote:
>> The technical term for developers resisting changes and citing
>> "Agile" as the reason is "bu11sh1t". There is no such transaction
>> defined in the Agile lexicon.

> You mean there's no "Resist stupid customer requests" practice defined
> in XP? Even in the second edition???  What about Agile 2.0? ;-)

> To be totally honest, I admit to having occasionally used the "Rule of
> 3" for requests with apparent low business value.  "Wait until they
> ask for it 3 times, then you know they're serious"

Well, from my preferences in Agile, I'm troubled by that. I think
that the dynamics work best when we are quite responsive to
everything they ask for, and when we always express our response in
essentially the same way, something like this:

   We can schedule that story whenever you ask us to. Its cost will
   be <estimate/> days. As you know, we're doing <velocity/> story
   days per week, so we can schedule this story any time you want to
   put <estimate/> story days available for it.

   Looking at the big picture here on the table, we have <total/>
   days of work until the release, and <available/> story days
   between now and that date. We'll work on whatever you want us to,
   and we're as interested as you are in getting the best combination
   of work done by the date. It looks to us, from the big picture, as
   if we have too much to do by the deadline, so we're concerned that
   this story might not be the most important thing to do. But it's
   your decision: we just want to be sure you see the overall
   picture.

This transaction puts the decision where it belongs, as I understand
Agile, namely in the hands of the customer. Their job is to manage
scope to get the project in on time. We want always to make it clear
to them how much is on the table, and it is their job to dispose of
our time as they see fit.

>> > User interface changes, especially non-trivial ones, have often been a
>> > difficult thing to push through in the Agile projects I've been
>> > involved with.  Yes, they eventually get done, but I've noticed a
>> > lower energy level from the development team.
>>
>> I wonder why. Possibly they don't believe the business value is
>> there. Possibly they are aware of (or experiencing) the frequent
>> customer disfunction of fiddling the GUI while the model languishes.

> Yes, I think it's a questioning of the business value, to be sure.  As
> a dev manager, I also sometimes questioned the business value, and
> made sure to have the conversation with the customer.  Nevertheless,
> once the customer was committed to a course of action, I always
> thought they should get the best implementation we could deliver.

Yes ...

> A team with low energy around a feature isn't likely to deliver their
> best, in my opinion.  Which can lead to lowered trust, etc.  I'm not
> saying this is in any way an "agile" problem, just a problem.

It certainly is a problem. The best way I know to solve it is with
open and frequent communication between customers and developers,
with a clear division of responsibility, and a clear picture of the
overall project plan on the table.

> By the way, I like the new "Thank you for your question" header :-)
> It's funny how a little thing like courtesy can change the dynamic of
> a conversation.  So I thank you for your thank you!

Well, I have to admit that it is generally part of my reply template
now, but it does express my real appreciation for the questions and
comments that come along. Thanks for your thank you for my thank
you!

Ron Jeffries
www.XProgramming.com
Do as you will, try to do it well. That's what I do.

--- In agile-usability@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
> > "Wait until they
> > ask for it 3 times, then you know they're serious"
>
> Well, from my preferences in Agile, I'm troubled by that. I think
> that the dynamics work best when we are quite responsive to
> everything they ask for, and when we always express our response in
> essentially the same way, something like this:
...
> This transaction puts the decision where it belongs, as I understand
> Agile, namely in the hands of the customer. Their job is to manage
> scope to get the project in on time. We want always to make it clear
> to them how much is on the table, and it is their job to dispose of
> our time as they see fit.

Yes, again, I agree with this in principle as well my usual practice.

My somewhat tongue-in-cheek "wait for them to ask 3 times" is more
indicative of my former "product manager" hat, where I acted as a
proxy for a diverse set of customers.

Thanks for forcing me to clarify my sloppy comment ;-)

--Dave

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

We have that same situation with a client, who believes we're
"re-designing" the site, yet still wants the old site/process/user
interface.

What we did was present the task flows absolutely separated from the
IA/user wireframes, and kept impressing upon them that the
requirements (i.e. use case flows) didn't necessarily represent the
interface. They seemed to calm down, and we've been working really
closely with the IAs to track the requirements being met in the
interface. We're only part-way through this process, but at least the
swords aren't rattling, yet.
I know it's hard to step back from the UI, for most biz clients 'cause
they're familiar with the interaction, not necessarily the task but
carefully scalpel-ling the reqs from UI has worked for me
(sometimes!). I always come in as the conduit - holding the current
user's hand (your client) and then gently (!) guiding them towards
better - which I totally agree with everyone, you can do through
testing, and good quantitative results.

It sounds like you're being hit with both ends - business and user
expert. I don't envy you, that's for sure!

take care,
a

Dave Churchville wrote:
> No, just with other features for the same team.  ALL teams I've been
> involved with seem to have reduced energy for UI changes.
>
> Actually, Agile teams are more open to changes in general in my
> experience, but still less excited about the UI ones.  So I'm not
> suggesting that this is an Agile problem, but I think it's a problem
> that hasn't yet been solved (in my experience) by agile techniques.
>

Interesting. On a project a couple years back, the XP Customer role was
filled by someone whose background was in UI design. I asked him if his
experience matched yours. His reply is so relevant that I'm going to
quote it at length:

James Home wrote:
> it wasn't true for us, but it's rare that an interface designer has
> the opportunity to be as involved as I was with shaping engineering's
> opinion on what is and isn't important.  the five of us worked
> together pretty seamlessly, unlike most teams where we'd be insulated
> by a product manager gasket on one side and an engineering manager
> gasket on the other.  I have come to believe that those gaskets
> introduce serious social failure points in the communication of an
> interface requirement.  it too often works like this:
>
> - interface designer comes up with a feature that will make some part
> of the application's interface better.  it's a change, but it will
> genuinely improve the user experience.
>
> - interface designer and product manager have great meeting discussing
> the new feature.  product manager notes that the new feature isn't in
> the schedule, but they'll figure something out.
>
> - product manager does a mediocre and self conscious job of explaining
> the feature to the engineering manager, further straining their
> already tenuous relationship.  very little conversation about the
> feature itself happens; the focus of the discussion is on how the
> feature isn't in the existing schedule, and that they really just need
> to get something out the door.
>
> - engineering manager presents the feature to engineering as yet
> another course change by the product team.  no discussion of the
> feature itself takes place, other than a functional description.
>
> - without any sense of the context that led to the proposed feature,
> the engineer sees another "stupid request", and has no enthusiasm for
> implementing it.

This certainly fits in with one of my frequent observations on XP teams:
by keeping in close proximity and constant communication, you don't just
improve the sharing of information; you come to share values, too. On
the team he's talking about, it was a consumer-focused product at a
startup, and the product manager cared passionately about the user
experience, due to both his nature and its critical business importance.
And all of us came to appreciate and care about that, too.


For the resistant teams you've seen, could you tell us more about the
communication flow? E.g., where the product managers sat in relation to
the developers?


> I've also been fairly successful at motiviating other programmers
> around this issue, but it can be exhausting.
>

Interesting. I completely agree that it's an education. I was lucky
enough to do a bunch of general tech support in high school and college,
so I developed an early appreciation for usability. Perhaps in addition
to getting them to watch usability testing, we should have developers
take turns doing support for the products they write.

William

PaulOldfield1@... wrote:
> The card should be a placeholder for the conversation; one
> should not need to do much more than identify the problem
> so we all know what conversation needs to take place.


Absolutely. One of my clients is just adopting the planning game. They
had a painful experience last week where the developer worked for a few
days from some notes on a card; on Thursday they discovered that he went
in the wrong direction, and some of his work needed to be scrapped.

They are having a hard time accepting that the solution to "not enough
information on the card" is to put *less* information on the card, not
more. They'll get there, but it's a struggle.

William

--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:

> For the resistant teams you've seen, could you tell us more about the
> communication flow? E.g., where the product managers sat in relation to
> the developers?

I'll share 2 of these situations (I've got more than that, but that
would be too much writing ;-) )

One of these teams worked on an internal call-center type of
application that was used constantly, and small UI changes actually
had a rather significant impact on productivity.  A single extra
confirmation dialog or even an extra mouse-click was a pretty big deal
for the end users of the application.

However, the "customer" was really the call center director, who
rarely suggested specific UI changes to streamline workflow, but
rather asked for additional features to reduce errors, allow better
tracking or distribution, etc.  The end users and the director were
all in a remote location and timezone (East/West coast).

As "customer proxy", I spent a lot of time on the phone, in
web-conferences, and periodic cross-country trips to make sure we
understood the user needs as they started to expand.  I also included
the development team on relevant phone calls to make sure they were
hearing requests straight from the customer (not just from me).

So the typical flow was:

1. Customer calls me to ask about a new feature: "Can we have a list
that shows X?"
2. I'd try to get at the heart of it: "What will the new list allow
you to do?  What problem are you trying to solve?"
3. Customer answers: "Well, we're making errors when doing Y, and I
think if we had a list of X, we'd make fewer errors".
4. I confer with the team to come up with a solution for the issue,
which might or might not be "a list that shows X", and present to the
customer for approval and validation.
5. We schedule the feature for a release and follow normal agile
processes from there.

The other major resistant situation was for a commercial product,
without direct customer contact (startup = no real customers).  So we
worked with the VP of Product Development who was effectively the
Product Manager since the Marketing dept. wasn't very helpful.

So naturally most of the input was subjective, and not validated by
real customers. We used an Agile process, minus the real customer
validation.  Later on, once we got a few customers, there was still a
gap here, but at least some of the input was from a real user.

Does this shed some light on it?  I suppose these aren't typical
"ideal agile" customer scenarios, but they're part of my real-world
experiences.

--Dave

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

On 1 Aug 2006, at 17:22, Jeff Patton wrote:
[snip]
> No, you're not necessarily.  I may be guilty of practicing a very
> relaxed form of agile.  For very many years I relied on nothing more
> than a story written on a 3x5 card and a conversation.  What was in
> and out of a story was very fluid - and almost always a matter of the
> ongoing conversation between developer and customer.  Statements
> like "I don't consider it part of the story I'm working on" when a
> customer might consider it part of the story seem to strike an
> adversarial posture I'd characterize as push-back.
[snip]

Maybe. I'd tend to see it as the start of a conversation myself ;-)

>   Possibly a better
> statement might be "this seems like a good idea, but my original
> estimate hadn't accounted for it.  Should we up the estimate -
> possibly jeapordizing other things in this iteration? - or should we
> defer this?"

Does "new story" always mean "defer to next iteration" to you?

It doesn't to me - and maybe that's why I don't hear the same
negative tone. Obviously more work means /something/ is going to get
deferred - but it doesn't have to be the new work.

>   That's more of the convesation/collaboration that I'd
> hope for, and one we were able to cultivate for years.  It's a subtle
> difference in language.

Yup. Exactly.

>   And frankly it's often the body language of
> the developers that communicates more than the actual words they
> use.

This is the thing that just seems really weird to me.... developers
not wanting to do new functionality that the customer wants. This is
so anti every experience I've had with agile teams it strikes me as a
sign that something is going badly wrong with the customer/developer
communications.

> Adrian, in a subsequent post you said:
> "Are the usability changes are getting a harsher reception than
> changes in requirement from the customer?"
>
> This is often the case that usability changes do get a harsher
> reception - are often met with skepticism.

Again, I find curious. Any ideas why? Developers making value
judgements about the stories coming from the customer depending on
whether they are usability related or not doesn't gel with the agile
teams I've worked with. A story is a story is a story.

> Usability changes often
> don't add functionality - they just make the functionality we have
> better.

If they're not adding functionality then no code needs to be written.
Job done ;-)

Usability stories /are/ adding functionality. The issue is how
different changes are being prioritised.

> If one team member is pushing towards implementing more, and
> another team member is pushing towards implementing better, there
> will likely be tension.

For me the issue isn't between more and better. It's between
different adding one bit of functionality or adding another.

>   And, I've observed the same skeptical
> reception when the usability changes come directly from the customer.

I wonder if some of this may be due to previous experience of
customers making really bad usability decisions?

I know I've been burned badly by this - both as a usability bod and
as a developer.

> I think focal to this discussion is the idea of how maleable stories
> are: are they "contracts for fixed scope" or are they general goals
> to be achieved during an iteration where the details of those goals
> are to be worked through collaboratively during the iteration.  I've
> observed both extremes in practice on agile projects - and variations
> in between.

The problem with general goals is that it makes it very hard to
define progress and - more importantly - being "done". Getting that
rapid and repeated "finished" fix is really important.

My preference is to have lots of small stories that have very clear
goals. If in the course of implementation we find that some of those
goals need to be changed or amended in any non trivial way I much
prefer to add a new story into the current iteration than amend the
current story.

I find teams much more productive if everybody is seeing continual
progress and positive feedback.

1) Me: I'll do the display mail messages in columns story now.....
<pause for typing>... done!
2) Customer: Great. All seems to work. Thanks. I have a new story for
you. We need to resize columns.
3) Me: Now I'll do the resize columns story...<pause for typing>...
done!
4) Customer: Great. All seems to work. Thanks. I have a new story for
you. Date columns need to squish.
5) Me: Now I'll do the make date column heading squishy
story...<pause for typing>... done!
6) Customer: Great. All seems to work. Thanks. I have a new story for
you.
... and so on...

Rather than continual negative feedback:

1) Me: I'll do the display mail messages in columns story now.....
<pause for typing>... done!
2) Customer: No you're not - that's rubbish. Look it doesn't work for
long subject lines
3) Me: Hmmm... okay guess I guess I can make then resizeable...<pause
for typing>... done
4) Customer: Well that's complete pants - when I resize the date
field you can only see the time of the message? Get it right!
5) Me: All right already <mutter naughty works under breath while
typing>... done?
6) Customer: Well - I guess it will do...
... and so on...

Okay - I'm exaggerating... slightly...

The worst bit about the negative feedback loop is that you can get to
the end of the iteration and from my perspective I have been working
my ass off all week, and from the customer perspective not a single
story has been completed... very bad.

So I can understand developers pushing back against a continually
growing story, but I can't understand developers pushing back against
new stories.

Hopefully making some vague sort of sense...

Cheers,

Adrian

On 2 Aug 2006, at 16:50, William Pietri wrote:
[snip]
> This certainly fits in with one of my frequent observations on XP
> teams:
> by keeping in close proximity and constant communication, you don't
> just
> improve the sharing of information; you come to share values, too. On
> the team he's talking about, it was a consumer-focused product at a
> startup, and the product manager cared passionately about the user
> experience, due to both his nature and its critical business
> importance.
> And all of us came to appreciate and care about that, too.
[snip]

Yes. This has been exactly my experience, and it clarifies why I find
the experiences of Dave and Jeff so intriguing.

With the agile teams I've worked with the developers /care/ about the
product. They're passionate about building the best possible product
for the customer and actively try and get into the customers head.
Developers are always asking "why?". Not to be picky, or challenge
the customer - but to understand them more deeply. They're looking at
the product and feeding ideas back to the customer because they've
spotted areas that need improvement.

Not being enthused by changes that make the product better, just
because they're "usability" related changes, seems so alien to this
mindset I'm really interested in finding out why this happens.

Cheers,

Adrian

On 2 Aug 2006, at 00:12, Jeff Patton wrote:
[snip]
> Business value � it�s tough to prove business value on lots of
> things � in particular improvements on user interactions.  Testing
> at least helps demonstrate it.

Yup. That is where I have the majority of my problems when wearing my
usability hat. Convincing the business owner of the value of the issues.

> William mentioned testing � but I find that lots of folks don�t
> know what we mean by testing.

Which "we" is that :-)

> There�s a big difference between testing that software is
> functionally correct and testing that users can effectively,
> efficiently use it.

Yes, but that's not to say that we can't use many of the same
techniques. I've been surprised about how many usability issues can
be embodied in automated tests to help keep everybody honest as
development continues.

> Finally Dave mentioned that the UI problem hasn�t been solved by
> agile techniques � which I agree with.

Just in case I've not been clear - I don't think the UI problem has
been solved by agile techniques either. Just that, in my experience,
agile teams are a lot better at dealing with usability issues than
non-agile teams. Things aren't perfect - just better.

>  But, low fidelity collaborative UI testing techniques work very
> well in an agile context.  I�ve already mentioned Gerrard once in
> this thread � but I�m going to again, because as it happens he
> wrote a paper that was presented at this years Agile2006 on adding
> usability testing to his Agile project.  Since it�s not available
> on the conference website, I put it here: http://
> www.abstractics.com/reference/Meszaros-AgileUsabilty.pdf
[snip]

Thanks. An interesting read.

Cheers,

Adrian

On 1 Aug 2006, at 16:58, Dave Churchville wrote:
[snip]
> I agree with this in principle, but in my own experience I've seen the
> development team actively resist usability changes with "Agile"
> justification, rather than passively recite time estimates.

I'd love to see a list of these "agile" justifications - just so I
can add to my list of "agile myths" :-)

> I suspect there's another factor here...with the rise of test-driven
> development and automated testing, perhaps features that aren't easy
> to test are not as well received?
[snip]

That's an interesting perspective. I know I get nervous around
features that I can't figure out how to write automated tests for.
Hopefully as we get better at figuring out how to write these sorts
of test this will be less of a problem.

That said, on my good days, an un-testable feature is a challenge
rather than a problem.

> I can't really explain this except that user interfaces are often
> emotional and reasonable people disagree on the "best" implementation.
>
> So unlike a business rule which is objective, UI changes are often
> scorned as "stupid" or "unnecessary".  This is what I call the "messy
> human stuff" that is an unavoidable part of the software process.

How do developers keep carry on thinking UI features are stupid" or
"unnecessary" in the face of:
* the customer, the person who understands the business issues,
saying that they're important
* feedback from users from the regular releases?
* usability test results?
* etc.

An agile development group that looks down at certain feature
requests from the customer sounds pretty bad, one that can do this
and ignore the feedback too...

Cheers,

Adrian

On 2 Aug 2006, at 09:47, PaulOldfield1@... wrote:
[snip]
> I'm beginning to suspect, from this thread, that basic
> requirements elicitation skills are in short supply.   Requirements
> gathering and analysis used to be a specialist set of skills.   If
> we're expecting our teams to gather the requirements directly
> from the customers, then the team should have theses skills.
[snip]

Yes, I agree completely. One of the things I like about XP is that
it's the team - rather than an individual analyst/architect - working
with the customer to help articulate stories.

This is one of the things that makes me slightly nervous when people
say that the obvious position for a usability person is being the
customers "one voice", because it cuts the rest of the team out of
the loop on all of those "whys".

> For example, we will often get a requirement phrased as a
> solution.  From our point of view, the solution is out of kilter
> with the rest of the design.  We may think the requirement is
> stupid as a result.  Yet there will be an underlying  requirement.
> We just need to ask why the customer wants what they asked
> for; what would this do for them.  Asking why is the easy bit;
> spotting the design masquerading as requirement is the bit
> that takes skill.
[snip]

I think this is one of the hidden benefits of having small stories.
By cutting features down into very small vertical slices you're
forced to burrow down to the core of the issue and ask lots of "whys".

Adrian

On 2 Aug 2006, at 17:20, Jeff Patton wrote:
[snip]
> Hearing the statement �design masquerading as a requirement� is
> interesting to me.  I believe the process of considering solutions
> to a problem and deciding on a best one /is/ design.  So, in my
> mind the product of design /is/ a requirement.  We simply start
> calling it a requirement when we don�t want it unraveled and to
> start delegating its execution to someone else.  So, all
> requirements are the result of design � they�re not masquerading.
> By calling it a requirement the person who called it that was
> telling you �I�ve done the design work, don�t question it� it�s a
> requirement.�  What I really hear in the statement �design
> masquerading as a requirement� is �I don�t like the design decision
> you made.  What was the problem you were trying to solve so I can
> validate your design or consider alternatives?�  Which I think is
> always a good question to ask � not just when making the choice to
> add a delight feature to a product � but all the way up the stack.
>
> Hope that all makes sense.

It does indeed :-)

Adrian