Orthodox View of Agile

[Amber-21]

> I see too many teams who lose the benefits of the agile process by >accepting almost any damn thing as a story.

>Ok, great, sure, you've got a very orthodox view of agile, and that's
>cool. I buy that. But the question I struggle with is this: where does
>design fit in? Do you write separate design stories? Is design part of
>a development story? Is a story acceptable if the functionality is
>there but its a poor UE? How do you measure "good" UE if UE can't be a
>story because its not software?

I understand the orthodox view of agile and the arguments for following the exact process, however at our company we have found that by writing stories and tasks for usability and IA work provides visibility into our processes to the rest of the Agile team.
Writing UX stories or tasks
--allows us to get one or two sprints ahead of the team.
--allows us to be looked at as part of the team. Being a part of the team helps developers understand and accept our recommendations.
--provides a way to track UX time and resources.
--provides a way to plan for future UX recommendations by creating 2-3 day development stories for unknown UX issues.

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 5:54 AM, jasarask8<amber_derosa@...> wrote:

>
>
>> I see too many teams who lose the benefits of the agile process by
>> >accepting almost any damn thing as a story.
>
>>Ok, great, sure, you've got a very orthodox view of agile, and that's
>>cool. I buy that. But the question I struggle with is this: where does
>>design fit in? Do you write separate design stories? Is design part of
>>a development story? Is a story acceptable if the functionality is
>>there but its a poor UE? How do you measure "good" UE if UE can't be a
>>story because its not software?
>
> I understand the orthodox view of agile and the arguments for following the
> exact process, however at our company we have found that by writing stories
> and tasks for usability and IA work provides visibility into our processes
> to the rest of the Agile team.

Do whatever you want and call it Agile. That's what the cool kids are doing.

> Writing UX stories or tasks
> --allows us to get one or two sprints ahead of the team.

Cool. I didn't realize that usability was a form of time travel.

> --allows us to be looked at as part of the team. Being a part of the team
> helps developers understand and accept our recommendations.

Interesting. Where I work you are a part of the team because you help
us implement stories.

> --provides a way to track UX time and resources.

You are here all iteration. Tracked.

> --provides a way to plan for future UX recommendations by creating 2-3 day
> development stories for unknown UX issues.
>

2-3 day story for unknown UX. That's a nice way to lie to your
customer. BTW, priority for that is after everything else the PO can
think of if he has any sense at all.

[jonathan berger]

>> [writing UX stories] provides a way to track UX time and resources.
> You are here all iteration. Tracked.

That's cute and flip and all, but there're two real problems you're
glossing over:

1) The importance of good UX is often undervalued and poorly
understood by the client. By not treating UX like real work which is
tracked and pointed, its not hard to see where they get that
impression from.

2) A great part of agile's appeal (for me at least) lies in embracing
a system that I don't have to think about that tracks effort and
progress and answers the question "what should I do next?" "You are
here all iteration. Tracked." is a little too coarse-grained to be
useful. Why can't designers have awesome velocity-tracking too?

On Tue, Sep 8, 2009 at 9:12 AM, Adam Sroka<adam.sroka@...> wrote:

>
>
> On Tue, Sep 8, 2009 at 5:54 AM, jasarask8<amber_derosa@...> wrote:
>>
>>
>>> I see too many teams who lose the benefits of the agile process by
>>> >accepting almost any damn thing as a story.
>>
>>>Ok, great, sure, you've got a very orthodox view of agile, and that's
>>>cool. I buy that. But the question I struggle with is this: where does
>>>design fit in? Do you write separate design stories? Is design part of
>>>a development story? Is a story acceptable if the functionality is
>>>there but its a poor UE? How do you measure "good" UE if UE can't be a
>>>story because its not software?
>>
>> I understand the orthodox view of agile and the arguments for following
>> the
>> exact process, however at our company we have found that by writing
>> stories
>> and tasks for usability and IA work provides visibility into our processes
>> to the rest of the Agile team.
>
> Do whatever you want and call it Agile. That's what the cool kids are doing.
>
>> Writing UX stories or tasks
>> --allows us to get one or two sprints ahead of the team.
>
> Cool. I didn't realize that usability was a form of time travel.
>
>> --allows us to be looked at as part of the team. Being a part of the team
>> helps developers understand and accept our recommendations.
>
> Interesting. Where I work you are a part of the team because you help
> us implement stories.
>
>> --provides a way to track UX time and resources.
>
> You are here all iteration. Tracked.
>
>> --provides a way to plan for future UX recommendations by creating 2-3 day
>> development stories for unknown UX issues.
>>
>
> 2-3 day story for unknown UX. That's a nice way to lie to your
> customer. BTW, priority for that is after everything else the PO can
> think of if he has any sense at all.
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private

[Adrian Howard]

Hi Adam,

On 8 Sep 2009, at 14:12, Adam Sroka wrote:

> On Tue, Sep 8, 2009 at 5:54 AM, jasarask8<amber_derosa@...>  
> wrote:
>>
>>
>>> I see too many teams who lose the benefits of the agile process by
>>>> accepting almost any damn thing as a story.
>>
>>> Ok, great, sure, you've got a very orthodox view of agile, and  
>>> that's
>>> cool. I buy that. But the question I struggle with is this: where  
>>> does
>>> design fit in? Do you write separate design stories? Is design  
>>> part of
>>> a development story? Is a story acceptable if the functionality is
>>> there but its a poor UE? How do you measure "good" UE if UE can't  
>>> be a
>>> story because its not software?
>>
>> I understand the orthodox view of agile and the arguments for  
>> following the
>> exact process, however at our company we have found that by writing  
>> stories
>> and tasks for usability and IA work provides visibility into our  
>> processes
>> to the rest of the Agile team.
>
> Do whatever you want and call it Agile. That's what the cool kids  
> are doing.

It seems to me that there was a problem. Since Amber (hoping that's  
the right name :-) said:

        "writing stories and tasks for usability and IA work
        provides visibility into our processes to the rest of
        the Agile team"

it sounds like there's been a problem - and writing explicit cards  
helped. Maybe exploring some of those issues might be productive and  
useful? It might let us find better solutions.

I'm guessing that the team wasn't understanding the need or time  
scales for some of the processes that the design team was performing  
to help define the stories that were coming into the development team.  
But I could be wrong. That's certainly a problem I've had when wearing  
my UX hat.

Amber - can you talk more about the problems you had that writing UX  
specific stories and tasks helped you with? We might be able to  
suggest some more effective solutions.

>> Writing UX stories or tasks
>> --allows us to get one or two sprints ahead of the team.
>
> Cool. I didn't realize that usability was a form of time travel.

Getting ahead of the team certainly shouldn't be the goal. Being able  
to ensure that the team get good and useful stories coming into the  
development process should be. At some level the Customer always has  
to be ahead of the team when producing stories - and UX folk are often  
heavily involved with that process.

I've mentioned previously that I'm uncertain that the N-1/N+1 pattern  
is a useful one for UX folk to adopt - but it certainly seems to be a  
common one that's working effectively for some people.

>> --allows us to be looked at as part of the team. Being a part of  
>> the team
>> helps developers understand and accept our recommendations.
>
> Interesting. Where I work you are a part of the team because you help
> us implement stories.

So the Customer is not part of the team when they're defining stories?

And again - Amber has said that doing this helped. So there's a  
problem there that writing cards fixed. I think that's worth exploring.

>> --provides a way to track UX time and resources.
>
> You are here all iteration. Tracked.

Eh? Words. More.

>> --provides a way to plan for future UX recommendations by creating  
>> 2-3 day
>> development stories for unknown UX issues.
>
> 2-3 day story for unknown UX. That's a nice way to lie to your
> customer. BTW, priority for that is after everything else the PO can
> think of if he has any sense at all.

As a developer I'm allowed to go "Dunno if this is going to work this  
way or that way or at all - we're going to spend $timebox trying to  
figure it out". Spikes. Lovely things.

Shouldn't we let Customer/UX folk do them?

Just pondering.

Cheers,

Adrian

--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 6:57 AM, jonathan
berger<jonathanpberger@...> wrote:

>
>
>>> [writing UX stories] provides a way to track UX time and resources.
>
>> You are here all iteration. Tracked.
>
> That's cute and flip and all, but there're two real problems you're
> glossing over:
>
> 1) The importance of good UX is often undervalued and poorly
> understood by the client. By not treating UX like real work which is
> tracked and pointed, its not hard to see where they get that
> impression from.
>
> 2) A great part of agile's appeal (for me at least) lies in embracing
> a system that I don't have to think about that tracks effort and
> progress and answers the question "what should I do next?" "You are
> here all iteration. Tracked." is a little too coarse-grained to be
> useful. Why can't designers have awesome velocity-tracking too?
>

Velocity shouldn't be about ego. We, as a team, get something done and
it's done. Nobody owns that.

Customers appreciate working software more than anything else. If you
can give them something that works and doesn't suck they will
appreciate that without necessarily appreciating everything that goes
into it, and that is fine. Usability is a part of that, and if they
don't realize that it's not that much of a tragedy (They don't
appreciate all of my OO refactoredness either, but I still sleep
fine.)

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 7:13 AM, Adrian Howard<adrianh@...> wrote:

>
>
> Hi Adam,
>
> On 8 Sep 2009, at 14:12, Adam Sroka wrote:
>
>> On Tue, Sep 8, 2009 at 5:54 AM, jasarask8<amber_derosa@...>
>> wrote:
>>>
>>> --provides a way to plan for future UX recommendations by creating
>>> 2-3 day
>>> development stories for unknown UX issues.
>>
>> 2-3 day story for unknown UX. That's a nice way to lie to your
>> customer. BTW, priority for that is after everything else the PO can
>> think of if he has any sense at all.
>
> As a developer I'm allowed to go "Dunno if this is going to work this
> way or that way or at all - we're going to spend $timebox trying to
> figure it out". Spikes. Lovely things.
>
> Shouldn't we let Customer/UX folk do them?
>

Spikes aren't supposed to be about letting the devs play. The customer
asks for something (i.e. the story.) We say, "We don't know how, but
give us some time." If we don't know how to make it usable then that
is what we spike on, but I strongly suspect that this isn't what OP
was suggesting.

[jonathan berger]

Velocity's not about ego. It's about "What can I get done this week?
What are the proper expectations to set for the client and the
stakeholders and the rest of the team?"



On Tue, Sep 8, 2009 at 10:15 AM, Adam Sroka<adam.sroka@...> wrote:

>
>
> On Tue, Sep 8, 2009 at 6:57 AM, jonathan
> berger<jonathanpberger@...> wrote:
>>
>>
>>>> [writing UX stories] provides a way to track UX time and resources.
>>
>>> You are here all iteration. Tracked.
>>
>> That's cute and flip and all, but there're two real problems you're
>> glossing over:
>>
>> 1) The importance of good UX is often undervalued and poorly
>> understood by the client. By not treating UX like real work which is
>> tracked and pointed, its not hard to see where they get that
>> impression from.
>>
>> 2) A great part of agile's appeal (for me at least) lies in embracing
>> a system that I don't have to think about that tracks effort and
>> progress and answers the question "what should I do next?" "You are
>> here all iteration. Tracked." is a little too coarse-grained to be
>> useful. Why can't designers have awesome velocity-tracking too?
>>
>
> Velocity shouldn't be about ego. We, as a team, get something done and
> it's done. Nobody owns that.
>
> Customers appreciate working software more than anything else. If you
> can give them something that works and doesn't suck they will
> appreciate that without necessarily appreciating everything that goes
> into it, and that is fine. Usability is a part of that, and if they
> don't realize that it's not that much of a tragedy (They don't
> appreciate all of my OO refactoredness either, but I still sleep
> fine.)
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private

[Adrian Howard]

On 8 Sep 2009, at 15:22, Adam Sroka wrote:

> Spikes aren't supposed to be about letting the devs play.

I don't see anybody suggesting this.

> The customer
> asks for something (i.e. the story.) We say, "We don't know how, but
> give us some time." If we don't know how to make it usable then that
> is what we spike on, but I strongly suspect that this isn't what OP
> was suggesting.

I strongly suspect it was. Maybe I'm wrong. Maybe we should ask?

Even if it wasn't directly related to a stories implementation in the  
current iteration it doesn't mean that it's necessarily wasted or  
unimportant work.

For example answering the question "Should we do X at all?" is  
massively important. Often a good UX person can answer that much more  
quickly with a paper prototype than actually building X.

Should we not schedule those things?

Adrian

--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Ron Jeffries-3]

Hello, jonathan.  On Tuesday, September 8, 2009, at 9:57:14 AM,
you wrote:

> 1) The importance of good UX is often undervalued and poorly
> understood by the client. By not treating UX like real work which is
> tracked and pointed, its not hard to see where they get that
> impression from.

It /is/ work. It is not /software/. One of the most pernicious
problems in teams adopting agile is not to focus on done software.
Accordingly, it is good to insist that the only stories on a
software project represent software.

UX is not software. I'm sure you bust your ass at it and all that
but it doesn't bear fruit until it is in the code. Similarly,
exploratory testing, architecture, and a host of other important
activities are not software. They all have to be done, and done
well, and in agile software development they all need to be folded
into the software in order to be considered done.

> 2) A great part of agile's appeal (for me at least) lies in embracing
> a system that I don't have to think about that tracks effort and
> progress and answers the question "what should I do next?" "You are
> here all iteration. Tracked." is a little too coarse-grained to be
> useful. Why can't designers have awesome velocity-tracking too?

You can. My advice is that you add columns to the left (and right if
you need them) of the actual software development columns, and put
your cards there. Just recognize that there is a very different kind
of "done" represented there and that all the wireframes in the world
aren't the same as having running tested code.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I know we always like to say it'll be easier to do it now than it
will be to do it later. Not likely. I plan to be smarter later than
I am now, so I think it'll be just as easy later, maybe even easier.
Why pay now when we can pay later?

[Ron Jeffries-3]

Hello, jasarask8.  On Tuesday, September 8, 2009, at 8:54:27 AM,
you wrote:

> I understand the orthodox view of agile and the arguments for
> following the exact process, however at our company we have found
> that by writing stories and tasks for usability and IA work
> provides visibility into our processes to the rest of the Agile team.

Yes, it will do that. However, what I would consider to be "best
current practice" would completely obviate the need for special
visibility into your processes.

> Writing UX stories or tasks

I recommend having all UX tasks done in-Sprint. Failing that, I
recommend considering them to be overhead work done in the
product owner's office.

> --allows us to get one or two sprints ahead of the team.

Work ahead of the team is what Lean calls "Work In Process". Work In
Process is uniformly considered waste and one tries to eliminate it.

If UX is two sprints ahead of the team, then the proper accounting
for stories is that the fastest possible story is three sprints
long. That's a long damn time, and this waste is solely caused by
trying to get ahead.

> --allows us to be looked at as part of the team. Being a part of
> the team helps developers understand and accept our recommendations.

Being with the team and working with them in real time, instead of
"one or two sprints ahead" would be a better way to become part of
the team in my opinion.

> --provides a way to track UX time and resources.

That's moderately useful. What is more important in these processes
is cycle time, not time and resource allocation.

> --provides a way to plan for future UX recommendations by
> creating 2-3 day development stories for unknown UX issues.

Like at least one other poster, I do not understand this idea at
all.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting.  --Millard Fuller

[Scott Preece-2]

Hi, Ron,

>From: Ron Jeffries <ronjeffries@...>

>Hello, jasarask8.  On Tuesday, September 8, 2009, at 8:54:27 AM,
>>you wrote:
>
>>I recommend having all UX tasks done in-Sprint. Failing that, I
>>recommend considering them to be overhead work done in the
>>product owner's office.

Well, you'd typically be doing them with end users and doing multiple iterations, so "in the PS's office" probably doesn't work, but it's probably fair to consider them as overhead in the same sense that work replaced as a result of negative customer feedback is overhead. I do tend to think of at least some of this as on the PS side rather than the development side.

>
>>> --allows us to get one or two sprints ahead of the team.
>
>>Work ahead of the team is what Lean calls "Work In Process". Work In
>>Process is uniformly considered waste and one tries to eliminate it.

I don't think it's "work in process" in the usual sense, and I think "waste" has a pejorative connotation that is misleading, but I agree it's not value-add. I think the point is that doing UX iterations is reducing the total waste in the project by avoiding wasted code development effort. Any agile iterative process is going to have waste; waste is how you learn what you need to deliver. The point to UX methods is that they're cheaper to iterate on than code.

>
>>If UX is two sprints ahead of the team, then the proper accounting
>>for stories is that the fastest possible story is three sprints
>>long. That's a long damn time, and this waste is solely caused by
>>trying to get ahead.

Yes, but if you assume there is some average number of iterations required to get things right, the expected time per story is always going to be longer than one sprint and, in an area like UX, where getting it right often takes several iterations, it's probably going to be longer than two stories, anyway. Doing the lead work as UX iterations typically involves fewer people than will be involved in the coding.

>
>>> --allows us to be looked at as part of the team. Being a part of
>>> the team helps developers understand and accept our recommendations.
>
>>Being with the team and working with them in real time, instead of
>>"one or two sprints ahead" would be a better way to become part of
>>the team in my opinion.

I do think UX people should be part of the team during development, but for products there's often a holistic aspect to the UX that doesn't thrive if you start from the bottom up - you want the UX to be consistent across different parts of the product.

I don't think there's any surprise here - this all comes under the notion of "enough" up-front modeling. If you're doing customer-facing UX, and especially if you're doing a consumer product whose development has to be sold to business management and downstream channels, "enough" may be substantial.

>>> --provides a way to plan for future UX recommendations by
>>> creating 2-3 day development stories for unknown UX issues.
>
>>Like at least one other poster, I do not understand this idea at
>>all.

I also don't know exactly what the OP meant by this. My guess is it's getting at reminding the client that things will be discovered late and will involve development time, which suggests a more formal planning process than agile recommends.

regards,
scott

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 9:00 AM, Scott Preece<sepreece@...> wrote:

>
>
> Hi, Ron,
>
>>From: Ron Jeffries <ronjeffries@...>
>
>>Hello, jasarask8. On Tuesday, September 8, 2009, at 8:54:27 AM,
>>>you wrote:
>>
>>>I recommend having all UX tasks done in-Sprint. Failing that, I
>>>recommend considering them to be overhead work done in the
>>>product owner's office.
>
> Well, you'd typically be doing them with end users and doing multiple
> iterations, so "in the PS's office" probably doesn't work, but it's probably
> fair to consider them as overhead in the same sense that work replaced as a
> result of negative customer feedback is overhead. I do tend to think of at
> least some of this as on the PS side rather than the development side.
>

I think you missed a part of the point. "Work replaced as a result of
negative customer feedback" is *not* overhead, precisely because it is
working software.

>>
>>>> --allows us to get one or two sprints ahead of the team.
>>
>>>Work ahead of the team is what Lean calls "Work In Process". Work In
>>>Process is uniformly considered waste and one tries to eliminate it.
>
> I don't think it's "work in process" in the usual sense, and I think "waste"
> has a pejorative connotation that is misleading, but I agree it's not
> value-add. I think the point is that doing UX iterations is reducing the
> total waste in the project by avoiding wasted code development effort. Any
> agile iterative process is going to have waste; waste is how you learn what
> you need to deliver. The point to UX methods is that they're cheaper to
> iterate on than code.
>

I think you might want to read up on Lean to understand what Ron is
saying here. Both "Work In Process" and "Waste" have precise meanings
there, and it is in that context that Ron is using them.

The very notion that some amount of design effort can serve to "avoid
wasted code development effort," is, IMO, fallacious. This is
precisely the idea that Agile is meant to challenge, and, if you truly
believe it, it might be worthwhile to consider a different method -
one which is designed to accommodate and account for such up-front
design efforts.

>>
>>>If UX is two sprints ahead of the team, then the proper accounting
>>>for stories is that the fastest possible story is three sprints
>>>long. That's a long damn time, and this waste is solely caused by
>>>trying to get ahead.
>
> Yes, but if you assume there is some average number of iterations required
> to get things right, the expected time per story is always going to be
> longer than one sprint and, in an area like UX, where getting it right often
> takes several iterations, it's probably going to be longer than two stories,
> anyway. Doing the lead work as UX iterations typically involves fewer people
> than will be involved in the coding.
>

I'm not sure that I follow your math, but I would suggest that
"getting it right" the first time around is not necessarily what Agile
teams intend to do. More like get it working and then get feedback
while there is still time to change.

>>
>>>> --allows us to be looked at as part of the team. Being a part of
>>>> the team helps developers understand and accept our recommendations.
>>
>>>Being with the team and working with them in real time, instead of
>>>"one or two sprints ahead" would be a better way to become part of
>>>the team in my opinion.
>
> I do think UX people should be part of the team during development, but for
> products there's often a holistic aspect to the UX that doesn't thrive if
> you start from the bottom up - you want the UX to be consistent across
> different parts of the product.
>

I'm not clear how being involved or "starting from the bottom up"
precludes consistent design. Seems to me that consistency is a quality
that can evolve alongside everything else.

> I don't think there's any surprise here - this all comes under the notion of
> "enough" up-front modeling. If you're doing customer-facing UX, and
> especially if you're doing a consumer product whose development has to be
> sold to business management and downstream channels, "enough" may be
> substantial.
>

I don't see how that follows at all. Business management, like
everyone else, is primarily interested in working software. I have
never seen them offended to be shown just such. They are more likely
to be offended if you show them a design and then produce a product
that is somehow different. Therefore, up-front design only serves to
limit your options later rather than add any value (Because the value
is in the working software. Stop me if I'm repeating myself :-)

>>>> --provides a way to plan for future UX recommendations by
>>>> creating 2-3 day development stories for unknown UX issues.
>>
>>>Like at least one other poster, I do not understand this idea at
>>>all.
>
> I also don't know exactly what the OP meant by this. My guess is it's
> getting at reminding the client that things will be discovered late and will
> involve development time, which suggests a more formal planning process than
> agile recommends.
>

It sounded to me like, "We need some time to do magic UX stuff, and we
want a story for that, but we aren't going to tell you what it means."
Huge red flag. Not the slightest bit Agile.

[William Pietri]

Hi!  Thanks for asking an interesting question. Let me ask a couple back:

jasarask8 wrote:
> I understand the orthodox view of agile and the arguments for following the exact process, however at our company we have found that by writing stories and tasks for usability and IA work provides visibility into our processes to the rest of the Agile team.
>  

To me, the desire for artificially making your work visible is a sign
that you are not working as closely with the rest of the team as is
optimal. Could you say more about your situation? For example, could you
tell me:

    * the length of your iterations,
    * how often the software is released,
    * how close physically you sit to the developers, and
    * how much time you spend each week working side by side with
      developers?


Maybe that will let us suggest some changes that would work better than
the approach you're using.

> --provides a way to plan for future UX recommendations by creating 2-3 day development stories for unknown UX issues.
>  

You mean that you have developers build things so that you can test them
out? If so, I'd consider that just another story.


William

[William Pietri]

William Pietri wrote:
> [...] Could you say more about your situation? [...]

Oops! Sorry, jasarask8, I just saw that you answered most of that in
another thread.

It sounds like you've found something that works in your situation,
which is great, and indeed, not calling it "Agile" will make some people
more comfortable. At the point when you want to kick things up a notch,
though, the approaches Adam and others talk about may be of benefit to you.

William

[William Pietri]

jonathan berger wrote:

> 1) The importance of good UX is often undervalued and poorly
> understood by the client. By not treating UX like real work which is
> tracked and pointed, its not hard to see where they get that
> impression from.
>
> 2) A great part of agile's appeal (for me at least) lies in embracing
> a system that I don't have to think about that tracks effort and
> progress and answers the question "what should I do next?" "You are
> here all iteration. Tracked." is a little too coarse-grained to be
> useful. Why can't designers have awesome velocity-tracking too?
>  

In my view, velocity includes all sorts of things. Coding. Database
work. CSS cleanup. Product management discussions. User research.
Performance optimization. Refactoring tests. Taking needed breaks. Doing
retrospectives. Building team rapport. And a zillion other things.
Including the various facets of UX work.

We could track all of those separately, because they're all important.
Or we could roll them all up into one number, where we only count the
things we are ready to ship. Personally, I prefer the latter. But I'm
not seeing the logic for separating out one or a few of those things and
tracking them separately, unless there's some particular problem we're
trying to investigate.


As to clients undervaluing things, that's a problem with almost any
specialty. If I wanted them to appreciate something in particular, I
wouldn't use a metric that highlight the cost side of things, which is
what work tracking does. Instead, I'd go with metrics that demonstrate
delivered value.

William

[Ron Jeffries-3]

Hello, Adam.  On Tuesday, September 8, 2009, at 12:28:20 PM, you
wrote:

> The very notion that some amount of design effort can serve to "avoid
> wasted code development effort," is, IMO, fallacious. This is
> precisely the idea that Agile is meant to challenge, and, if you truly
> believe it, it might be worthwhile to consider a different method -
> one which is designed to accommodate and account for such up-front
> design efforts.

I don't agree here. Clearly some amount of up front thinking about
anything can reduce rework. And rework is always bad, some amount of
thinking is of value. We just need to recognize that all that work
is just Work In Process until it shows up in the software. (I'm not
sure what the status ought to be of a sketch that we throw away.
Formally it is of course waste, but mostly we don't know how to get
rid of it.)

What is not bad is refinement. So building to a simple UI, then
enhancing the UI can be a reasonable way to go.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Steering is more important than speed,
in driving and in software development.

[Jeremy Kriegel]

For those advocating that UX work be done in the sprint, how long are your
sprints?
The teams I work with now use 4 week sprints, which, while a bit long for my
taste, does afford more opportunity to do UX once stories are committed to
and avoid unused design work. However, at my last employer, the 2 week
sprints did not allow for much exploration.

As far as the utility of design work, I think there is a spectrum with
working code on one side and the various forms of non-code design artifacts
(wireframes, paper, whiteboard, etc) on the other. At the end of the day, as
it has been said, value has to be received via working code. However,
different scenarios seem to benefit from switching from design to code at
different points in that spectrum and it changes by developer, designer,
feature, etc., even within the same sprint or story.

There are two different ways I think about how much design work a given
feature needs. First, I like to think about my level of confidence in my
assumptions and the cost of being wrong. The more I think I (and the team)
know about what we're building and who we're building for, and the less risk
there is to releasing something of poor quality that is rejected, the
lighter the design. The less I know, and the more risk to being 'wrong',
then I advocate for 'heavier' design. One element of risk is how soon I will
be able to revise the design. In a nimble start-up that releases changes to
its web app every 2 weeks, the risk is lower than in a corporate environment
with releases every 3-6 months.

Another dimension I consider is complexity. The less complex, the less
design. The more complex, the more design thinking seems to be required.
This is more of a simplification of the first lens as the more complex a
given story, the greater the likelihood that I don't know as much as I think
I do and the risk of failure is higher.

This has been at the forefront of my brain for a while, and will hopefully
be extrapolated soon as a proper post.

-jeremy kriegel
www.methodsansmadness.com


"Be well, do good work & keep in touch."
    - Garrison Keillor


On Tue, Sep 8, 2009 at 2:41 PM, Ron Jeffries <ronjeffries@...> wrote:

>
>
> Hello, Adam. On Tuesday, September 8, 2009, at 12:28:20 PM, you
> wrote:
>
>
> > The very notion that some amount of design effort can serve to "avoid
> > wasted code development effort," is, IMO, fallacious. This is
> > precisely the idea that Agile is meant to challenge, and, if you truly
> > believe it, it might be worthwhile to consider a different method -
> > one which is designed to accommodate and account for such up-front
> > design efforts.
>
> I don't agree here. Clearly some amount of up front thinking about
> anything can reduce rework. And rework is always bad, some amount of
> thinking is of value. We just need to recognize that all that work
> is just Work In Process until it shows up in the software. (I'm not
> sure what the status ought to be of a sketch that we throw away.
> Formally it is of course waste, but mostly we don't know how to get
> rid of it.)
>
> What is not bad is refinement. So building to a simple UI, then
> enhancing the UI can be a reasonable way to go.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Steering is more important than speed,
> in driving and in software development.
>
>  
>

[Scott Preece-2]

Hi, Adam,

>From: Adam Sroka <adam.sroka@...>
>  
>On Tue, Sep 8, 2009 at 9:00 AM, Scott Preece<sepreece@yahoo. com> wrote:
>>>
>>>
>>> Hi, Ron,
>>>
>>>>From: Ron Jeffries <ronjeffries@ acm.org>
>>>
>>> iterations, so "in the PS's office" probably doesn't work, but it's probably
>>> fair to consider them as overhead in the same sense that work replaced as a
>>> result of negative customer feedback is overhead. I do tend to think of at
>>> least some of this as on the PS side rather than the development side.
>>>
>
>>I think you missed a part of the point. "Work replaced as a result of
>>negative customer feedback" is *not* overhead, precisely because it is
>>working software.

Code that is written, reviewed by the customer, and subsequently replaced based on the customer's feedback has to be counted as waste (overhead), because it isn't part of what's delivered. We may be taking "working" differently. To me, an iteration may provide to the customer code that is "working" in the sense that it implements the story but ends up being rejected as unshippable. The code that has to be replaced is waste.

>>> I don't think it's "work in process" in the usual sense, and I think "waste"
>>> has a pejorative connotation that is misleading, but I agree it's not
>>> value-add. I think the point is that doing UX iterations is reducing the
>>> total waste in the project by avoiding wasted code development effort. Any
>>> agile iterative process is going to have waste; waste is how you learn what
>>> you need to deliver. The point to UX methods is that they're cheaper to
>>> iterate on than code.
>>>
>
>>I think you might want to read up on Lean to understand what Ron is
>>saying here. Both "Work In Process" and "Waste" have precise meanings
>>there, and it is in that context that Ron is using them.

I apologize if I'm misunderstanding the terms work in process and
waste. There's always some danger in trying to apply manufacturing
analogies to the design process (I think we all generally agree that
software development is a design process, not manufacturing).

>>The very notion that some amount of design effort can serve to "avoid
>>wasted code development effort," is, IMO, fallacious. This is
>>precisely the idea that Agile is meant to challenge, and, if you truly
>>believe it, it might be worthwhile to consider a different method -
>>one which is designed to accommodate and account for such up-front
>>design efforts.

I think it's undeniable that sometimes up-front design can avoid downstream waste. In this case, I'm saying that if it takes, say, three iterations of user testing successive versions of the UX, then it involves LESS waste to do those iterations on lightweight mockups than to have people code those three approaches and then throw two of them away, along with whatever tests went with them and whatever user-facing documentation had to be delivered with them.

Note that it's only the UX I'm talking about here; my experience with  backend code is that it more likely to be "mostly OK" than the first iterations of UX designs.

>>> Yes, but if you assume there is some average number of iterations required
>>> to get things right, the expected time per story is always going to be
>>> longer than one sprint and, in an area like UX, where getting it right often
>>> takes several iterations, it's probably going to be longer than two stories,
>>> anyway. Doing the lead work as UX iterations typically involves fewer people
>>> than will be involved in the coding.
>>>
>
>>I'm not sure that I follow your math, but I would suggest that
>>"getting it right" the first time around is not necessarily what Agile
>>teams intend to do. More like get it working and then get feedback
>>while there is still time to change.

Well, that's exactly my point. If you deliver the code to get feedback, then rework and deliver an updated version in the next sprint, get more feedback, then rework and deliver again, you're right back at three sprints before it's delivered (and you've spent a lot more person-hours). If you've got a good UX process, you may be able to get the interaction aspects right before the first feedback cycle, because you've already had multiple feedback cycles while you were designing it.

In our experience, we often reworked interactions completely, to give the user a different abstraction to work with, after the first iteration and sometimes for several iterations. If those had been code iterations, not just presentation layer, but major chunks of backend would have been thrown away, because the corresponding model wasn't there anymore.

>
>>> I don't think there's any surprise here - this all comes under the notion of
>>> "enough" up-front modeling. If you're doing customer-facing UX, and
>>> especially if you're doing a consumer product whose development has to be
>>> sold to business management and downstream channels, "enough" may be
>>> substantial.
>
>>I don't see how that follows at all. Business management, like
>>everyone else, is primarily interested in working software. I have
>>never seen them offended to be shown just such. They are more likely
>>to be offended if you show them a design and then produce a product
>>that is somehow different. Therefore, up-front design only serves to
>>limit your options later rather than add any value (Because the value
>>is in the working software. Stop me if I'm repeating myself :-)

In my background, management was interested in having shippable products by the date they were promised to distribution channels. They wanted to see intermediate versions as evidence that progress was being made, but the channels' signoff on the UX design was major progress, too - a sign that "if we build it like this, they will take N million units". That kind of upfront review was needed to justify the cost of committing to the project (which typically involved custom hardware and ASICs that needed to be scheduled into supplier fabs).

regards,
scott

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 11:41 AM, Ron Jeffries<ronjeffries@...> wrote:

>
>
> Hello, Adam. On Tuesday, September 8, 2009, at 12:28:20 PM, you
> wrote:
>
>> The very notion that some amount of design effort can serve to "avoid
>> wasted code development effort," is, IMO, fallacious. This is
>> precisely the idea that Agile is meant to challenge, and, if you truly
>> believe it, it might be worthwhile to consider a different method -
>> one which is designed to accommodate and account for such up-front
>> design efforts.
>
> I don't agree here. Clearly some amount of up front thinking about
> anything can reduce rework. And rework is always bad, some amount of
> thinking is of value. We just need to recognize that all that work
> is just Work In Process until it shows up in the software. (I'm not
> sure what the status ought to be of a sketch that we throw away.
> Formally it is of course waste, but mostly we don't know how to get
> rid of it.)
>
> What is not bad is refinement. So building to a simple UI, then
> enhancing the UI can be a reasonable way to go.
>

I could just be picking nits. To me, thinking about it is not
necessarily a separate activity from doing it. If spending more time
thinking about it before doing it were likely to reduce the number of
iterations after I start doing it, then I would want to do that. In my
experience, and in my opinion, it does not.

[Ron Jeffries-3]

Hello, Scott.  On Tuesday, September 8, 2009, at 12:00:58 PM, you
wrote:

>>>Work ahead of the team is what Lean calls "Work In Process". Work In
>>>Process is uniformly considered waste and one tries to eliminate it.

> I don't think it's "work in process" in the usual sense, and I
> think "waste" has a pejorative connotation that is misleading, but
> I agree it's not value-add. I think the point is that doing UX
> iterations is reducing the total waste in the project by avoiding
> wasted code development effort. Any agile iterative process is
> going to have waste; waste is how you learn what you need to
> deliver. The point to UX methods is that they're cheaper to iterate on than code.

As far as I can tell, according to Lean people including Mary
Poppendieck, anything that is in the pipeline at all, even a story
card, is Work In Process and is nominally waste.

Waste has a pejorative meaning for a purpose, namely to remind us
/always/ that we would like to get rid of it.

I fully agree that UX methods can appear to be cheaper to iterate on
than code. They have drawbacks as well as advantages, in clarity, in
certainty that they are practical to implement, and in fidelity. It
is not all one-sided.

My experience with this kind of software development tells me that
when a story is spread over multiple iterations, that is bad.
Pretending that it is really two or three stories doesn't change the
badness. It's the extended time dependency

  UXA1 -> UXA2 -> ... -> UXAcode

that is biting us. If the code can be brought forward, or the UX
deferred, so that we get

  UXA1code1, UXA2code2, UXA3code3

we break the dependency between the stories and increase the rate of
delivery of the only thing we absolutely cannot do without, the
program.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
To Fly, Flip Away Backhanded -- Master Frisbee