Question_Agile Process_ UIE Virtual Seminar

[Robert Biddle-2]

Um, I was in agreement about UI designers working collaboratively with
programmers. But now I'm getting concerned about some ideas that seem
too simplistic. Some of us have argued these points on this mailing
list before. But just to identify these issues, from my point of view:

* I do not think there is any one accepted way to link UI design and
agile software development. People are doing different things and we
need reports of experience on how things turn out.

* Although we can regard UI researchers and UI designers as part of
the team, we should also recognize they may also be part of the
customer. In particular, they may specify stories. Also, while they
are the programmers will be working on the same product, it does not
mean that have to be working on the same stories in the same
iteration: see for example Lynn Miller's interleaved iterations,
where the programmers work on one set of stories while the UI people
design the next set and test the last set.

* In UI work it is generally accepted that one cannot simply ask users
what they want, deliver it, and expect things to work well. Users
are often too close to the action, and although they may experience
problems and desires, they cannot necessarily articulate
solutions. In these cases observation, ethnography, and exploring
several varying prototypes can help.

* Similarly, in UI work it is generally accepted that low-fidelity
prototypes can often elicit better feedback than high-fidelity
prototypes or fully working software. Basically, it seems that
things being too "finished" seems to act an inhibitor on
articulation of important potential improvements.

* Although it makes sense to design on the basis of user research and
careful modeling, it still seems that usability testing is
essential, because humans are complex choatic systems, and sometimes
things that seem destined to be fine turn out to be wrong. And it
is not possible to "test first".

* Although it makes sense for UI designers and programmers to
co-locate and collaborate, it also makes sense for UI designers to
spend lots of time with users, and they may be far away. Co-location
is powerful, but we have to face that we cannot co-locate with
everyone all the time.

I accept that others may have different views, but I think all the
views above are sufficiently common that they should not just be swept
away by an unusual destiny in the blue sea of August.

Ahh, August.
Or perhaps February. Your hemisphere may vary. Mine has.

Robt




Mike Dwyer wrote:

>
> First why is it that the people would not stay in the same place?
>
> Second how often have you seen this happen. You desing a UI and the
> user love it, the developers provide code and full fuinctionality and
> the users tell you they have not gotten what they wanted?
>
> Finally if you are getting feedback and taking the time to do a new
> design before getting the developers involved, how long does it take
> the users to tell you that it isn’t quite what they wanted?
>
> B y you working directly with the developers and the users everyone -
> including the users get to see the procud as it is developed. If you
> start with the very basics of what the users want they will change
> their minds, but that is OK because much of what they now want will be
> based on what they have working. Thiis way the usersw are being guided
> by the product as it is finished and they will focus on what they need
> and not what they think will be cool. You end up with a product
> working that always meets the current needs of the user and continues
> to be refined to better meet the users needs.
>
> *Mike Dwyer *
> /Principal, Agile Coach/
>
> *BigVisible Solutions*
> url: http://www.bigvisib le.com <http://www.bigvisible.com/>
>
> cell: [phone]
>
> email: mdwyer@bigvisible. com <mailto:asingh@...>
>
> *From:* Srinivas Manda [mailto:laksinu@ laksinu.com]
> *Sent:* Tuesday, March 10, 2009 5:22 PM
> *To:* agile-usability@ yahoogroups. com
> *Subject:* [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
>
> Mike, we as a team are still trying to understand Agile, and we are
> working based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place
> and work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features
> and as a UX designer I should design the feature and get that
> validated with users and get a feedback from them .. But if we follow
> agile then the dev team should be boiling the code before I get the
> results ...if they do coding and if I get feedback from the users to
> change some design then should the dev need to recode it ?
>
> Please comment on this
>
> --- In agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>, "Mike Dwyer" <mdwyer@...>
> wrote:
> >
> > WHOA! Look dude, Ron was being very nice. We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged. You may have been an UI or UX Prima Donna in the
> > conventional world but in the Agile sphere, you are a member of a
> team, each
> > of whom brings their own unique skills that you, in all likelihood
> lack as
> > you have chosen to be a UI wizard. Here is the secret message inside the
> > Agile bottle. Users don't buy software, or UI or databases or any of the
> > stuff we love to work with. Users buy value and it is our combined
> job to
> > work with the users to make sure we are all on the same page.
> >
> >
> >
> > So if you are going to be Agile, understand this. Your skills are no
> more
> > or less valuable than the most junior newbie tester or coder or BA.
> It is
> > the sum impact of the team that delivers.
> >
> >
> >
> > If this bothers you or you think that your world is an exception, please
> > look up the word Scrumbutt or Cragile and start using it to refer to
> what
> > you do.
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisib le.com <http://www.bigvisible.com>
> <http://www.bigvisib le.com/ <http://www.bigvisible.com/>>
> >
> > cell: [phone]
> >
> > email: mdwyer@... <mailto:asingh@ ...>
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@ ...]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
> >
> >
> >
> > Thanks everyone for your input... will make it as a mandit to include
> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>
> > <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries
> <ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers /
> Designers to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and designer,
> BA's are
> > > > working at the same time and if the screen design is done ... and we
> > > > test the design with the USERS ... it is not really possible to get
> > > > feedback from the USERS in 2 weeks or so.. by the time we get the
> > > > feedback from USERS developers are done with there coding ...
> and if we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming. com
> > > www.xprogramming. com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonx p.com/index. php?option= com_eventlist
> <http://hendricksonxp.com/index.php?option=com_eventlist>
> > <http://hendricksonx p.com/index. php?option=
> com_eventlist&Itemid=28
> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make fire.
> > > He was probably burned at the stake he had taught his brothers to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/agile-usability/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/agile-usability/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:agile-usability-digest@...
    mailto:agile-usability-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    agile-usability-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[William Pietri]

Srinivas Manda wrote:
> Mike, we as a team are still trying to understand Agile, and we are working based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place and work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>  

Well, I'm not sure Agile says anything on its own, but if we take Scrum
or Extreme Programming, they certainly say that the product side of the
house needs to know enough about a story once development starts that
they can answer all the questions developers might have. That means they
tend to work ahead of development some.

In my view, "design" straddles the product management / development
divide. Consider Jesse James Garrett's "Elements of User Experience":

http://www.jjg.net/elements/pdf/elements.pdf

The topic of user needs and site objectives and functional specs are,
from the Agile perspective, clearly part of the product manager's world,
although it's an area some designers see as theirs, too. At the other
end, the skin of an app is executed by developers, with the involvement
of designers varying from place to place. In between,
the interaction design, the information design, the interface design,
and the visual design all sound a lot like things designers do.


So in practice, I'd say that the more high-level any given design
activity, the more likely it is to take place outside of the iteration
framework. The right balance varies from shop to shop, but you should
seek out the minimum amount of up-front design work that allows stories
to complete smoothly.

If you want more info, Amanda Willoughby  and I did a talk on this very
topic. We went around to a number of places (including Google and
YouTube) and took a look at how they actually do design in an agile way.
Our talk is about what we saw, and what we think works well.  It's
called "Meshing Gears" and you can find it here:

http://pivotallabs.com/talks

The downloadable video and MP3 are here:

http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mov
http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mp3

William

[Adam Sroka-3]

On Tue, Mar 10, 2009 at 6:04 PM, William Pietri <william@...> wrote:

> Srinivas Manda wrote:
>> Mike, we as a team are still trying to understand Agile, and we are
>> working based on how easy it is for us that suites our working model.
>>
>> Agile says that we (designer, dev, testing etc) should be at one place and
>> work on stories that team buys for that iteration
>>
>> But in realistic how can that happen?
>>
>
> Well, I'm not sure Agile says anything on its own, but if we take Scrum
> or Extreme Programming, they certainly say that the product side of the
> house needs to know enough about a story once development starts that
> they can answer all the questions developers might have. That means they
> tend to work ahead of development some.
>

I'm not sure that follows. As Ron Jeffries has said, stories are
"placeholders for a conversation." It isn't necessary that the
business "know enough ... to answer all the questions." Rather, it is
sufficient that they know enough to consider the story a priority and
are prepared to engage in conversation to determine what needs to be
done. It is also common for the definition of a story to be loose
enough that our shared understanding of it will change significantly
over time.

In practice this really depends on the customer. Some stories will
call for considerable research on the business side, and the business
may have a very good idea of what they want before they ask for the
story. Other stories will fall into a gap between existing
understanding and the need to create a functional whole. These stories
will necessarily be "fuzzy" and evolve over time. The practice in
Agile is to accept such uncertainty as necessary and productive.

> In my view, "design" straddles the product management / development
> divide. Consider Jesse James Garrett's "Elements of User Experience":
>
> http://www.jjg.net/elements/pdf/elements.pdf
>
> The topic of user needs and site objectives and functional specs are,
> from the Agile perspective, clearly part of the product manager's world,
> although it's an area some designers see as theirs, too. At the other
> end, the skin of an app is executed by developers, with the involvement
> of designers varying from place to place. In between,
> the interaction design, the information design, the interface design,
> and the visual design all sound a lot like things designers do.
>

I don't know that these design elements are "clearly part of the
Product Manager's world." I agree that design straddles the
Customer/Developer divide, as do testing and a number of other
significant concerns (Performance, reliability, scalability, etc.)

That is part of the reason that XP changed its language to talk about
"Whole Teams". Scrum and Agile in general are starting to come around
to this view due largely to the influence of Lean. Lean suggests that
the entire team is responsible for meeting goals, and that individuals
contribute where they are best able. The only caveat that Scrum and XP
seem to require is that the Product Manager/Customer retains a sort of
veto power where product priorities are concerned.

> So in practice, I'd say that the more high-level any given design
> activity, the more likely it is to take place outside of the iteration
> framework. The right balance varies from shop to shop, but you should
> seek out the minimum amount of up-front design work that allows stories
> to complete smoothly.
>

Well put. I think the key is to retain an overarching vision of the
design while allowing the elements to emerge as the product grows in
complexity. Some things must be considered up front, but the goal of
the designer on an Agile team should be to keep the design simple
enough to prevent up-front design from interfering with the delivery
of stories.

> If you want more info, Amanda Willoughby and I did a talk on this very
> topic. We went around to a number of places (including Google and
> YouTube) and took a look at how they actually do design in an agile way.
> Our talk is about what we saw, and what we think works well. It's
> called "Meshing Gears" and you can find it here:
>
> http://pivotallabs.com/talks
>
> The downloadable video and MP3 are here:
>
> http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mov
> http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mp3
>

Haven't looked yet, but I'm looking forward to it.

[Thomas Sola]

Robert,

Thank you for pointing these aspects out and for articulating them  
better than I was about to. I don't think can add anything more but to  
second your points 100%.

Particularly in that what people say they want and what will be most  
effective for them to use can often be in stark contrast to each other

The benefit of agile is that you can fix your mistakes sooner rather  
than later but that's no reason not to design intelligently in advance.

Thomas

On Mar 10, 2009, at 5:57 PM, Robert Biddle <robtbiddle@...> wrote:

> Um, I was in agreement about UI designers working collaboratively with
> programmers. But now I'm getting concerned about some ideas that seem
> too simplistic. Some of us have argued these points on this mailing
> list before. But just to identify these issues, from my point of view:
>
> * I do not think there is any one accepted way to link UI design and
> agile software development. People are doing different things and we
> need reports of experience on how things turn out.
>
> * Although we can regard UI researchers and UI designers as part of
> the team, we should also recognize they may also be part of the
> customer. In particular, they may specify stories. Also, while they
> are the programmers will be working on the same product, it does not
> mean that have to be working on the same stories in the same
> iteration: see for example Lynn Miller's interleaved iterations,
> where the programmers work on one set of stories while the UI people
> design the next set and test the last set.
>
> * In UI work it is generally accepted that one cannot simply ask users
> what they want, deliver it, and expect things to work well. Users
> are often too close to the action, and although they may experience
> problems and desires, they cannot necessarily articulate
> solutions. In these cases observation, ethnography, and exploring
> several varying prototypes can help.
>
> * Similarly, in UI work it is generally accepted that low-fidelity
> prototypes can often elicit better feedback than high-fidelity
> prototypes or fully working software. Basically, it seems that
> things being too "finished" seems to act an inhibitor on
> articulation of important potential improvements.
>
> * Although it makes sense to design on the basis of user research and
> careful modeling, it still seems that usability testing is
> essential, because humans are complex choatic systems, and sometimes
> things that seem destined to be fine turn out to be wrong. And it
> is not possible to "test first".
>
> * Although it makes sense for UI designers and programmers to
> co-locate and collaborate, it also makes sense for UI designers to
> spend lots of time with users, and they may be far away. Co-location
> is powerful, but we have to face that we cannot co-locate with
> everyone all the time.
>
> I accept that others may have different views, but I think all the
> views above are sufficiently common that they should not just be swept
> away by an unusual destiny in the blue sea of August.
>
> Ahh, August.
> Or perhaps February. Your hemisphere may vary. Mine has.
>
> Robt
>
>
>
>
> Mike Dwyer wrote:
>>
>> First why is it that the people would not stay in the same place?
>>
>> Second how often have you seen this happen. You desing a UI and the
>> user love it, the developers provide code and full fuinctionality and
>> the users tell you they have not gotten what they wanted?
>>
>> Finally if you are getting feedback and taking the time to do a new
>> design before getting the developers involved, how long does it take
>> the users to tell you that it isn’t quite what they wanted?
>>
>> B y you working directly with the developers and the users everyone -
>> including the users get to see the procud as it is developed. If you
>> start with the very basics of what the users want they will change
>> their minds, but that is OK because much of what they now want will  
>> be
>> based on what they have working. Thiis way the usersw are being  
>> guided
>> by the product as it is finished and they will focus on what they  
>> need
>> and not what they think will be cool. You end up with a product
>> working that always meets the current needs of the user and continues
>> to be refined to better meet the users needs.
>>
>> *Mike Dwyer *
>> /Principal, Agile Coach/
>>
>> *BigVisible Solutions*
>> url: http://www.bigvisib le.com <http://www.bigvisible.com/>
>>
>> cell: [phone]
>>
>> email: mdwyer@bigvisible. com <mailto:asingh@...>
>>
>> *From:* Srinivas Manda [mailto:laksinu@ laksinu.com]
>> *Sent:* Tuesday, March 10, 2009 5:22 PM
>> *To:* agile-usability@ yahoogroups. com
>> *Subject:* [agile-usability] Re: Question_Agile Process_ UIE Virtual
>> Seminar
>>
>> Mike, we as a team are still trying to understand Agile, and we are
>> working based on how easy it is for us that suites our working model.
>>
>> Agile says that we (designer, dev, testing etc) should be at one  
>> place
>> and work on stories that team buys for that iteration
>>
>> But in realistic how can that happen?
>>
>> Say everyone is at one place for 3 weeks and start working on  
>> features
>> and as a UX designer I should design the feature and get that
>> validated with users and get a feedback from them .. But if we follow
>> agile then the dev team should be boiling the code before I get the
>> results ...if they do coding and if I get feedback from the users to
>> change some design then should the dev need to recode it ?
>>
>> Please comment on this
>>
>> --- In agile-usability@ yahoogroups. com
>> <mailto:agile-usability%40yahoogroups.com>, "Mike Dwyer" <mdwyer@...>
>> wrote:
>>>
>>> WHOA! Look dude, Ron was being very nice. We are not talking about
>>> letting developers in to the initial design meetings. Agile is about
>>> everyone being engaged. You may have been an UI or UX Prima Donna  
>>> in the
>>> conventional world but in the Agile sphere, you are a member of a
>> team, each
>>> of whom brings their own unique skills that you, in all likelihood
>> lack as
>>> you have chosen to be a UI wizard. Here is the secret message  
>>> inside the
>>> Agile bottle. Users don't buy software, or UI or databases or any  
>>> of the
>>> stuff we love to work with. Users buy value and it is our combined
>> job to
>>> work with the users to make sure we are all on the same page.
>>>
>>>
>>>
>>> So if you are going to be Agile, understand this. Your skills are no
>> more
>>> or less valuable than the most junior newbie tester or coder or BA.
>> It is
>>> the sum impact of the team that delivers.
>>>
>>>
>>>
>>> If this bothers you or you think that your world is an exception,  
>>> please
>>> look up the word Scrumbutt or Cragile and start using it to refer to
>> what
>>> you do.
>>>
>>>
>>>
>>> Mike Dwyer
>>> Principal, Agile Coach
>>>
>>> BigVisible Solutions
>>> url: http://www.bigvisib le.com <http://www.bigvisible.com>
>> <http://www.bigvisib le.com/ <http://www.bigvisible.com/>>
>>>
>>> cell: [phone]
>>>
>>> email: mdwyer@... <mailto:asingh@ ...>
>>>
>>>
>>>
>>>
>>>
>>> From: Srinivas Manda [mailto:laksinu@ ...]
>>> Sent: Tuesday, March 10, 2009 2:18 PM
>>> To: agile-usability@ yahoogroups. com
>> <mailto:agile-usability%40yahoogroups.com>
>>> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
>> Seminar
>>>
>>>
>>>
>>> Thanks everyone for your input... will make it as a mandit to  
>>> include
>>> developers in my initial design meetings and will say this will be a
>>> roadblock if not included...
>>>
>>> Thanks Everyone again..
>>>
>>> -laksinu
>>>
>>> --- In agile-usability@ yahoogroups. com
>> <mailto:agile-usability%40yahoogroups.com>
>>> <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries
>> <ronjeffries@>
>>> wrote:
>>>>
>>>> Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
>>>> wrote:
>>>>
>>>>> I agree to what you say , I would love to have Developers /
>> Designers to
>>>>> be in the same team but it is not possible
>>>>
>>>> Why? Are some of them in prison?
>>>>
>>>>> once example as i said earlier ... if developers and designer,
>> BA's are
>>>>> working at the same time and if the screen design is done ...  
>>>>> and we
>>>>> test the design with the USERS ... it is not really possible to  
>>>>> get
>>>>> feedback from the USERS in 2 weeks or so.. by the time we get the
>>>>> feedback from USERS developers are done with there coding ...
>> and if we
>>>>> have some changes .. developers need to change the code ...
>>>>
>>>> Yes. This is an obstacle. You must remove it.
>>>>
>>>> Ron Jeffries
>>>> www.XProgramming. com
>>>> www.xprogramming. com/blog
>>>> Attend our CSM Plus Course!
>>>> http://hendricksonx p.com/index. php?option= com_eventlist
>> <http://hendricksonxp.com/index.php?option=com_eventlist>
>>> <http://hendricksonx p.com/index. php?option=
>> com_eventlist&Itemid=28
>> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
>>> &Itemid=28
>>>> Thousands of years ago, the first man discovered how to make fire.
>>>> He was probably burned at the stake he had taught his brothers to
>>>> light - Howard Roark (The Fountainhead, Ayn Rand)
>>>>
>>>
>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[William Pietri]

Adam Sroka wrote:

>> Well, I'm not sure Agile says anything on its own, but if we take Scrum
>> or Extreme Programming, they certainly say that the product side of the
>> house needs to know enough about a story once development starts that
>> they can answer all the questions developers might have. That means they
>> tend to work ahead of development some.
>>
>>    
>
> I'm not sure that follows. As Ron Jeffries has said, stories are
> "placeholders for a conversation." It isn't necessary that the
> business "know enough ... to answer all the questions." Rather, it is
> sufficient that they know enough to consider the story a priority and
> are prepared to engage in conversation to determine what needs to be
> done. It is also common for the definition of a story to be loose
> enough that our shared understanding of it will change significantly
> over time.
>  

What you say is all true, but when I said "once development starts" I
mean for that particular story. Once developers start going on a story,
none of the good teams I've seen have a lot of time for research and
extended conversation.

>> In my view, "design" straddles the product management / development
>> divide. Consider Jesse James Garrett's "Elements of User Experience":
>>
>> http://www.jjg.net/elements/pdf/elements.pdf
>>
>> The topic of user needs and site objectives and functional specs are,
>> from the Agile perspective, clearly part of the product manager's world,
>> although it's an area some designers see as theirs, too. At the other
>> end, the skin of an app is executed by developers, with the involvement
>> of designers varying from place to place. In between,
>> the interaction design, the information design, the interface design,
>> and the visual design all sound a lot like things designers do.
>>
>>    
>
> I don't know that these design elements are "clearly part of the
> Product Manager's world." I agree that design straddles the
> Customer/Developer divide, as do testing and a number of other
> significant concerns (Performance, reliability, scalability, etc.)
>  

Ok. I know a lot of product managers who would argue with you, but I
understand that you have a different approach and I'm fine with that.


> That is part of the reason that XP changed its language to talk about
> "Whole Teams". Scrum and Agile in general are starting to come around
> to this view due largely to the influence of Lean. Lean suggests that
> the entire team is responsible for meeting goals, and that individuals
> contribute where they are best able. The only caveat that Scrum and XP
> seem to require is that the Product Manager/Customer retains a sort of
> veto power where product priorities are concerned.
>  

I think XP's separation is substantially stronger than that, but I'm
sure Ron will opine on this.

Observationally, most of the teams I have visited also have more of a
separation. Sure everybody has a lot of opinions, and sure, everybody's
big on consensus, and sure everybody doesn't shares bits of work pretty
promiscuously. But for the teams I've studied, I'd say that about 90% of
the work and decisions that fall neatly into design, development, or
product management are done by people who hold ones of those titles and
have a lot of background in it.

Still, I agree that good software can get made all sorts of ways, so I'm
not trying to be dogmatic here. I'm mainly trying to give Srinivas a
place to start from, so I'm going to be more shu about this than ha and
ri people would necessarily be comfortable with.


> Well put. I think the key is to retain an overarching vision of the
> design while allowing the elements to emerge as the product grows in
> complexity. Some things must be considered up front, but the goal of
> the designer on an Agile team should be to keep the design simple
> enough to prevent up-front design from interfering with the delivery
> of stories.
>  

Absolutely.

>  
>> If you want more info, Amanda Willoughby and I did a talk on this very
>> topic. We went around to a number of places (including Google and
>> YouTube) and took a look at how they actually do design in an agile way.
>> Our talk is about what we saw, and what we think works well. It's
>> called "Meshing Gears" and you can find it here:
>>
>> http://pivotallabs.com/talks
>>
>> The downloadable video and MP3 are here:
>>
>> http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mov
>> http://assets.pivotallabs.com/talks/10-22-2008_Meshing-Gears_Amanda-W_William-P.mp3
>>
>>    
>
> Haven't looked yet, but I'm looking forward to it.
>  

Thanks! Let me know what you think; I haven't done many video talks, and
the whole thing gives me the willies.

William



--
William Pietri - william@... - [phone]
Agile consulting, coaching, and development: http://www.scissor.com/
We'd love feedback on our new blog: http://agilefocus.com/

   

[Mike Dwyer-2]

Why the concern?
If all that you present is working and is delighting your customer's,
demoralizing your competition, and balancing everyone's life why are you
even talking about Agile.  I mean it is a real pain to implement.  All the
changes it makes to the established order of things.  It has well deserved
reputation for replacing the illusions of 'almost done' with the cold hard
state of DONE or not.  The process driven comfort of knowing that you can
pass it on and know that it will be 'thoroughly tested' somewhere down the
line is gone as well.

The other ugly thing you have to deal with is never having a chance to
explain how it is going, no meetings to go and ponder the possibility of the
proposition.  All you  end up doing is answering three stupid questions in
front of the people you committed to deliver with and to.  And you get to do
it everyday.  No excuses, No Earned Value, just where are you where do you
plan to be by this time tomorrow and what is holding you up.

I could go on and on about the 'dark side of Agile' but if you really don't
care about anything but getting things done, delivering value, and getting
better all the time, then I would suggest you take a long hard look at what
we are doing and figure out how to.  As Ken Schwaber says "It about common
sense".



Mike Dwyer
Principal, Agile Coach
BigVisible Solutions
url:    http://www.bigvisible.com
cell:   [phone]
email: mdwyer@...



-----Original Message-----
From: Robert Biddle [mailto:robtbiddle@...]
Sent: Tuesday, March 10, 2009 8:57 PM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

Um, I was in agreement about UI designers working collaboratively with
programmers. But now I'm getting concerned about some ideas that seem
too simplistic. Some of us have argued these points on this mailing
list before. But just to identify these issues, from my point of view:

* I do not think there is any one accepted way to link UI design and
agile software development. People are doing different things and we
need reports of experience on how things turn out.

* Although we can regard UI researchers and UI designers as part of
the team, we should also recognize they may also be part of the
customer. In particular, they may specify stories. Also, while they
are the programmers will be working on the same product, it does not
mean that have to be working on the same stories in the same
iteration: see for example Lynn Miller's interleaved iterations,
where the programmers work on one set of stories while the UI people
design the next set and test the last set.

* In UI work it is generally accepted that one cannot simply ask users
what they want, deliver it, and expect things to work well. Users
are often too close to the action, and although they may experience
problems and desires, they cannot necessarily articulate
solutions. In these cases observation, ethnography, and exploring
several varying prototypes can help.

* Similarly, in UI work it is generally accepted that low-fidelity
prototypes can often elicit better feedback than high-fidelity
prototypes or fully working software. Basically, it seems that
things being too "finished" seems to act an inhibitor on
articulation of important potential improvements.

* Although it makes sense to design on the basis of user research and
careful modeling, it still seems that usability testing is
essential, because humans are complex choatic systems, and sometimes
things that seem destined to be fine turn out to be wrong. And it
is not possible to "test first".

* Although it makes sense for UI designers and programmers to
co-locate and collaborate, it also makes sense for UI designers to
spend lots of time with users, and they may be far away. Co-location
is powerful, but we have to face that we cannot co-locate with
everyone all the time.

I accept that others may have different views, but I think all the
views above are sufficiently common that they should not just be swept
away by an unusual destiny in the blue sea of August.

Ahh, August.
Or perhaps February. Your hemisphere may vary. Mine has.

Robt




Mike Dwyer wrote:

>
> First why is it that the people would not stay in the same place?
>
> Second how often have you seen this happen. You desing a UI and the
> user love it, the developers provide code and full fuinctionality and
> the users tell you they have not gotten what they wanted?
>
> Finally if you are getting feedback and taking the time to do a new
> design before getting the developers involved, how long does it take
> the users to tell you that it isn't quite what they wanted?
>
> B y you working directly with the developers and the users everyone -
> including the users get to see the procud as it is developed. If you
> start with the very basics of what the users want they will change
> their minds, but that is OK because much of what they now want will be
> based on what they have working. Thiis way the usersw are being guided
> by the product as it is finished and they will focus on what they need
> and not what they think will be cool. You end up with a product
> working that always meets the current needs of the user and continues
> to be refined to better meet the users needs.
>
> *Mike Dwyer *
> /Principal, Agile Coach/
>
> *BigVisible Solutions*
> url: http://www.bigvisib le.com <http://www.bigvisible.com/>
>
> cell: [phone]
>
> email: mdwyer@bigvisible. com <mailto:asingh@...>
>
> *From:* Srinivas Manda [mailto:laksinu@ laksinu.com]
> *Sent:* Tuesday, March 10, 2009 5:22 PM
> *To:* agile-usability@ yahoogroups. com
> *Subject:* [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
>
> Mike, we as a team are still trying to understand Agile, and we are
> working based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place
> and work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features
> and as a UX designer I should design the feature and get that
> validated with users and get a feedback from them .. But if we follow
> agile then the dev team should be boiling the code before I get the
> results ...if they do coding and if I get feedback from the users to
> change some design then should the dev need to recode it ?
>
> Please comment on this
>
> --- In agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>, "Mike Dwyer" <mdwyer@...>
> wrote:
> >
> > WHOA! Look dude, Ron was being very nice. We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged. You may have been an UI or UX Prima Donna in the
> > conventional world but in the Agile sphere, you are a member of a
> team, each
> > of whom brings their own unique skills that you, in all likelihood
> lack as
> > you have chosen to be a UI wizard. Here is the secret message inside the
> > Agile bottle. Users don't buy software, or UI or databases or any of the
> > stuff we love to work with. Users buy value and it is our combined
> job to
> > work with the users to make sure we are all on the same page.
> >
> >
> >
> > So if you are going to be Agile, understand this. Your skills are no
> more
> > or less valuable than the most junior newbie tester or coder or BA.
> It is
> > the sum impact of the team that delivers.
> >
> >
> >
> > If this bothers you or you think that your world is an exception, please
> > look up the word Scrumbutt or Cragile and start using it to refer to
> what
> > you do.
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisib le.com <http://www.bigvisible.com>
> <http://www.bigvisib le.com/ <http://www.bigvisible.com/>>
> >
> > cell: [phone]
> >
> > email: mdwyer@... <mailto:asingh@ ...>
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@ ...]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
> >
> >
> >
> > Thanks everyone for your input... will make it as a mandit to include
> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>
> > <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries
> <ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers /
> Designers to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and designer,
> BA's are
> > > > working at the same time and if the screen design is done ... and we
> > > > test the design with the USERS ... it is not really possible to get
> > > > feedback from the USERS in 2 weeks or so.. by the time we get the
> > > > feedback from USERS developers are done with there coding ...
> and if we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming. com
> > > www.xprogramming. com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonx p.com/index. php?option= com_eventlist
> <http://hendricksonxp.com/index.php?option=com_eventlist>
> > <http://hendricksonx p.com/index. php?option=
> com_eventlist&Itemid=28
> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make fire.
> > > He was probably burned at the stake he had taught his brothers to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>
>

------------------------------------

Yahoo! Groups Links

[Adam Sroka-3]

On Tue, Mar 10, 2009 at 7:07 PM, William Pietri <william@...> wrote:

> Adam Sroka wrote:
> That is part of the reason that XP changed its language to talk about
> "Whole Teams". Scrum and Agile in general are starting to come around
> to this view due largely to the influence of Lean. Lean suggests that
> the entire team is responsible for meeting goals, and that individuals
> contribute where they are best able. The only caveat that Scrum and XP
> seem to require is that the Product Manager/Customer retains a sort of
> veto power where product priorities are concerned.
>
>
> I think XP's separation is substantially stronger than that, but I'm sure
> Ron will opine on this.
>
> Observationally, most of the teams I have visited also have more of a
> separation. Sure everybody has a lot of opinions, and sure, everybody's big
> on consensus, and sure everybody doesn't shares bits of work pretty
> promiscuously. But for the teams I've studied, I'd say that about 90% of the
> work and decisions that fall neatly into design, development, or product
> management are done by people who hold ones of those titles and have a lot
> of background in it.
>
> Still, I agree that good software can get made all sorts of ways, so I'm not
> trying to be dogmatic here. I'm mainly trying to give Srinivas a place to
> start from, so I'm going to be more shu about this than ha and ri people
> would necessarily be comfortable with.
>
>

Yes. Well, practice necessarily lags behind theory, but there are
plenty of us who /recommend/ an approach similar to what I described.
The notion of a cross-functional team, as I understand it, is that all
the roles necessary to fulfill a project should be filled, but that
those roles are not very important in how team members interact with
one another (i.e. they should work this out through
self-organization.)

[William Pietri]

Adam Sroka wrote:

>> Observationally, most of the teams I have visited also have more of a
>> separation. Sure everybody has a lot of opinions, and sure, everybody's big
>> on consensus, and sure everybody doesn't shares bits of work pretty
>> promiscuously. But for the teams I've studied, I'd say that about 90% of the
>> work and decisions that fall neatly into design, development, or product
>> management are done by people who hold ones of those titles and have a lot
>> of background in it.
>>
>> Still, I agree that good software can get made all sorts of ways, so I'm not
>> trying to be dogmatic here. I'm mainly trying to give Srinivas a place to
>> start from, so I'm going to be more shu about this than ha and ri people
>> would necessarily be comfortable with.
>>
>>
>>    
>
> Yes. Well, practice necessarily lags behind theory, but there are
> plenty of us who /recommend/ an approach similar to what I described.
> The notion of a cross-functional team, as I understand it, is that all
> the roles necessary to fulfill a project should be filled, but that
> those roles are not very important in how team members interact with
> one another (i.e. they should work this out through
> self-organization.)

Hmmm... In the case of Agile + Design, I think theory is actually
lagging practice a fair bit, which is why I try to observe as many teams
as possible. There are a number of teams doing great work with nary a
thought to how they do it; they just are doing it. YouTube was a great
example of that; they didn't even know that they were agile, but they
met most of my criteria.

Regarding a cross-functional team, I agree that for people to be fully
effective in an Agile context, they need to break out of the fixation on
formal roles that I think come from a command-and-control context.
However, I've seen some teams go wrong when they have no clear lines of
authority to fall back on when things get confused, especially early on
in an Agile adoption.

One failure mode that worries me a lot is where developers use chaos to
seize power, building the things that they think are most important and
designing them how they'd like them to be designed. Managers can do it
too, as can designers, but I've seen that less often.

No matter who seizes power inappropriately, I think a balance-of-powers
approach can keep things close enough to equilibrium that the group then
can find the happy Agile relationship you describe. Still, even if a
team has no formal roles, I think they often drift into informal ones,
just based on personal capabilities and interests. So I don't think it
does novices too much harm to start from a set of roles they understand,
just as long as they focus on team accountability rather than individual
accountability.

William

[JamesPage]

@robert

> * Although we can regard UI researchers and UI designers as part of the
> team, we should also recognize they may also be part of the customer.


I don't know if I agree here. Hotelling's model would say that what is best
for the user of the software is not necessarily best for the business. The
more competition there is the more aligned the customer and users needs are.
But if you have a (duo)monopoly type situation then they are not aligned.

If you take a start up in a new field there is no way that the product
at launch can meet every need of the user, or all the needs of all users. It
is far better to launch a product meeting some of the needs for some of the
users than not at all.

Joel on Software has some interesting insight about the importance for the
UI person and the developers to be peers :-

To make sure that the debate happens respectfully and on a rational basis of
> facts, it’s absolutely critical that the program managers and developers be
> peers. If developers report to the program manager, at some point during the
> debate the program manager is going to get sick of the whole thing and just
> say, “OK, enough talking, now we do it my way.” When they’re peers, this can
> never happen. It’s a little bit like courts of law: we don’t allow a lawyer
> for one side to be the judge, and we work on the theory that the truth is
> most likely to be uncovered through a process of debate between equals. The
> debate can only be a fair one if neither side has an unfair advantage.
>

He goes on to say

The number one mistake most companies make is having the manager of the
> programmers writing the specs and designing the product.
>

There has been much debate on IXDA list about Joel's comments. You also
point out.....

Although it makes sense for UI designers and programmers to co-locate and
> collaborate, it also makes sense for UI designers to spend lots of time with
> users, and they may be far away.


Why only  UI designers? Should not the whole team be learning about the end
user

I have no idea why agile has brought up the argument between the Designer
and the Programmer. In my early years I worked in games, and there was
little conflict between the designer and the artists. Often we would work
side by side. A small games company then worked in a very Agile way even if
the manifesto had been invented then.

James
http://blog.feralabs.com


>


2009/3/11 William Pietri <william@...>

>    Adam Sroka wrote:
>
>  Observationally, most of the teams I have visited also have more of a
> separation. Sure everybody has a lot of opinions, and sure, everybody's big
> on consensus, and sure everybody doesn't shares bits of work pretty
> promiscuously. But for the teams I've studied, I'd say that about 90% of the
> work and decisions that fall neatly into design, development, or product
> management are done by people who hold ones of those titles and have a lot
> of background in it.
>
> Still, I agree that good software can get made all sorts of ways, so I'm not
> trying to be dogmatic here. I'm mainly trying to give Srinivas a place to
> start from, so I'm going to be more shu about this than ha and ri people
> would necessarily be comfortable with.
>
>
>
>
>  Yes. Well, practice necessarily lags behind theory, but there are
> plenty of us who /recommend/ an approach similar to what I described.
> The notion of a cross-functional team, as I understand it, is that all
> the roles necessary to fulfill a project should be filled, but that
> those roles are not very important in how team members interact with
> one another (i.e. they should work this out through
> self-organization.)
>
>
> Hmmm... In the case of Agile + Design, I think theory is actually lagging
> practice a fair bit, which is why I try to observe as many teams as
> possible. There are a number of teams doing great work with nary a thought
> to how they do it; they just are doing it. YouTube was a great example of
> that; they didn't even know that they were agile, but they met most of my
> criteria.
>
> Regarding a cross-functional team, I agree that for people to be fully
> effective in an Agile context, they need to break out of the fixation on
> formal roles that I think come from a command-and-control context. However,
> I've seen some teams go wrong when they have no clear lines of authority to
> fall back on when things get confused, especially early on in an Agile
> adoption.
>
> One failure mode that worries me a lot is where developers use chaos to
> seize power, building the things that they think are most important and
> designing them how they'd like them to be designed. Managers can do it too,
> as can designers, but I've seen that less often.
>
> No matter who seizes power inappropriately, I think a balance-of-powers
> approach can keep things close enough to equilibrium that the group then can
> find the happy Agile relationship you describe. Still, even if a team has no
> formal roles, I think they often drift into informal ones, just based on
> personal capabilities and interests. So I don't think it does novices too
> much harm to start from a set of roles they understand, just as long as they
> focus on team accountability rather than individual accountability.
>
> William
>
>  
>

[Larry Constantine]

Robert Biddle said:

> Um, I was in agreement about UI designers working collaboratively with
> programmers. But now I'm getting concerned about some ideas that seem
> too simplistic. Some of us have argued these points on this mailing
> list before. But just to identify these issues, from my point of view:
...
> I accept that others may have different views, but I think all the
> views above are sufficiently common that they should not just be swept
> away by an unusual destiny in the blue sea of August.
>
> Ahh, August.
> Or perhaps February. Your hemisphere may vary. Mine has.

To which I would add, "Amen" to a summary with which I almost completely
agree, leaving aside the gratuitous reference to blue August sea, which
completely escapes me. :-)

In Madeira, the sea is never blue, but the sky is, at least today.

--Larry Constantine, IDSA, ACM Fellow
  University of Madeira

[Mike Dwyer-2]

James

I am fascinated with your analogy to rules and legal system and the truth.

I haven't heard this argument used in software  in over a decade and was
wondering where you still see the notion of the 'truth' as an attainable
goal through debate and conflict - particularly through analogies to the
legal system whose reliance on precedence and resistance to change.

Finally I would like to read more at the source level to the statement that
"agile has brought up the argument between the Designer and the Programmer"

As much of the work Mike Cohn and others has shown that Agile - in the game
industry - is all about collaboration and incrementally improving the value
delivered to the customer.  A thought that allows us to view the 'truth' as
having a half life and thus in need of a boost in clarity.

 

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   [phone]

email: mdwyer@... <mailto:asingh@...>

 

 

From: James Page [mailto:jamespage@...]
Sent: Wednesday, March 11, 2009 6:48 AM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 

@robert

* Although we can regard UI researchers and UI designers as part of the
team, we should also recognize they may also be part of the customer.

 

I don't know if I agree here. Hotelling's model would say that what is best
for the user of the software is not necessarily best for the business. The
more competition there is the more aligned the customer and users needs are.
But if you have a (duo)monopoly type situation then they are not aligned.

 

If you take a start up in a new field there is no way that the product at
launch can meet every need of the user, or all the needs of all users. It is
far better to launch a product meeting some of the needs for some of the
users than not at all.

 

Joel on Software has some interesting insight about the importance for the
UI person and the developers to be peers :-

 

To make sure that the debate happens respectfully and on a rational basis of
facts, it's absolutely critical that the program managers and developers be
peers. If developers report to the program manager, at some point during the
debate the program manager is going to get sick of the whole thing and just
say, "OK, enough talking, now we do it my way." When they're peers, this can
never happen. It's a little bit like courts of law: we don't allow a lawyer
for one side to be the judge, and we work on the theory that the truth is
most likely to be uncovered through a process of debate between equals. The
debate can only be a fair one if neither side has an unfair advantage.

 

He goes on to say

 

The number one mistake most companies make is having the manager of the
programmers writing the specs and designing the product.

 

There has been much debate on IXDA list about Joel's comments. You also
point out.....

 

Although it makes sense for UI designers and programmers to co-locate and
collaborate, it also makes sense for UI designers to spend lots of time with
users, and they may be far away.

 

Why only  UI designers? Should not the whole team be learning about the end
user

 

I have no idea why agile has brought up the argument between the Designer
and the Programmer. In my early years I worked in games, and there was
little conflict between the designer and the artists. Often we would work
side by side. A small games company then worked in a very Agile way even if
the manifesto had been invented then.

 

James

http://blog.feralabs.com 

 

 

 

2009/3/11 William Pietri <william@...>

Adam Sroka wrote:



Observationally, most of the teams I have visited also have more of a
separation. Sure everybody has a lot of opinions, and sure, everybody's big
on consensus, and sure everybody doesn't shares bits of work pretty
promiscuously. But for the teams I've studied, I'd say that about 90% of the
work and decisions that fall neatly into design, development, or product
management are done by people who hold ones of those titles and have a lot
of background in it.
 
Still, I agree that good software can get made all sorts of ways, so I'm not
trying to be dogmatic here. I'm mainly trying to give Srinivas a place to
start from, so I'm going to be more shu about this than ha and ri people
would necessarily be comfortable with.
 
 
   

Yes. Well, practice necessarily lags behind theory, but there are
plenty of us who /recommend/ an approach similar to what I described.
The notion of a cross-functional team, as I understand it, is that all
the roles necessary to fulfill a project should be filled, but that
those roles are not very important in how team members interact with
one another (i.e. they should work this out through
self-organization.)

 

Hmmm... In the case of Agile + Design, I think theory is actually lagging
practice a fair bit, which is why I try to observe as many teams as
possible. There are a number of teams doing great work with nary a thought
to how they do it; they just are doing it. YouTube was a great example of
that; they didn't even know that they were agile, but they met most of my
criteria.

Regarding a cross-functional team, I agree that for people to be fully
effective in an Agile context, they need to break out of the fixation on
formal roles that I think come from a command-and-control context. However,
I've seen some teams go wrong when they have no clear lines of authority to
fall back on when things get confused, especially early on in an Agile
adoption.

One failure mode that worries me a lot is where developers use chaos to
seize power, building the things that they think are most important and
designing them how they'd like them to be designed. Managers can do it too,
as can designers, but I've seen that less often.

No matter who seizes power inappropriately, I think a balance-of-powers
approach can keep things close enough to equilibrium that the group then can
find the happy Agile relationship you describe. Still, even if a team has no
formal roles, I think they often drift into informal ones, just based on
personal capabilities and interests. So I don't think it does novices too
much harm to start from a set of roles they understand, just as long as they
focus on team accountability rather than individual accountability.

William

 




 
 

[Mike Dwyer-2]

Larry

I assume that Mr Biddle is teasing us that on the "right side of the world"
it is summer that has Christmas and that he is basking in the glow of the
southern hemisphere while some of us are digging our ways to our cars.

 

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   [phone]

email: mdwyer@... <mailto:asingh@...>

 

 

From: Larry Constantine [mailto:lconstantine@...]
Sent: Wednesday, March 11, 2009 8:28 AM
To: agile-usability@...
Subject: RE: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 

Robert Biddle said:

> Um, I was in agreement about UI designers working collaboratively with
> programmers. But now I'm getting concerned about some ideas that seem
> too simplistic. Some of us have argued these points on this mailing
> list before. But just to identify these issues, from my point of view:
...
> I accept that others may have different views, but I think all the
> views above are sufficiently common that they should not just be swept
> away by an unusual destiny in the blue sea of August.
>
> Ahh, August.
> Or perhaps February. Your hemisphere may vary. Mine has.

To which I would add, "Amen" to a summary with which I almost completely
agree, leaving aside the gratuitous reference to blue August sea, which
completely escapes me. :-)

In Madeira, the sea is never blue, but the sky is, at least today.

--Larry Constantine, IDSA, ACM Fellow
University of Madeira




 
 

[Srinivas Manda]

Mike , please find my reply in blue text below


--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:
>
> First why is it that the people would not stay in the same place?

Srinivas - ,

1) As people are working on two or three projects at  one time and
sometimes its really hard to stay at one time ,

2) people may work remotely

3) developers buy some stories and designers buy some stories  for  AN
ITERATION , reason  i already mentioned it earlier ...

>
> Second how often have you seen this happen. You desing a UI and the
user
> love it, the developers provide code and full fuinctionality and the
users
> tell you they have not gotten what they wanted?

Srinivas - It happens only 2 out of 10 times ... and we always prefer to
get a feedback from the user and then do the coding ... that is always
we preferred ..

>
> Finally if you are getting feedback and taking the time to do a new
design
> before getting the developers involved, how long does it take the
users to
> tell you that it isn't quite what they wanted?

Srinivas - , 4 weeks -  we do testing with users once in every 4 weeks


>
>
> B y you working directly with the developers and the users everyone -
> including the users get to see the procud as it is developed. If you
start
> with the very basics of what the users want they will change their
minds,
> but that is OK because much of what they now want will be based on
what they
> have working. Thiis way the usersw are being guided by the product as
it is
> finished and they will focus on what they need and not what they think
will
> be cool. You end up with a product working that always meets the
current
> needs of the user and continues to be refined to better meet the users
> needs.

Srinivas - , I am not sure if i understand you correctly are you saying
that designers, developers and users should be at one place and then
users will see the product that is being developed.. if yes that is
really expensive ... you know we cannot ask users to sit with us 5 - 6
times in three weeks

>
>
>
>
>
> Mike Dwyer
> Principal, Agile Coach
>
> BigVisible Solutions
> url: http://www.bigvisible.com <http://www.bigvisible.com/>
>
> cell: [phone]
>
> email: mdwyer@... <mailto:asingh@...
>
>
>
>
>
> From: Srinivas Manda [mailto:laksinu@...]
> Sent: Tuesday, March 10, 2009 5:22 PM
> To: agile-usability@...
> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar
>
>
>
> Mike, we as a team are still trying to understand Agile, and we are
working
> based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place
and
> work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features
and
> as a UX designer I should design the feature and get that validated
with
> users and get a feedback from them .. But if we follow agile then the
dev

> team should be boiling the code before I get the results ...if they do
> coding and if I get feedback from the users to change some design then
> should the dev need to recode it ?
>
> Please comment on this
>
> --- In agile-usability@...
> <mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" mdwyer@
> wrote:
> >
> > WHOA! Look dude, Ron was being very nice. We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged. You may have been an UI or UX Prima Donna in

the
> > conventional world but in the Agile sphere, you are a member of a
team,
> each
> > of whom brings their own unique skills that you, in all likelihood
lack as
> > you have chosen to be a UI wizard. Here is the secret message inside
the
> > Agile bottle. Users don't buy software, or UI or databases or any of
the
> > stuff we love to work with. Users buy value and it is our combined
job to
> > work with the users to make sure we are all on the same page.
> >
> >
> >
> > So if you are going to be Agile, understand this. Your skills are no
more
> > or less valuable than the most junior newbie tester or coder or BA.
It is
> > the sum impact of the team that delivers.
> >
> >
> >
> > If this bothers you or you think that your world is an exception,
please
> > look up the word Scrumbutt or Cragile and start using it to refer to
what

> > you do.
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisible.com <http://www.bigvisible.com/>
> >
> > cell: [phone]
> >
> > email: mdwyer@ <mailto:asingh@
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar
> >
> >
> >
> > Thanks everyone for your input... will make it as a mandit to
include

> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > <mailto:agile-usability%40yahoogroups.com> , Ron Jeffries

<ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers /
Designers
> to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and designer,
BA's
> are
> > > > working at the same time and if the screen design is done ...
and we
> > > > test the design with the USERS ... it is not really possible to
get
> > > > feedback from the USERS in 2 weeks or so.. by the time we get
the
> > > > feedback from USERS developers are done with there coding ...
and if

> we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming.com
> > > www.xprogramming.com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonxp.com/index.php?option=com_eventlist
> > <http://hendricksonxp.com/index.php?option=com_eventlist
> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>
> &Itemid=28>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make fire.
> > > He was probably burned at the stake he had taught his brothers to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>

[Srinivas Manda]

--- In agile-usability@..., Robert Biddle <robtbiddle@...>
wrote:

I agree to what all ROB says .. it is really happening like how Rob
mentioned below ...

>
> Um, I was in agreement about UI designers working collaboratively with
> programmers. But now I'm getting concerned about some ideas that seem
> too simplistic. Some of us have argued these points on this mailing
> list before. But just to identify these issues, from my point of view:
>
> * I do not think there is any one accepted way to link UI design and
> agile software development. People are doing different things and we
> need reports of experience on how things turn out.
>
> * Although we can regard UI researchers and UI designers as part of
> the team, we should also recognize they may also be part of the
> customer. In particular, they may specify stories. Also, while they
> are the programmers will be working on the same product, it does not
> mean that have to be working on the same stories in the same
> iteration: see for example Lynn Miller's interleaved iterations,
> where the programmers work on one set of stories while the UI people
> design the next set and test the last set.
>
> * In UI work it is generally accepted that one cannot simply ask users
> what they want, deliver it, and expect things to work well. Users
> are often too close to the action, and although they may experience
> problems and desires, they cannot necessarily articulate
> solutions. In these cases observation, ethnography, and exploring
> several varying prototypes can help.
>
> * Similarly, in UI work it is generally accepted that low-fidelity
> prototypes can often elicit better feedback than high-fidelity
> prototypes or fully working software. Basically, it seems that
> things being too "finished" seems to act an inhibitor on
> articulation of important potential improvements.
>
> * Although it makes sense to design on the basis of user research and
> careful modeling, it still seems that usability testing is
> essential, because humans are complex choatic systems, and sometimes
> things that seem destined to be fine turn out to be wrong. And it
> is not possible to "test first".
>
> * Although it makes sense for UI designers and programmers to
> co-locate and collaborate, it also makes sense for UI designers to
> spend lots of time with users, and they may be far away. Co-location
> is powerful, but we have to face that we cannot co-locate with
> everyone all the time.
>
> I accept that others may have different views, but I think all the
> views above are sufficiently common that they should not just be swept
> away by an unusual destiny in the blue sea of August.
>
> Ahh, August.
> Or perhaps February. Your hemisphere may vary. Mine has.
>
> Robt
>
>
>
>
> Mike Dwyer wrote:
> >
> > First why is it that the people would not stay in the same place?
> >
> > Second how often have you seen this happen. You desing a UI and the
> > user love it, the developers provide code and full fuinctionality

and
> > the users tell you they have not gotten what they wanted?
> >
> > Finally if you are getting feedback and taking the time to do a new
> > design before getting the developers involved, how long does it take
> > the users to tell you that it isn't quite what they wanted?
> >
> > B y you working directly with the developers and the users everyone
-
> > including the users get to see the procud as it is developed. If you
> > start with the very basics of what the users want they will change
> > their minds, but that is OK because much of what they now want will
be
> > based on what they have working. Thiis way the usersw are being
guided
> > by the product as it is finished and they will focus on what they
need
> > and not what they think will be cool. You end up with a product
> > working that always meets the current needs of the user and
continues

> > to be refined to better meet the users needs.
> >
> > *Mike Dwyer *
> > /Principal, Agile Coach/
> >
> > *BigVisible Solutions*
> > url: http://www.bigvisib le.com <http://www.bigvisible.com/>
> >
> > cell: [phone]
> >
> > email: mdwyer@bigvisible. com <mailto:asingh@...
> >
> > *From:* Srinivas Manda [mailto:laksinu@ laksinu.com]
> > *Sent:* Tuesday, March 10, 2009 5:22 PM
> > *To:* agile-usability@ yahoogroups. com
> > *Subject:* [agile-usability] Re: Question_Agile Process_ UIE Virtual
> > Seminar
> >
> > Mike, we as a team are still trying to understand Agile, and we are
> > working based on how easy it is for us that suites our working

model.
> >
> > Agile says that we (designer, dev, testing etc) should be at one
place
> > and work on stories that team buys for that iteration
> >
> > But in realistic how can that happen?
> >
> > Say everyone is at one place for 3 weeks and start working on
features
> > and as a UX designer I should design the feature and get that
> > validated with users and get a feedback from them .. But if we
follow

> > agile then the dev team should be boiling the code before I get the
> > results ...if they do coding and if I get feedback from the users to
> > change some design then should the dev need to recode it ?
> >
> > Please comment on this
> >
> > --- In agile-usability@ yahoogroups. com
> > <mailto:agile-usability%40yahoogroups.com>, "Mike Dwyer" mdwyer@
> > wrote:
> > >
> > > WHOA! Look dude, Ron was being very nice. We are not talking about
> > > letting developers in to the initial design meetings. Agile is

about
> > > everyone being engaged. You may have been an UI or UX Prima Donna
in the
> > > conventional world but in the Agile sphere, you are a member of a
> > team, each
> > > of whom brings their own unique skills that you, in all likelihood
> > lack as
> > > you have chosen to be a UI wizard. Here is the secret message
inside the
> > > Agile bottle. Users don't buy software, or UI or databases or any
of the
> > > stuff we love to work with. Users buy value and it is our combined
> > job to
> > > work with the users to make sure we are all on the same page.
> > >
> > >
> > >
> > > So if you are going to be Agile, understand this. Your skills are
no
> > more
> > > or less valuable than the most junior newbie tester or coder or
BA.
> > It is
> > > the sum impact of the team that delivers.
> > >
> > >
> > >
> > > If this bothers you or you think that your world is an exception,
please
> > > look up the word Scrumbutt or Cragile and start using it to refer
to

> > what
> > > you do.
> > >
> > >
> > >
> > > Mike Dwyer
> > > Principal, Agile Coach
> > >
> > > BigVisible Solutions
> > > url: http://www.bigvisib le.com <http://www.bigvisible.com>
> > <http://www.bigvisib le.com/ <http://www.bigvisible.com/>>
> > >
> > > cell: [phone]
> > >
> > > email: mdwyer@ <mailto:asingh@ ...>
> > >
> > >
> > >
> > >
> > >
> > > From: Srinivas Manda [mailto:laksinu@ ...]
> > > Sent: Tuesday, March 10, 2009 2:18 PM
> > > To: agile-usability@ yahoogroups. com
> > <mailto:agile-usability%40yahoogroups.com>
> > > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
> > Seminar
> > >
> > >
> > >
> > > Thanks everyone for your input... will make it as a mandit to

include
> > > developers in my initial design meetings and will say this will be
a

> > > roadblock if not included...
> > >
> > > Thanks Everyone again..
> > >
> > > -laksinu
> > >
> > > --- In agile-usability@ yahoogroups. com
> > <mailto:agile-usability%40yahoogroups.com>
> > > <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries
> > <ronjeffries@>
> > > wrote:
> > > >
> > > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > > wrote:
> > > >
> > > > > I agree to what you say , I would love to have Developers /
> > Designers to
> > > > > be in the same team but it is not possible
> > > >
> > > > Why? Are some of them in prison?
> > > >
> > > > > once example as i said earlier ... if developers and designer,
> > BA's are
> > > > > working at the same time and if the screen design is done ...

and we
> > > > > test the design with the USERS ... it is not really possible
to get
> > > > > feedback from the USERS in 2 weeks or so.. by the time we get
the

> > > > > feedback from USERS developers are done with there coding ...
> > and if we
> > > > > have some changes .. developers need to change the code ...
> > > >
> > > > Yes. This is an obstacle. You must remove it.
> > > >
> > > > Ron Jeffries
> > > > www.XProgramming. com
> > > > www.xprogramming. com/blog
> > > > Attend our CSM Plus Course!
> > > > http://hendricksonx p.com/index. php?option= com_eventlist
> > <http://hendricksonxp.com/index.php?option=com_eventlist>
> > > <http://hendricksonx p.com/index. php?option=
> > com_eventlist&Itemid=28
> > <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
> > > &Itemid=28
> > > > Thousands of years ago, the first man discovered how to make

fire.
> > > > He was probably burned at the stake he had taught his brothers
to
> > > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > > >
> > >
> >
> >
>

[Mike Dwyer-2]

I agree that having users sit and work with you is not cost effective.  That
is why Agile has a key role called the product owner.  On a small effort,
this may be a single person, on large and complex ones it could be a team of
people. In either case there is one and only one product owner who has the
power to make decisions.  In a team situation the Product Owner stands
behind the decisions the team makes and is the person that makes sure there
is consistency within the Product Owner Team.

 

This is a critical issue because not only does the Product Owner speak for
the user, but also has the job of keeping management informed as to the
progress, cost, and value being delivered.  This is a very important role
and with it comes the having the right to make decisions that can overrule
the majority opinion of the team.  Why?  It is the Product Owner's neck on
the block and only they have the right to chop it off.

 

Distributed teams are a necessary part of the 21st century.  You have a
couple of choices that include having all the developers in one place all
the testers in another and the users in a third.  Bad idea as it forces you
into a waterfall or conventional approach.  You could have team one doing
one set of functionality, team 2 a second and so on.  This allows you to
concentrate your development of value so that work is done quickly.

 

Having people work on two or three projects at a time is a HUGE waste.  They
take longer, the quality is poorer, and they are not as much fun.  Don't
believe me?  There is an enormous amount of experience from all sorts of
industry and from education showing that interruptions are the core cause of
error fatigue and conflict.  For example two projects are due a week apart
and are scheduled for 3 weeks of work.  Project 1 has a two day delay in the
first week and project two has perfect conditions and gets 2 days ahead.
OOPS  they are now going to come due within a day.  What to do.  Lose the
productivity gained in the success of project 2 by delaying it?  Lose even
more on project 1 by delaying it?  Now that is an real ideal story because
it assumes the two project managers, the stakeholders, and the organization
are going to act in a rational way.  Nope what will probably happen is
someone will come to the team member and 'suggest' ways they can both
deliver on time.  This leads to a death march, an unhappy and unproductive
worker and two poor quality projects.

 

Testing every 4 weeks.  Hmm so you build up three weeks of errors that you
also write code on top of.  Then you test for a week and find a whole bunch
of bugs that have created a chain reaction of side effects that someone
coded around.  Now you get to not only fix those but re-write all the work
arounds.  To top it off you also get to deal with the fact that everytime
you touch code you introduce errors.

 

Now this is why I am a fan of Test Driven Development and FDD when it is
used in conjunction with solid underlying code.

 

 

Here is a thought  what happens if you do the UI after your developers have
solved the processing issues so that the users can see good data results and
then you can create the UI US to best show off the real thing?  Then you are
only dealing with the UI and the code interface to the processing?   What
does my blissful ignorance need to know about this approach?

 

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   [phone]

email: mdwyer@... <mailto:asingh@...>

 

 

From: Srinivas Manda [mailto:laksinu@...]
Sent: Wednesday, March 11, 2009 10:28 AM
To: agile-usability@...
Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar

 

Mike , please find my reply in blue text below


--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:
>
> First why is it that the people would not stay in the same place?

Srinivas - ,

1) As people are working on two or three projects at  one time and sometimes
its really hard to stay at one time ,

2) people may work remotely

3) developers buy some stories and designers buy some stories  for  AN
ITERATION , reason  i already mentioned it earlier ...

>
> Second how often have you seen this happen. You desing a UI and the user
> love it, the developers provide code and full fuinctionality and the users
> tell you they have not gotten what they wanted?

Srinivas - It happens only 2 out of 10 times ... and we always prefer to get
a feedback from the user and then do the coding ... that is always we
preferred ..

>
> Finally if you are getting feedback and taking the time to do a new design
> before getting the developers involved, how long does it take the users to
> tell you that it isn't quite what they wanted?

Srinivas - , 4 weeks -  we do testing with users once in every 4 weeks


>
>
> B y you working directly with the developers and the users everyone -
> including the users get to see the procud as it is developed. If you start
> with the very basics of what the users want they will change their minds,
> but that is OK because much of what they now want will be based on what
they
> have working. Thiis way the usersw are being guided by the product as it
is
> finished and they will focus on what they need and not what they think
will
> be cool. You end up with a product working that always meets the current
> needs of the user and continues to be refined to better meet the users
> needs.

Srinivas - , I am not sure if i understand you correctly are you saying that
designers, developers and users should be at one place and then users will
see the product that is being developed.. if yes that is really expensive
... you know we cannot ask users to sit with us 5 - 6 times in three weeks

 

>
>
>
>
>
> Mike Dwyer
> Principal, Agile Coach
>
> BigVisible Solutions
> url: http://www.bigvisible.com <http://www.bigvisible.com/>
>
> cell: [phone]
>
> email: mdwyer@... <mailto:asingh@...
>
>
>
>
>
> From: Srinivas Manda [mailto:laksinu@...]
> Sent: Tuesday, March 10, 2009 5:22 PM
> To: agile-usability@...
> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar
>
>
>
> Mike, we as a team are still trying to understand Agile, and we are

working

> based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place and
> work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features and
> as a UX designer I should design the feature and get that validated with
> users and get a feedback from them .. But if we follow agile then the dev
> team should be boiling the code before I get the results ...if they do
> coding and if I get feedback from the users to change some design then
> should the dev need to recode it ?
>
> Please comment on this
>
> --- In agile-usability@...
> <mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" mdwyer@
> wrote:
> >
> > WHOA! Look dude, Ron was being very nice. We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged. You may have been an UI or UX Prima Donna in the
> > conventional world but in the Agile sphere, you are a member of a team,
> each
> > of whom brings their own unique skills that you, in all likelihood lack

as
> > you have chosen to be a UI wizard. Here is the secret message inside the
> > Agile bottle. Users don't buy software, or UI or databases or any of the
> > stuff we love to work with. Users buy value and it is our combined job
to
> > work with the users to make sure we are all on the same page.
> >
> >
> >
> > So if you are going to be Agile, understand this. Your skills are no
more
> > or less valuable than the most junior newbie tester or coder or BA. It
is
> > the sum impact of the team that delivers.
> >
> >
> >
> > If this bothers you or you think that your world is an exception, please
> > look up the word Scrumbutt or Cragile and start using it to refer to
what

> > you do.
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisible.com <http://www.bigvisible.com/>
> >
> > cell: [phone]
> >
> > email: mdwyer@ <mailto:asingh@
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar

> >
> >
> >
> > Thanks everyone for your input... will make it as a mandit to include
> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > <mailto:agile-usability%40yahoogroups.com> , Ron Jeffries <ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers /

Designers

> to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and designer, BA's
> are
> > > > working at the same time and if the screen design is done ... and we
> > > > test the design with the USERS ... it is not really possible to get
> > > > feedback from the USERS in 2 weeks or so.. by the time we get the
> > > > feedback from USERS developers are done with there coding ... and if
> we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming.com
> > > www.xprogramming.com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonxp.com/index.php?option=com_eventlist
> > <http://hendricksonxp.com/index.php?option=com_eventlist
> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>
> &Itemid=28>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make fire.
> > > He was probably burned at the stake he had taught his brothers to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>

[JamesPage]

Mike,
I am bit confused by your question to rules and legal systems. Hotelling was
an economist, and statistician.
Yes there is a law named after him, but in
scientific<http://en.wikipedia.org/wiki/Scientific_law> not
legal sense. On the mater is a law truth, in science, what matters is
which philosophy
you pick, the view of Lakatosh, Popper, or Kuhn. Take your pick and I will
supply an argument. But all of them dealt with progress. How do ideas
develop, and move forward. Also they all dealt with conflict over ideas. Even
if we take a philosopher from the Arts like Foucault, there is a debate from
two sides.

For me what matters is who is the enemy. Some people like Matt Ridley belive
that there will always be conflict between groups see: THE ORIGINS OF
VIRTUE. I believe that companies such as Apple focus the discourse on
Microsoft, while others let the discourse develop inside the company
creating company politics. In the Games industry when I was there, it
was console manufactures who where the enemy, who took a lions share of
revenue, made buggy tools, demanded unrealistic deadlines. I don't know if
things have moved on.
Back to philosophy many have argued that HCI as a field lacks progress
because it does not have a central Paradigm (Kuhn), or Core(Lakatosh). Agile
has its manifesto.

For some ideas on discourse in Software Development, look at the IxDA
mailing list, and this one such as
http://blog.carbonfive.com/2009/03/agile/when-worlds-collide-conversation-with-maria-giudice-of-hot-studio

James
http://blog.feralabs.com




2009/3/11 Mike Dwyer <mdwyer@...>

>    James
>
> I am fascinated with your analogy to rules and legal system and the truth.
>
> I haven’t heard this argument used in software  in over a decade and was
> wondering where you still see the notion of the ‘truth’ as an attainable
> goal through debate and conflict – particularly through analogies to the
> legal system whose reliance on precedence and resistance to change.
>
> Finally I would like to read more at the source level to the statement that
> “agile has brought up the argument between the Designer and
> the Programmer”
>
> As much of the work Mike Cohn and others has shown that Agile – in the game
> industry – is all about collaboration and incrementally improving the value
> delivered to the customer.  A thought that allows us to view the ‘truth’ as
> having a half life and thus in need of a boost in clarity.
>
>
>
> *Mike Dwyer *
> *Principal, Agile Coach*
>
> *BigVisible Solutions*
> url:    http://www.bigvisible.com
>
> cell:   [phone]
>
> email: mdwyer@... <asingh@...>
>
>
>
>
>
> *From:* James Page [mailto:jamespage@...]
> *Sent:* Wednesday, March 11, 2009 6:48 AM
> *To:* agile-usability@...
> *Subject:* Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
>
>
>
> @robert
>
> * Although we can regard UI researchers and UI designers as part of the
> team, we should also recognize they may also be part of the customer.
>
>
>
> I don't know if I agree here. Hotelling's model would say that what is best
> for the user of the software is not necessarily best for the business. The
> more competition there is the more aligned the customer and users needs are.
> But if you have a (duo)monopoly type situation then they are not aligned.
>
>
>
> If you take a start up in a new field there is no way that the product
> at launch can meet every need of the user, or all the needs of all users. It
> is far better to launch a product meeting some of the needs for some of the
> users than not at all.
>
>
>
> Joel on Software has some interesting insight about the importance for the
> UI person and the developers to be peers :-
>
>
>
> To make sure that the debate happens respectfully and on a rational basis
> of facts, it’s absolutely critical that the program managers and developers
> be peers. If developers report to the program manager, at some point during
> the debate the program manager is going to get sick of the whole thing and
> just say, “OK, enough talking, now we do it my way.” When they’re peers,
> this can never happen. It’s a little bit like courts of law: we don’t allow
> a lawyer for one side to be the judge, and we work on the theory that the
> truth is most likely to be uncovered through a process of debate between
> equals. The debate can only be a fair one if neither side has an unfair
> advantage.
>
>
>
> He goes on to say
>
>
>
> The number one mistake most companies make is having the manager of the
> programmers writing the specs and designing the product.
>
>
>
> There has been much debate on IXDA list about Joel's comments. You also
> point out.....
>
>
>
> Although it makes sense for UI designers and programmers to co-locate and
> collaborate, it also makes sense for UI designers to spend lots of time with
> users, and they may be far away.
>
>
>
> Why only  UI designers? Should not the whole team be learning about the
> end user
>
>
>
> I have no idea why agile has brought up the argument between the Designer
> and the Programmer. In my early years I worked in games, and there was
> little conflict between the designer and the artists. Often we would work
> side by side. A small games company then worked in a very Agile way even if
> the manifesto had been invented then.
>
>
>
> James
>
> http://blog.feralabs.com
>
>
>
>
>
>
>
> 2009/3/11 William Pietri <william@...>
>
> Adam Sroka wrote:
>
>  Observationally, most of the teams I have visited also have more of a
>
> separation. Sure everybody has a lot of opinions, and sure, everybody's big
>
> on consensus, and sure everybody doesn't shares bits of work pretty
>
> promiscuously. But for the teams I've studied, I'd say that about 90% of the
>
> work and decisions that fall neatly into design, development, or product
>
> management are done by people who hold ones of those titles and have a lot
>
> of background in it.
>
>
>
> Still, I agree that good software can get made all sorts of ways, so I'm not
>
> trying to be dogmatic here. I'm mainly trying to give Srinivas a place to
>
> start from, so I'm going to be more shu about this than ha and ri people
>
> would necessarily be comfortable with.
>
>
>
>
>
>
>
> Yes. Well, practice necessarily lags behind theory, but there are
>
> plenty of us who /recommend/ an approach similar to what I described.
>
> The notion of a cross-functional team, as I understand it, is that all
>
> the roles necessary to fulfill a project should be filled, but that
>
> those roles are not very important in how team members interact with
>
> one another (i.e. they should work this out through
>
> self-organization.)
>
>
>
> Hmmm... In the case of Agile + Design, I think theory is actually lagging
> practice a fair bit, which is why I try to observe as many teams as
> possible. There are a number of teams doing great work with nary a thought
> to how they do it; they just are doing it. YouTube was a great example of
> that; they didn't even know that they were agile, but they met most of my
> criteria.
>
> Regarding a cross-functional team, I agree that for people to be fully
> effective in an Agile context, they need to break out of the fixation on
> formal roles that I think come from a command-and-control context. However,
> I've seen some teams go wrong when they have no clear lines of authority to
> fall back on when things get confused, especially early on in an Agile
> adoption.
>
> One failure mode that worries me a lot is where developers use chaos to
> seize power, building the things that they think are most important and
> designing them how they'd like them to be designed. Managers can do it too,
> as can designers, but I've seen that less often.
>
> No matter who seizes power inappropriately, I think a balance-of-powers
> approach can keep things close enough to equilibrium that the group then can
> find the happy Agile relationship you describe. Still, even if a team has no
> formal roles, I think they often drift into informal ones, just based on
> personal capabilities and interests. So I don't think it does novices too
> much harm to start from a set of roles they understand, just as long as they
> focus on team accountability rather than individual accountability.
>
> William
>
>
>
>  
>

[William Pietri]

That's a nicely put set of summaries, Robert. I especially agree that
this is something people all over the place are figuring out right now,
and that more detail on what people are actually doing and how it's
working for them is very valuable.

Regarding the question of UI researchers and designers as being on the
team or off the team, I generally encourage people to think of product
management as also being on the team. That makes it easier for designers
to see themselves as on it as well. In my view, the team is everybody
who is committed to and working mostly on a particular product.

Collocating the team is definitely harder for people who need to leave
the room to get some of their job done. But I've seen a number of
reasonable adaptations to that, and I think it usually works out very well.

The times I see trouble around this are with people who want to be fully
involved but are only focused on the team's product a fraction of their
time. In the best case, those people are treated as any other off-team
resource, and the team goes ahead without them as a member.

The bad cases include a low-momentum team, where people spend a lot of
time waiting or trying to context-switch when blocked. Another
possibility is that the team keeps momentum, but spends a lot of time
bringing the part-time person fully up to date and redoing things where
decisions change frequently. That is certainly costly, and looks pretty
frustrating to those actually on the team.

William



Robert Biddle wrote:

> Um, I was in agreement about UI designers working collaboratively with
> programmers. But now I'm getting concerned about some ideas that seem
> too simplistic. Some of us have argued these points on this mailing
> list before. But just to identify these issues, from my point of view:
>
> * I do not think there is any one accepted way to link UI design and
> agile software development. People are doing different things and we
> need reports of experience on how things turn out.
>
> * Although we can regard UI researchers and UI designers as part of
> the team, we should also recognize they may also be part of the
> customer. In particular, they may specify stories. Also, while they
> are the programmers will be working on the same product, it does not
> mean that have to be working on the same stories in the same
> iteration: see for example Lynn Miller's interleaved iterations,
> where the programmers work on one set of stories while the UI people
> design the next set and test the last set.
>
> * In UI work it is generally accepted that one cannot simply ask users
> what they want, deliver it, and expect things to work well. Users
> are often too close to the action, and although they may experience
> problems and desires, they cannot necessarily articulate
> solutions. In these cases observation, ethnography, and exploring
> several varying prototypes can help.
>
> * Similarly, in UI work it is generally accepted that low-fidelity
> prototypes can often elicit better feedback than high-fidelity
> prototypes or fully working software. Basically, it seems that
> things being too "finished" seems to act an inhibitor on
> articulation of important potential improvements.
>
> * Although it makes sense to design on the basis of user research and
> careful modeling, it still seems that usability testing is
> essential, because humans are complex choatic systems, and sometimes
> things that seem destined to be fine turn out to be wrong. And it
> is not possible to "test first".
>
> * Although it makes sense for UI designers and programmers to
> co-locate and collaborate, it also makes sense for UI designers to
> spend lots of time with users, and they may be far away. Co-location
> is powerful, but we have to face that we cannot co-locate with
> everyone all the time.
>
> I accept that others may have different views, but I think all the
> views above are sufficiently common that they should not just be swept
> away by an unusual destiny in the blue sea of August.
>
> Ahh, August.
> Or perhaps February. Your hemisphere may vary. Mine has.
>
> Robt
>
>
>
>
> Mike Dwyer wrote:
>  
>> First why is it that the people would not stay in the same place?
>>
>> Second how often have you seen this happen. You desing a UI and the
>> user love it, the developers provide code and full fuinctionality and
>> the users tell you they have not gotten what they wanted?
>>
>> Finally if you are getting feedback and taking the time to do a new
>> design before getting the developers involved, how long does it take
>> the users to tell you that it isn’t quite what they wanted?
>>
>> B y you working directly with the developers and the users everyone -
>> including the users get to see the procud as it is developed. If you
>> start with the very basics of what the users want they will change
>> their minds, but that is OK because much of what they now want will be
>> based on what they have working. Thiis way the usersw are being guided
>> by the product as it is finished and they will focus on what they need
>> and not what they think will be cool. You end up with a product
>> working that always meets the current needs of the user and continues
>> to be refined to better meet the users needs.
>>
>> *Mike Dwyer *
>> /Principal, Agile Coach/
>>
>> *BigVisible Solutions*
>> url: http://www.bigvisib le.com <http://www.bigvisible.com/>
>>
>> cell: [phone]
>>
>> email: mdwyer@bigvisible. com <mailto:asingh@...>
>>
>> *From:* Srinivas Manda [mailto:laksinu@ laksinu.com]
>> *Sent:* Tuesday, March 10, 2009 5:22 PM
>> *To:* agile-usability@ yahoogroups. com
>> *Subject:* [agile-usability] Re: Question_Agile Process_ UIE Virtual
>> Seminar
>>
>> Mike, we as a team are still trying to understand Agile, and we are
>> working based on how easy it is for us that suites our working model.
>>
>> Agile says that we (designer, dev, testing etc) should be at one place
>> and work on stories that team buys for that iteration
>>
>> But in realistic how can that happen?
>>
>> Say everyone is at one place for 3 weeks and start working on features
>> and as a UX designer I should design the feature and get that
>> validated with users and get a feedback from them .. But if we follow
>> agile then the dev team should be boiling the code before I get the
>> results ...if they do coding and if I get feedback from the users to
>> change some design then should the dev need to recode it ?
>>
>> Please comment on this
>>
>> --- In agile-usability@ yahoogroups. com
>> <mailto:agile-usability%40yahoogroups.com>, "Mike Dwyer" <mdwyer@...>
>> wrote:
>>    
>>> WHOA! Look dude, Ron was being very nice. We are not talking about
>>> letting developers in to the initial design meetings. Agile is about
>>> everyone being engaged. You may have been an UI or UX Prima Donna in the
>>> conventional world but in the Agile sphere, you are a member of a
>>>      
>> team, each
>>    
>>> of whom brings their own unique skills that you, in all likelihood
>>>      
>> lack as
>>    
>>> you have chosen to be a UI wizard. Here is the secret message inside the
>>> Agile bottle. Users don't buy software, or UI or databases or any of the
>>> stuff we love to work with. Users buy value and it is our combined
>>>      
>> job to
>>    
>>> work with the users to make sure we are all on the same page.
>>>
>>>
>>>
>>> So if you are going to be Agile, understand this. Your skills are no
>>>      
>> more
>>    
>>> or less valuable than the most junior newbie tester or coder or BA.
>>>      
>> It is
>>    
>>> the sum impact of the team that delivers.
>>>
>>>
>>>
>>> If this bothers you or you think that your world is an exception, please
>>> look up the word Scrumbutt or Cragile and start using it to refer to
>>>      
>> what
>>    
>>> you do.
>>>
>>>
>>>
>>> Mike Dwyer
>>> Principal, Agile Coach
>>>
>>> BigVisible Solutions
>>> url: http://www.bigvisib le.com <http://www.bigvisible.com>
>>>      
>> <http://www.bigvisib le.com/ <http://www.bigvisible.com/>>
>>    
>>> cell: [phone]
>>>
>>> email: mdwyer@... <mailto:asingh@ ...>
>>>
>>>
>>>
>>>
>>>
>>> From: Srinivas Manda [mailto:laksinu@ ...]
>>> Sent: Tuesday, March 10, 2009 2:18 PM
>>> To: agile-usability@ yahoogroups. com
>>>      
>> <mailto:agile-usability%40yahoogroups.com>
>>    
>>> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
>>>      
>> Seminar
>>    
>>>
>>> Thanks everyone for your input... will make it as a mandit to include
>>> developers in my initial design meetings and will say this will be a
>>> roadblock if not included...
>>>
>>> Thanks Everyone again..
>>>
>>> -laksinu
>>>
>>> --- In agile-usability@ yahoogroups. com
>>>      
>> <mailto:agile-usability%40yahoogroups.com>
>>    
>>> <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries
>>>      
>> <ronjeffries@>
>>    
>>> wrote:
>>>      
>>>> Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
>>>> wrote:
>>>>
>>>>        
>>>>> I agree to what you say , I would love to have Developers /
>>>>>          
>> Designers to
>>    
>>>>> be in the same team but it is not possible
>>>>>          
>>>> Why? Are some of them in prison?
>>>>
>>>>        
>>>>> once example as i said earlier ... if developers and designer,
>>>>>          
>> BA's are
>>    
>>>>> working at the same time and if the screen design is done ... and we
>>>>> test the design with the USERS ... it is not really possible to get
>>>>> feedback from the USERS in 2 weeks or so.. by the time we get the
>>>>> feedback from USERS developers are done with there coding ...
>>>>>          
>> and if we
>>    
>>>>> have some changes .. developers need to change the code ...
>>>>>          
>>>> Yes. This is an obstacle. You must remove it.
>>>>
>>>> Ron Jeffries
>>>> www.XProgramming. com
>>>> www.xprogramming. com/blog
>>>> Attend our CSM Plus Course!
>>>> http://hendricksonx p.com/index. php?option= com_eventlist
>>>>        
>> <http://hendricksonxp.com/index.php?option=com_eventlist>
>>    
>>> <http://hendricksonx p.com/index. php?option=
>>>      
>> com_eventlist&Itemid=28
>> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
>>    
>>> &Itemid=28
>>>      
>>>> Thousands of years ago, the first man discovered how to make fire.
>>>> He was probably burned at the stake he had taught his brothers to
>>>> light - Howard Roark (The Fountainhead, Ayn Rand)
>>>>
>>>>        
>>    
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>  

[Scott Preece-2]

Hi,

Note that Srinivas said "testing with users" is done every 4 weeks, not that no other testing is done in between. "Testing with users" corresponds to per-iteration feedback. If they're doing serious UX work, this would involve bringing in end users and observing them using the system, then collecting their feedback.

Same point about "sitting with the users". You may sit with the PO, but the end users are probably at least one hop away and otherwise occupied; if you're doing consumer-facing products, they may be outside the organization entirely, and cost money to gather. Even if you could convince the organization to assign customers to sit with the team all the time, that would diminish their value as representative users - they would know too much.

scott




________________________________
From: Mike Dwyer <mdwyer@...>
To: agile-usability@...
Sent: Wednesday, March 11, 2009 10:05:18 AM
Subject: RE: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar


I agree that having users sit and work with you is not cost effective.
That is why Agile has a key role called the product owner.  On a small effort,
this may be a single person, on large and complex ones it could be a team of
people. In either case there is one and only one product owner who has the
power to make decisions.  In a team situation the Product Owner stands
behind the decisions the team makes and is the person that makes sure there is
consistency within the Product Owner Team.
 
This is a critical issue because not only does the Product Owner
speak for the user, but also has the job of keeping management informed as to
the progress, cost, and value being delivered.  This is a very important role
and with it comes the having the right to make decisions that can overrule the
majority opinion of the team.  Why?  It is the Product Owner’s
neck on the block and only they have the right to chop it off.
 
Distributed teams are a necessary part of the 21st century.  You have a couple of choices that include having all the
developers in one place all the testers in another and the users in a third.
Bad idea as it forces you into a waterfall or conventional approach.  You
could have team one doing one set of functionality, team 2 a second and so
on.  This allows you to concentrate your development of value so that work
is done quickly.
 
Having people work on two or three projects at a time is a HUGE
waste.  They take longer, the quality is poorer, and they are not as much
fun.  Don’t believe me?  There is an enormous amount of
experience from all sorts of industry and from education showing that
interruptions are the core cause of error fatigue and conflict.  For
example two projects are due a week apart and are scheduled for 3 weeks of
work.  Project 1 has a two day delay in the first week and project two has
perfect conditions and gets 2 days ahead.  OOPS  they are now going
to come due within a day.  What to do.  Lose the productivity gained
in the success of project 2 by delaying it?  Lose even more on project 1
by delaying it?  Now that is an real ideal story because it assumes the
two project managers, the stakeholders, and the organization are going to act
in a rational way.  Nope what will probably happen is someone will come to
the team member and ‘suggest’ ways they can both deliver on
time.  This leads to a death march, an unhappy and unproductive worker and
two poor quality projects.
 
Testing every 4 weeks.  Hmm so you build up three weeks of
errors that you also write code on top of.  Then you test for a week and
find a whole bunch of bugs that have created a chain reaction of side effects
that someone coded around.  Now you get to not only fix those but re-write
all the work arounds.  To top it off you also get to deal with the fact
that everytime you touch code you introduce errors.
 
Now this is why I am a fan of Test Driven Development and FDD
when it is used in conjunction with solid underlying code.
 
 
Here is a thought  what happens if you do the UI after your
developers have solved the processing issues so that the users can see good
data results and then you can create the UI US to best show off the real
thing?  Then you are only dealing with the UI and the code interface to the
processing?   What does my blissful ignorance need to know about this
approach?
 
Mike Dwyer
Principal, Agile Coach
BigVisible Solutions
url:    http://www.bigvisible.com/
cell:   [phone]
email:mdwyer@bigvisible. com
 
 
From:Srinivas Manda
[mailto:laksinu@ laksinu.com]
Sent: Wednesday, March 11, 2009 10:28 AM
To: agile-usability@ yahoogroups. com
Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar
 
Mike , please find my reply in blue text
below

--- In agile-usability@ yahoogroups. com, "Mike Dwyer"
<mdwyer@...> wrote:
>
> First why is it that the people would not stay in the same place?
Srinivas - ,
1) As people are working on two or three
projects at  one time and sometimes its really hard to stay at one time ,

2) people may work remotely

3) developers buy some stories and designers buy some stories
for  AN ITERATION , reason  i already mentioned it earlier ...

>
> Second how often have you seen this happen. You desing a UI and the user
> love it, the developers provide code and full fuinctionality and the users
> tell you they have not gotten what they wanted?

Srinivas - It happens only 2
out of 10 times ... and we always prefer to get a feedback from the user and
then do the coding ... that is always we preferred ..

>
> Finally if you are getting feedback and taking the time to do a new design
> before getting the developers involved, how long does it take the users to
> tell you that it isn't quite what they wanted?

Srinivas - , 4 weeks -  we do
testing with users once in every 4 weeks


>
>
> B y you working directly with the developers and the users everyone -
> including the users get to see the procud as it is developed. If you start
> with the very basics of what the users want they will change their minds,
> but that is OK because much of what they now want will be based on what
they
> have working. Thiis way the usersw are being guided by the product as it
is
> finished and they will focus on what they need and not what they think
will
> be cool. You end up with a product working that always meets the current
> needs of the user and continues to be refined to better meet the users
> needs.
Srinivas - , I am not sure if i
understand you correctly are you saying that designers,
developers and users should be at one placeand then users will see the product that is being developed.. if yes that is really expensive... you know we cannot ask users to sit with us 5 - 6 times in three weeks
 

>
>
>
>
>
> Mike Dwyer
> Principal, Agile Coach
>
> BigVisible Solutions
> url: http://www.bigvisib le.com<http://www.bigvisib le.com/>
>
> cell: [phone]
>
> email: mdwyer@... <mailto:asingh@ ...
>
>
>
>
>
> From: Srinivas Manda [mailto:laksinu@ ...]
> Sent: Tuesday, March 10, 2009 5:22 PM
> To: agile-usability@ yahoogroups. com
> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar
>
>
>
> Mike, we as a team are still trying to understand Agile, and we are

working

> based on how easy it is for us that suites our working model.
>
> Agile says that we (designer, dev, testing etc) should be at one place and
> work on stories that team buys for that iteration
>
> But in realistic how can that happen?
>
> Say everyone is at one place for 3 weeks and start working on features and
> as a UX designer I should design the feature and get that validated with
> users and get a feedback from them .. But if we follow agile then the dev
> team should be boiling the code before I get the results ...if they do
> coding and if I get feedback from the users to change some design then
> should the dev need to recode it ?
>
> Please comment on this
>
> --- In agile-usability@ yahoogroups. com
> <mailto:agile- usability% 40yahoogroups. com> , "Mike Dwyer"

mdwyer@
> wrote:
> >
> > WHOA! Look dude, Ron was being very nice. We are not talking about
> > letting developers in to the initial design meetings. Agile is about
> > everyone being engaged. You may have been an UI or UX Prima Donna in
the
> > conventional world but in the Agile sphere, you are a member of a
team,
> each
> > of whom brings their own unique skills that you, in all likelihood
lack as
> > you have chosen to be a UI wizard. Here is the secret message inside
the
> > Agile bottle. Users don't buy software, or UI or databases or any of
the
> > stuff we love to work with. Users buy value and it is our combined
job to
> > work with the users to make sure we are all on the same page.
> >
> >
> >
> > So if you are going to be Agile, understand this. Your skills are no
more
> > or less valuable than the most junior newbie tester or coder or BA.
It is
> > the sum impact of the team that delivers.
> >
> >
> >
> > If this bothers you or you think that your world is an exception,
please
> > look up the word Scrumbutt or Cragile and start using it to refer to
what

> > you do.
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisib le.com <http://www.bigvisib le.com/>
> >
> > cell: [phone]
> >
> > email: mdwyer@ <mailto:asingh@
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@ ]
> > Sent: Tuesday, March 10, 2009 2:18 PM
> > To: agile-usability@ yahoogroups. com
> <mailto:agile- usability% 40yahoogroups. com>
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar

> >
> >
> >
> > Thanks everyone for your input... will make it as a mandit to include
> > developers in my initial design meetings and will say this will be a
> > roadblock if not included...
> >
> > Thanks Everyone again..
> >
> > -laksinu
> >
> > --- In agile-usability@ yahoogroups. com
> <mailto:agile- usability% 40yahoogroups. com>
> > <mailto:agile- usability% 40yahoogroups. com> , Ron Jeffries

<ronjeffries@>
> > wrote:
> > >
> > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > wrote:
> > >
> > > > I agree to what you say , I would love to have Developers /
Designers
> to
> > > > be in the same team but it is not possible
> > >
> > > Why? Are some of them in prison?
> > >
> > > > once example as i said earlier ... if developers and
designer, BA's
> are
> > > > working at the same time and if the screen design is done
... and we
> > > > test the design with the USERS ... it is not really
possible to get
> > > > feedback from the USERS in 2 weeks or so.. by the time we
get the
> > > > feedback from USERS developers are done with there coding
... and if

> we
> > > > have some changes .. developers need to change the code ...
> > >
> > > Yes. This is an obstacle. You must remove it.
> > >
> > > Ron Jeffries
> > > www.XProgramming. com
> > > www.xprogramming. com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonx p.com/index. php?option= com_eventlist
> > <http://hendricksonx p.com/index. php?option= com_eventlist
> <http://hendricksonx p.com/index. php?option= com_eventlist&Itemid=28>
> &Itemid=28>
> > &Itemid=28
> > > Thousands of years ago, the first man discovered how to make

fire.
> > > He was probably burned at the stake he had taught his brothers
to
> > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > >
> >
>
   

[Srinivas Manda]

--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:
>
> I agree that having users sit and work with you is not cost effective.
That
> is why Agile has a key role called the product owner. On a small
effort,
> this may be a single person, on large and complex ones it could be a
team of
> people. In either case there is one and only one product owner who has
the
> power to make decisions. In a team situation the Product Owner stands
> behind the decisions the team makes and is the person that makes sure
there
> is consistency within the Product Owner Team.


>
>
>
> This is a critical issue because not only does the Product Owner speak
for
> the user, but also has the job of keeping management informed as to
the
> progress, cost, and value being delivered. This is a very important
role
> and with it comes the having the right to make decisions that can
overrule
> the majority opinion of the team. Why? It is the Product Owner's neck
on
> the block and only they have the right to chop it off.



Srinivas :

Product Owner represents user but is not the actual user of the
application, we cannot go on what the product owner says if product
owner is OK with one interaction and the same interaction may be a
confusion to an user ( we wanted to validate that with the user )

so we cannot say that the product owner has the final decisions when it
comes to User Experience

Also Product Owner still want to RUN the design with the users and test
it before it actually gets coded and they do really like that way to
work on ...






>
>
>
> Distributed teams are a necessary part of the 21st century. You have a
> couple of choices that include having all the developers in one place
all
> the testers in another and the users in a third. Bad idea as it forces
you
> into a waterfall or conventional approach. You could have team one
doing
> one set of functionality, team 2 a second and so on. This allows you
to
> concentrate your development of value so that work is done quickly.
>






>
>
> Having people work on two or three projects at a time is a HUGE waste.
They
> take longer, the quality is poorer, and they are not as much fun.
Don't
> believe me? There is an enormous amount of experience from all sorts
of
> industry and from education showing that interruptions are the core
cause of
> error fatigue and conflict. For example two projects are due a week
apart
> and are scheduled for 3 weeks of work. Project 1 has a two day delay
in the
> first week and project two has perfect conditions and gets 2 days
ahead.
> OOPS they are now going to come due within a day. What to do. Lose the
> productivity gained in the success of project 2 by delaying it? Lose
even
> more on project 1 by delaying it? Now that is an real ideal story
because
> it assumes the two project managers, the stakeholders, and the
organization
> are going to act in a rational way. Nope what will probably happen is
> someone will come to the team member and 'suggest' ways they can both
> deliver on time. This leads to a death march, an unhappy and
unproductive
> worker and two poor quality projects.

Srinivas : We cannot tell to Management that we only want to work on 1
project.... that does not WORK


>
>
>
> Testing every 4 weeks. Hmm so you build up three weeks of errors that
you
> also write code on top of. Then you test for a week and find a whole
bunch
> of bugs that have created a chain reaction of side effects that
someone
> coded around. Now you get to not only fix those but re-write all the
work
> arounds. To top it off you also get to deal with the fact that
everytime
> you touch code you introduce errors.

Srinivas : When i say testing it is usability testing...  we design one
feature per iteration and get it tested before that iteration is done
... and do some changes that we get from users and hand over these
designs to developers for next iteration to get it coded.




>
>
>
> Now this is why I am a fan of Test Driven Development and FDD when it
is
> used in conjunction with solid underlying code.
>
>
>
>
>
> Here is a thought what happens if you do the UI after your developers
have
> solved the processing issues so that the users can see good data
results and
> then you can create the UI US to best show off the real thing? Then
you are
> only dealing with the UI and the code interface to the processing?
What

> does my blissful ignorance need to know about this approach?
>
>
>
> Mike Dwyer
> Principal, Agile Coach
>
> BigVisible Solutions
> url: http://www.bigvisible.com <http://www.bigvisible.com/>
>
> cell: [phone]
>
> email: mdwyer@... <mailto:asingh@...
>
>
>
>
>
> From: Srinivas Manda [mailto:laksinu@...]
> Sent: Wednesday, March 11, 2009 10:28 AM
> To: agile-usability@...
> Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar

>
>
>
> Mike , please find my reply in blue text below
>
>
> --- In agile-usability@..., "Mike Dwyer" mdwyer@ wrote:
> >
> > First why is it that the people would not stay in the same place?
>
> Srinivas - ,
>
> 1) As people are working on two or three projects at one time and

sometimes
> its really hard to stay at one time ,
>
> 2) people may work remotely
>
> 3) developers buy some stories and designers buy some stories for AN
> ITERATION , reason i already mentioned it earlier ...
>
> >
> > Second how often have you seen this happen. You desing a UI and the
user
> > love it, the developers provide code and full fuinctionality and the
users
> > tell you they have not gotten what they wanted?
>
> Srinivas - It happens only 2 out of 10 times ... and we always prefer
to get
> a feedback from the user and then do the coding ... that is always we
> preferred ..
>
> >
> > Finally if you are getting feedback and taking the time to do a new
design
> > before getting the developers involved, how long does it take the
users to
> > tell you that it isn't quite what they wanted?
>
> Srinivas - , 4 weeks - we do testing with users once in every 4 weeks
>
>
> >
> >
> > B y you working directly with the developers and the users everyone
-
> > including the users get to see the procud as it is developed. If you
start
> > with the very basics of what the users want they will change their
minds,
> > but that is OK because much of what they now want will be based on
what
> they
> > have working. Thiis way the usersw are being guided by the product
as it
> is
> > finished and they will focus on what they need and not what they
think
> will
> > be cool. You end up with a product working that always meets the
current
> > needs of the user and continues to be refined to better meet the
users
> > needs.
>
> Srinivas - , I am not sure if i understand you correctly are you
saying that
> designers, developers and users should be at one place and then users
will
> see the product that is being developed.. if yes that is really
expensive
> ... you know we cannot ask users to sit with us 5 - 6 times in three
weeks

>
>
>
>
> >
> >
> >
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url: http://www.bigvisible.com <http://www.bigvisible.com/>
> >
> > cell: [phone]
> >
> > email: mdwyer@ <mailto:asingh@
> >
> >
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@]
> > Sent: Tuesday, March 10, 2009 5:22 PM
> > To: agile-usability@...
> > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual

Seminar
> >
> >
> >
> > Mike, we as a team are still trying to understand Agile, and we are
> working
> > based on how easy it is for us that suites our working model.
> >
> > Agile says that we (designer, dev, testing etc) should be at one
place and
> > work on stories that team buys for that iteration
> >
> > But in realistic how can that happen?
> >
> > Say everyone is at one place for 3 weeks and start working on
features and
> > as a UX designer I should design the feature and get that validated
with
> > users and get a feedback from them .. But if we follow agile then
the dev
> > team should be boiling the code before I get the results ...if they
do
> > coding and if I get feedback from the users to change some design
then

> > should the dev need to recode it ?
> >
> > Please comment on this
> >
> > --- In agile-usability@...
> > <mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" mdwyer@
> > wrote:
> > >
> > > WHOA! Look dude, Ron was being very nice. We are not talking about
> > > letting developers in to the initial design meetings. Agile is

about
> > > everyone being engaged. You may have been an UI or UX Prima Donna
in the
> > > conventional world but in the Agile sphere, you are a member of a
team,
> > each
> > > of whom brings their own unique skills that you, in all likelihood
lack
> as
> > > you have chosen to be a UI wizard. Here is the secret message
inside the
> > > Agile bottle. Users don't buy software, or UI or databases or any
of the
> > > stuff we love to work with. Users buy value and it is our combined
job
> to
> > > work with the users to make sure we are all on the same page.
> > >
> > >
> > >
> > > So if you are going to be Agile, understand this. Your skills are
no
> more
> > > or less valuable than the most junior newbie tester or coder or
BA. It
> is
> > > the sum impact of the team that delivers.
> > >
> > >
> > >
> > > If this bothers you or you think that your world is an exception,
please
> > > look up the word Scrumbutt or Cragile and start using it to refer
to

> what
> > > you do.
> > >
> > >
> > >
> > > Mike Dwyer
> > > Principal, Agile Coach
> > >
> > > BigVisible Solutions
> > > url: http://www.bigvisible.com <http://www.bigvisible.com/>
> > >
> > > cell: [phone]
> > >
> > > email: mdwyer@ <mailto:asingh@
> > >
> > >
> > >
> > >
> > >
> > > From: Srinivas Manda [mailto:laksinu@]
> > > Sent: Tuesday, March 10, 2009 2:18 PM
> > > To: agile-usability@...
> > <mailto:agile-usability%40yahoogroups.com>
> > > Subject: [agile-usability] Re: Question_Agile Process_ UIE Virtual
> Seminar
> > >
> > >
> > >
> > > Thanks everyone for your input... will make it as a mandit to

include
> > > developers in my initial design meetings and will say this will be
a
> > > roadblock if not included...
> > >
> > > Thanks Everyone again..
> > >
> > > -laksinu
> > >
> > > --- In agile-usability@...
> > <mailto:agile-usability%40yahoogroups.com>
> > > <mailto:agile-usability%40yahoogroups.com> , Ron Jeffries
<ronjeffries@>

> > > wrote:
> > > >
> > > > Hello, Srinivas. On Tuesday, March 10, 2009, at 8:51:00 AM, you
> > > > wrote:
> > > >
> > > > > I agree to what you say , I would love to have Developers /
> Designers
> > to
> > > > > be in the same team but it is not possible
> > > >
> > > > Why? Are some of them in prison?
> > > >
> > > > > once example as i said earlier ... if developers and designer,

BA's
> > are
> > > > > working at the same time and if the screen design is done ...
and we
> > > > > test the design with the USERS ... it is not really possible
to get
> > > > > feedback from the USERS in 2 weeks or so.. by the time we get
the
> > > > > feedback from USERS developers are done with there coding ...
and if

> > we
> > > > > have some changes .. developers need to change the code ...
> > > >
> > > > Yes. This is an obstacle. You must remove it.
> > > >
> > > > Ron Jeffries
> > > > www.XProgramming.com
> > > > www.xprogramming.com/blog
> > > > Attend our CSM Plus Course!
> > > > http://hendricksonxp.com/index.php?option=com_eventlist
> > > <http://hendricksonxp.com/index.php?option=com_eventlist
> > <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>
> > &Itemid=28>
> > > &Itemid=28
> > > > Thousands of years ago, the first man discovered how to make

fire.
> > > > He was probably burned at the stake he had taught his brothers
to
> > > > light - Howard Roark (The Fountainhead, Ayn Rand)
> > > >
> > >
> >
>

[William Pietri]

Srinivas Manda wrote:

>
> *1) As people are working on two or three projects at  one time and
> sometimes its really hard to stay at one time ,
>
> 2) people may work remotely
>
> 3) developers buy some stories and designers buy some stories  for  AN
> ITERATION , reason  i already mentioned it earlier ...
> *
>

If you are concerned about productivity, I'd strongly recommend you
arrange things to minimize 1 and 2.

Multitasking has a high cost, one that is generally hidden from people
doing the multitasking because they are too busy with multitasking to
notice. There's some disagreement in the agile community about working
remotely, but I think everybody can agree that it an advanced agile
practice, and until your team is doing the basics perfectly, you'd be
wise to avoid the advanced things.

Regarding 3, I'd encourage you to move to a whole-team model, where a
cross-functional team, all sitting together, commits to work together.
Designers should still be doing some work on stories a bit ahead of
developers, but you don't have to manage that in lock-step with the
development iteration cycle.

William