Question_Agile Process_ UIE Virtual Seminar

[Srinivas Manda]

Hello Everyone...

I am referring to the model that is given in
UIE Virtual Seminar
The Essentials of Agile Development that is given by Jeff recently...
(SLIDE 30)

We are already working on this model but we have an issue.

Scenario: Assuming that we have six features to a project and business
and the designer will be working on "First feature" in Iteration ZERO
with the Requirements/ Screens / Spec for three weeks and they are done
with it. (in Iteration ZERO developers may not be ready to participate
with designer as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements /
Screens / Spec of the First feature to the developers so that they can
code it..   and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?

-laksinu

[William Pietri]

Srinivas Manda wrote:

>
> (in Iteration ZERO developers may not be ready to participate with
> designer as they will work on some other technical tasks)
>
> Once we move on to SECOND Iteration and we will give Requirements /
> Screens / Spec of the First feature to the developers so that they can
> code it..   and this is where the problem comes **
>
> *Problem:* If there is a technical problem/Limitation that arises for
> the designs that we already worked on ITERATION ZERO how do we handle it?
>

My easy three-step solution:

   1. Put everybody in the same room.
   2. When designers design, encourage them to frequently get feedback
      from the developers.
   3. When developers develop, encourage them to frequently get feedback
      from the designers.


I've seen this approach work well for quite a number of successful
teams. It turns out people are never too busy to talk with the guy
sitting right next to them, especially when it makes both of their jobs
easier.

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/

[Srinivas Manda]

Thanks William, the problem is in Agile you know that we always buy stories  and work on them in sprints ...
designers always do early designs so that it can be usability tested before developers actually code it ....


in  iteration zero if designers work on the features that time developers might buy some stories (technical) and they are busy with it...

  1.. Put everybody in the same room.
  if developers are working on other stories how can they be part of design stories

  2.. When designers design, encourage them to frequently get feedback from the developers.
  developers are busy with other stories how can they contribute of the stories that designers might have bought
   
  3.. When developers develop, encourage them to frequently get feedback from the designers.

-laksinu


  ----- Original Message -----
  From: William Pietri
  To: agile-usability@...
  Sent: Monday, March 09, 2009 4:38 PM
  Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar


  Srinivas Manda wrote:
    (in Iteration ZERO developers may not be ready to participate with designer as they will work on some other technical tasks)

    Once we move on to SECOND Iteration and we will give Requirements / Screens / Spec of the First feature to the developers so that they can code it..   and this is where the problem comes
    Problem: If there is a technical problem/Limitation that arises for the designs that we already worked on ITERATION ZERO how do we handle it?


  My easy three-step solution:


    1.. Put everybody in the same room.
    2.. When designers design, encourage them to frequently get feedback from the developers.
    3.. When developers develop, encourage them to frequently get feedback from the designers.

  I've seen this approach work well for quite a number of successful teams. It turns out people are never too busy to talk with the guy sitting right next to them, especially when it makes both of their jobs easier.

  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]

What do you mean when you say 'buy stories'.  I am unfamiliar with that
term.  It sounds like you have a supplier vendor relationship instead of a
collaborative one.

From what little I understand it seems you are attempting to retain a wall
between the developers, designers and the users.  If I may suggest, you
might find it interesting to think about beginning with defining everything
according to its value, which I take to be usability as it is the only item
worthy of testing.  However, by expanding the notion to value the customer
can now define the comparative worth of stuff they use based on its value to
them in getting the job at hand done.  This would expand the interaction of
all by merging their contributions to the customer value needs and thus
create a more complete test of usefulness.

 

Just a thought

 

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: Monday, March 09, 2009 7:03 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

Thanks William, the problem is in Agile you know that we always buy stories
and work on them in sprints ...
designers always do early designs so that it can be usability tested before
developers actually code it ....

in  iteration zero if designers work on the features that time developers
might buy some stories (technical) and they are busy with it...

 

1. Put everybody in the same room.
if developers are working on other stories how can they be part of design
stories
2. When designers design, encourage them to frequently get feedback
from the developers.
developers are busy with other stories how can they contribute of the
stories that designers might have bought
3. When developers develop, encourage them to frequently get feedback
from the designers.

 

-laksinu

 

 

----- Original Message -----

From: William Pietri <mailto:william@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 4:38 PM

Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

Srinivas Manda wrote:

(in Iteration ZERO developers may not be ready to participate with designer
as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements / Screens
/ Spec of the First feature to the developers so that they can code it..
and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?



My easy three-step solution:

1. Put everybody in the same room.
2. When designers design, encourage them to frequently get feedback
from the developers.
3. When developers develop, encourage them to frequently get feedback
from the designers.


I've seen this approach work well for quite a number of successful teams. It
turns out people are never too busy to talk with the guy sitting right next
to them, especially when it makes both of their jobs easier.

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/




 
 

[William Pietri]

Mike Dwyer wrote:
>
> What do you mean when you say 'buy stories'.  I am unfamiliar with
> that term.  It sounds like you have a supplier vendor relationship
> instead of a collaborative one.
>

I agree with your general thrust, Mike: a collaborative relationship is
the only way to go. One quibble, though.

Personally, I use the "buy stories" language a lot when I suspect people
aren't thinking strongly enough about real-world value. Often there will
be a big soup of things that they claim they absolutely must have, and
they are all equal priority. If I ask things like "which would you buy
first?" or "which one would you pay more for?" It can help break the logjam.

People have a lot of mental skills around shopping, so it can sometimes
be helpful to bring those to story prioritization.

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/

   

[Srinivas Manda]

Thanks Mike ....

in a project we usually take all the features and build them in the form of  " user stories"  and place all of these stories in the project backlog and we as a team take some of the stories  and buy them in each iteration.

example : -

say in total we have around 20 stories in the product backlog
say we have 4 iterations

5 stories x 4 iterations = 20 stories
and the entire project (20 stories that are in the backlog) can be done in 4 iterations ....

each iteration has 5  stories that team buys based on the priority  that is what i mean
by "buy stories"..


let me know if you have questions ....

-srinivas

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


  ----- Original Message -----
  From: Mike Dwyer
  To: agile-usability@...
  Sent: Monday, March 09, 2009 6:40 PM
  Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual Seminar



  What do you mean when you say 'buy stories'.  I am unfamiliar with that term.  It sounds like you have a supplier vendor relationship instead of a collaborative one.
  From what little I understand it seems you are attempting to retain a wall between the developers, designers and the users.  If I may suggest, you might find it interesting to think about beginning with defining everything according to its value, which I take to be usability as it is the only item worthy of testing.  However, by expanding the notion to value the customer can now define the comparative worth of stuff they use based on its value to them in getting the job at hand done.  This would expand the interaction of all by merging their contributions to the customer value needs and thus create a more complete test of usefulness.

  Just a thought

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


  From: Srinivas Manda [mailto:laksinu@...]
  Sent: Monday, March 09, 2009 7:03 PM
  To: agile-usability@...
  Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

  Thanks William, the problem is in Agile you know that we always buy stories  and work on them in sprints ...
  designers always do early designs so that it can be usability tested before developers actually code it ....
  in  iteration zero if designers work on the features that time developers might buy some stories (technical) and they are busy with it...

    1.. Put everybody in the same room.
    if developers are working on other stories how can they be part of design stories
    2.. When designers design, encourage them to frequently get feedback from the developers.
    developers are busy with other stories how can they contribute of the stories that designers might have bought
    3.. When developers develop, encourage them to frequently get feedback from the designers.

  -laksinu


    ----- Original Message -----
    From: William Pietri
    To: agile-usability@...
    Sent: Monday, March 09, 2009 4:38 PM
    Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

    Srinivas Manda wrote:
      (in Iteration ZERO developers may not be ready to participate with designer as they will work on some other technical tasks)

      Once we move on to SECOND Iteration and we will give Requirements / Screens / Spec of the First feature to the developers so that they can code it..   and this is where the problem comes
      Problem: If there is a technical problem/Limitation that arises for the designs that we already worked on ITERATION ZERO how do we handle it?


    My easy three-step solution:
      1.. Put everybody in the same room.
      2.. When designers design, encourage them to frequently get feedback from the developers.
      3.. When developers develop, encourage them to frequently get feedback from the designers.

    I've seen this approach work well for quite a number of successful teams. It turns out people are never too busy to talk with the guy sitting right next to them, especially when it makes both of their jobs easier.

    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/


 

[William Pietri]

The way I normally apply Agile methods, teams work on things together.

If your product needs developers and designers, I think they should be
on the same team. At the beginning of the sprint, the product manager
picks stories for the team to do, and over the course of the sprint, the
team completes team. When the team succeeds, they succeed together. And
when they fail, they also fail together.

It's true that at any given moment, a given individual may be working on
a given story. But I think things work best when the relationship
between an individual and a story is relatively loose and arrived at
dynamically. My most successful clients have designers and developers
working together fluidly based on what the story needs at the time.

Does that help answer your question?

William

Srinivas Manda wrote:

> Thanks William, the problem is in Agile you know that we always buy
> stories  and work on them in sprints ...
> designers always do early designs so that it can be usability tested
> before developers actually code it ....
>
> in  iteration zero if designers work on the features that time
> developers might buy some stories (technical) and they are busy with it...
>  
>
>    1. Put everybody in the same room.
>       if developers are working on other stories how can they be part
>       of design stories
>    2. When designers design, encourage them to frequently get feedback
>       from the developers.
>       developers are busy with other stories how can they contribute
>       of the stories that designers might have bought
>    3. When developers develop, encourage them to frequently get
>       feedback from the designers.
>
>  
> -laksinu
>  
>  
>
>     ----- Original Message -----
>     *From:* William Pietri <mailto:william@...>
>     *To:* agile-usability@...
>     <mailto:agile-usability@...>
>     *Sent:* Monday, March 09, 2009 4:38 PM
>     *Subject:* Re: [agile-usability] Question_Agile Process_ UIE
>     Virtual Seminar
>
>     Srinivas Manda wrote:
>
>>     (in Iteration ZERO developers may not be ready to participate
>>     with designer as they will work on some other technical tasks)
>>
>>     Once we move on to SECOND Iteration and we will give Requirements
>>     / Screens / Spec of the First feature to the developers so that
>>     they can code it..   and this is where the problem comes **
>>
>>     *Problem:* If there is a technical problem/Limitation that arises
>>     for the designs that we already worked on ITERATION ZERO how do
>>     we handle it?
>>
>
>
>     My easy three-step solution:
>
>        1. Put everybody in the same room.
>        2. When designers design, encourage them to frequently get
>           feedback from the developers.
>        3. When developers develop, encourage them to frequently get
>           feedback from the designers.
>
>
>     I've seen this approach work well for quite a number of successful
>     teams. It turns out people are never too busy to talk with the guy
>     sitting right next to them, especially when it makes both of their
>     jobs easier.
>
>     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]

I use the same terms and the same words (sans buy) to do something a bit
different.

All stories accepted into a sprint/iteration must be completed within that
sprint.  Completed requires they have associated with them a traceablity to
the value proposition the product owner can sign up with.  Completed occurs
when the measurable indicators associated with that story are met.  So
William's muddle is taken and decomposed as the inability of the Product
owner to identify measurable for the value of a story provide the shoice
criteria for a story be tgaken into an iteration.

 

I also have a problem with the notion there is a 'project backlog'  this
assumes that all stories are associated with a single project.  In the world
that I work in as many as 17 teams have been working on a dozen projects all
under the umbrella of a very large program.  I can understand how a UI
perception of work would see this scale and scope as the future of UI is the
challenged with providing a user a common experience through an endless
variety of devices and interfaces so that the way a user gets what they want
has to be consistent despite the different capabilities and limitations of
the vehicle used.

 

We have already faced the challenge of the limit of thinking in project
terms and offer this learning.  There is a product backlog where stories are
kept and as the story's value is understood, the story is moved into
releases where it eventually ends up being delivered in such a way  as to be
valuable to the user

 

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: Monday, March 09, 2009 8:58 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

Thanks Mike ....

 

in a project we usually take all the features and build them in the form of
" user stories"  and place all of these stories in the project backlog and
we as a team take some of the stories  and buy them in each iteration.

 

example : -

 

say in total we have around 20 stories in the product backlog

say we have 4 iterations

 

5 stories x 4 iterations = 20 stories
and the entire project (20 stories that are in the backlog) can be done in 4
iterations ....

 

each iteration has 5  stories that team buys based on the priority  that is
what i mean
by "buy stories"..

 

 

let me know if you have questions ....

 

-srinivas

 

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

 

 

----- Original Message -----

From: Mike Dwyer <mailto:mdwyer@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 6:40 PM

Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

What do you mean when you say 'buy stories'.  I am unfamiliar with that
term.  It sounds like you have a supplier vendor relationship instead of a
collaborative one.

From what little I understand it seems you are attempting to retain a wall
between the developers, designers and the users.  If I may suggest, you
might find it interesting to think about beginning with defining everything
according to its value, which I take to be usability as it is the only item
worthy of testing.  However, by expanding the notion to value the customer
can now define the comparative worth of stuff they use based on its value to
them in getting the job at hand done.  This would expand the interaction of
all by merging their contributions to the customer value needs and thus
create a more complete test of usefulness.

Just a thought

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: Monday, March 09, 2009 7:03 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

Thanks William, the problem is in Agile you know that we always buy stories
and work on them in sprints ...
designers always do early designs so that it can be usability tested before
developers actually code it ....

in  iteration zero if designers work on the features that time developers
might buy some stories (technical) and they are busy with it...

1. Put everybody in the same room.
if developers are working on other stories how can they be part of design
stories
2. When designers design, encourage them to frequently get feedback
from the developers.
developers are busy with other stories how can they contribute of the
stories that designers might have bought
3. When developers develop, encourage them to frequently get feedback
from the designers.

-laksinu

----- Original Message -----

From: William Pietri <mailto:william@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 4:38 PM

Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

Srinivas Manda wrote:

(in Iteration ZERO developers may not be ready to participate with designer
as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements / Screens
/ Spec of the First feature to the developers so that they can code it..
and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?



My easy three-step solution:

1. Put everybody in the same room.
2. When designers design, encourage them to frequently get feedback
from the developers.
3. When developers develop, encourage them to frequently get feedback
from the designers.


I've seen this approach work well for quite a number of successful teams. It
turns out people are never too busy to talk with the guy sitting right next
to them, especially when it makes both of their jobs easier.

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]

To put forth an even more fundamental notion William.  A team begins as a
collection of people whose skills and motivation can deliver value.  As the
collection learns to wrok and compliment each other's strengths and weakness
a rhythm and balance evolves where everyone contributes to the point that
all are amazed at what they can do as one.

 

Mike Dwyer
Principal, Agile Coach

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

cell:   [phone]

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

 

 

From: William Pietri [mailto:william@...]
Sent: Monday, March 09, 2009 9:04 PM
To: agile-usability@...
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 


The way I normally apply Agile methods, teams work on things together.

If your product needs developers and designers, I think they should be on
the same team. At the beginning of the sprint, the product manager picks
stories for the team to do, and over the course of the sprint, the team
completes team. When the team succeeds, they succeed together. And when they
fail, they also fail together.

It's true that at any given moment, a given individual may be working on a
given story. But I think things work best when the relationship between an
individual and a story is relatively loose and arrived at dynamically. My
most successful clients have designers and developers working together
fluidly based on what the story needs at the time.

Does that help answer your question?

William

Srinivas Manda wrote:

Thanks William, the problem is in Agile you know that we always buy stories
and work on them in sprints ...
designers always do early designs so that it can be usability tested before
developers actually code it ....

in  iteration zero if designers work on the features that time developers
might buy some stories (technical) and they are busy with it...

 

1. Put everybody in the same room.
if developers are working on other stories how can they be part of design
stories
2. When designers design, encourage them to frequently get feedback
from the developers.
developers are busy with other stories how can they contribute of the
stories that designers might have bought
3. When developers develop, encourage them to frequently get feedback
from the designers.

 

-laksinu

 

 

----- Original Message -----

From: William Pietri <mailto:william@...>  

To: agile-usability@...

Sent: Monday, March 09, 2009 4:38 PM

Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar

 

Srinivas Manda wrote:

(in Iteration ZERO developers may not be ready to participate with designer
as they will work on some other technical tasks)

Once we move on to SECOND Iteration and we will give Requirements / Screens
/ Spec of the First feature to the developers so that they can code it..
and this is where the problem comes

Problem: If there is a technical problem/Limitation that arises for the
designs that we already worked on ITERATION ZERO how do we handle it?



My easy three-step solution:

1. Put everybody in the same room.
2. When designers design, encourage them to frequently get feedback
from the developers.
3. When developers develop, encourage them to frequently get feedback
from the designers.


I've seen this approach work well for quite a number of successful teams. It
turns out people are never too busy to talk with the guy sitting right next
to them, especially when it makes both of their jobs easier.

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/

 




 
 

[Adrian Howard]

On 9 Mar 2009, at 21:38, William Pietri wrote:

> Srinivas Manda wrote:
>>
>> (in Iteration ZERO developers may not be ready to participate with  
>> designer as they will work on some other technical tasks)
>>
>> Once we move on to SECOND Iteration and we will give Requirements /  
>> Screens / Spec of the First feature to the developers so that they  
>> can code it..   and this is where the problem comes **
>>
>> *Problem:* If there is a technical problem/Limitation that arises  
>> for the designs that we already worked on ITERATION ZERO how do we  
>> handle it?
>>
>
>
> My easy three-step solution:
>
>  1. Put everybody in the same room.
>  2. When designers design, encourage them to frequently get feedback
>     from the developers.
>  3. When developers develop, encourage them to frequently get feedback
>     from the designers.

++ to that.

Adrian

[Srinivas Manda]

I agree to what you say , I would love to have Developers / Designers to
be in the same team but it is not possible

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 ...

-Laksinu




--- In agile-usability@..., William Pietri <william@...>
wrote:
>
>
> The way I normally apply Agile methods, teams work on things together.
>
> If your product needs developers and designers, I think they should be
> on the same team. At the beginning of the sprint, the product manager
> picks stories for the team to do, and over the course of the sprint,
the
> team completes team. When the team succeeds, they succeed together.
And
> when they fail, they also fail together.
>
> It's true that at any given moment, a given individual may be working
on

> a given story. But I think things work best when the relationship
> between an individual and a story is relatively loose and arrived at
> dynamically. My most successful clients have designers and developers
> working together fluidly based on what the story needs at the time.
>
> Does that help answer your question?
>
> William
>
> Srinivas Manda wrote:
> > Thanks William, the problem is in Agile you know that we always buy
> > stories and work on them in sprints ...
> > designers always do early designs so that it can be usability tested
> > before developers actually code it ....
> >
> > in iteration zero if designers work on the features that time
> > developers might buy some stories (technical) and they are busy with

it...

> >
> >
> > 1. Put everybody in the same room.
> > if developers are working on other stories how can they be part
> > of design stories
> > 2. When designers design, encourage them to frequently get feedback
> > from the developers.
> > developers are busy with other stories how can they contribute
> > of the stories that designers might have bought
> > 3. When developers develop, encourage them to frequently get
> > feedback from the designers.
> >
> >
> > -laksinu
> >
> >
> >
> > ----- Original Message -----
> > *From:* William Pietri <mailto:william@...
> > *To:* agile-usability@...
> > <mailto:agile-usability@...
> > *Sent:* Monday, March 09, 2009 4:38 PM
> > *Subject:* Re: [agile-usability] Question_Agile Process_ UIE
> > Virtual Seminar
> >
> > Srinivas Manda wrote:
> >
> >> (in Iteration ZERO developers may not be ready to participate
> >> with designer as they will work on some other technical tasks)
> >>
> >> Once we move on to SECOND Iteration and we will give Requirements
> >> / Screens / Spec of the First feature to the developers so that
> >> they can code it.. and this is where the problem comes **
> >>
> >> *Problem:* If there is a technical problem/Limitation that arises
> >> for the designs that we already worked on ITERATION ZERO how do
> >> we handle it?
> >>
> >
> >
> > My easy three-step solution:
> >
> > 1. Put everybody in the same room.
> > 2. When designers design, encourage them to frequently get
> > feedback from the developers.
> > 3. When developers develop, encourage them to frequently get
> > feedback from the designers.
> >
> >
> > I've seen this approach work well for quite a number of successful
> > teams. It turns out people are never too busy to talk with the guy
> > sitting right next to them, especially when it makes both of their
> > jobs easier.
> >
> > 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/
> >
> >
> >
> >
> >
>

[William Pietri]

Srinivas Manda 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
>

In that case, are you sure you should be using an Agile approach? It
doesn't sound like your environment is a good fit. I'd recommend looking
at some other development method.

William

[Ron Jeffries]

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&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)

[Nancy Frishberg]

Srinivas (and all),

I as a UX team member would want to get user input in a variety of  
ways. Usability evaluation is a good one, and with a coordinated team,  
it can happen within an amount of time that it can serve as input to  
revision prior to the programming get too far ahead.  And there are at  
least a dozen other techniques.  Some of them can extend over several  
sprints.

Rather than have the developers or even the developers and the UX  
folks buy stories, I'd like to have users buy stories!   Buying is  
only one of several metaphors that you can use.

Additional advantage of getting in front of users:  Having users rank  
or sort or arrange or buy stories means you get feedback on how well  
the team has been channeling the known stories, revisions to stories  
and new stories that you haven't thought of (because you're not the  
users of the target product, you don't operate in the work settings  
they do, and you don't manage their specific tasks with their  
interruptions, you don't have their background and they don't have  
yours).  Product owners can stand in for users or customers only so far.

Plus, it's fun.

May I invite you and others to join us at Usability Professionals  
Association's 2009 meeting in Portland Oregon, where I'll be  
moderating a panel about "Agile User Experience:
Strategy and Design Research above and beyond Sprint 0" on the last  
morning?  I expect a lively discussion, especially if *you're* there!
http://www.usabilityprofessionals.org/conference/2009/ (Early  
registration will open today or later this week.)

  -- Nancy

Nancy Frishberg [phone] mobile
nancyf@...
Certified Innovation Games® Facilitator
http://www.linkedin.com/in/nfrishberg

On Mar 9, 2009, at 5:58 PM, Srinivas Manda wrote:

> Thanks Mike ....
>
> in a project we usually take all the features and build them in the  
> form of  " user stories"  and place all of these stories in the  
> project backlog and we as a team take some of the stories  and buy  
> them in each iteration.
>
> example : -
>
> say in total we have around 20 stories in the product backlog
> say we have 4 iterations
>
> 5 stories x 4 iterations = 20 stories
> and the entire project (20 stories that are in the backlog) can be  
> done in 4 iterations ....
>
> each iteration has 5  stories that team buys based on the priority  
> that is what i mean
> by "buy stories"..
>
>
> let me know if you have questions ....
>
> -srinivas
>
> ----------------------------------------------------------------------------------
>
>
> ----- Original Message -----
> From: Mike Dwyer
> To: agile-usability@...
> Sent: Monday, March 09, 2009 6:40 PM
> Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual  
> Seminar
>
>
> What do you mean when you say ‘buy stories’.  I am unfamiliar with  
> that term.  It sounds like you have a supplier vendor relationship  
> instead of a collaborative one.
>
> From what little I understand it seems you are attempting to retain  
> a wall between the developers, designers and the users.  If I may  
> suggest, you might find it interesting to think about beginning with  
> defining everything according to its value, which I take to be  
> usability as it is the only item worthy of testing.  However, by  
> expanding the notion to value the customer can now define the  
> comparative worth of stuff they use based on its value to them in  
> getting the job at hand done.  This would expand the interaction of  
> all by merging their contributions to the customer value needs and  
> thus create a more complete test of usefulness.
>
>
> Just a thought
>
>
> Mike Dwyer
> Principal, Agile Coach
>
> BigVisible Solutions
> url:    http://www.bigvisible.com
>
> cell:   [phone]
>
> email: mdwyer@...
>
>
>
> From: Srinivas Manda [mailto:laksinu@...]
> Sent: Monday, March 09, 2009 7:03 PM
> To: agile-usability@...
> Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual  
> Seminar
>
>
> Thanks William, the problem is in Agile you know that we always buy  
> stories  and work on them in sprints ...
> designers always do early designs so that it can be usability tested  
> before developers actually code it ....
>
> in  iteration zero if designers work on the features that time  
> developers might buy some stories (technical) and they are busy with  
> it...
>
>
> Put everybody in the same room.
> if developers are working on other stories how can they be part of  
> design stories
> When designers design, encourage them to frequently get feedback  
> from the developers.
> developers are busy with other stories how can they contribute of  
> the stories that designers might have bought
> When developers develop, encourage them to frequently get feedback  
> from the designers.
>
> -laksinu
>
>
>
> ----- Original Message -----
>
> From: William Pietri
>
> To: agile-usability@...
>
> Sent: Monday, March 09, 2009 4:38 PM
>
> Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual  
> Seminar
>
>
> Srinivas Manda wrote:
>
> (in Iteration ZERO developers may not be ready to participate with  
> designer as they will work on some other technical tasks)
>
> Once we move on to SECOND Iteration and we will give Requirements /  
> Screens / Spec of the First feature to the developers so that they  
> can code it..   and this is where the problem comes
>
> Problem: If there is a technical problem/Limitation that arises for  
> the designs that we already worked on ITERATION ZERO how do we  
> handle it?
>
>
>
> My easy three-step solution:
>
> Put everybody in the same room.
> When designers design, encourage them to frequently get feedback  
> from the developers.
> When developers develop, encourage them to frequently get feedback  
> from the designers.
>
> I've seen this approach work well for quite a number of successful  
> teams. It turns out people are never too busy to talk with the guy  
> sitting right next to them, especially when it makes both of their  
> jobs easier.
>
> 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/
>
>
>
>
>
>

[Srinivas Manda]

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@..., 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&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]

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@...
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> , 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&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]

Nancy... when I refer to the product backlog , all the stories that are there in the product backlog came from users and those are what users asked for .. Basically we prioritize them and try to complete them in a project...

And on second thought once UI designer is done with the design we take them back to users and get a feedback from them.. And that is when developers start coding here we do not see any rework unless if there is a technical limitation...

-Srinivas

--- In agile-usability@..., Nancy Frishberg <nancyf@...> wrote:

>
> Srinivas (and all),
>
> I as a UX team member would want to get user input in a variety of  
> ways. Usability evaluation is a good one, and with a coordinated team,  
> it can happen within an amount of time that it can serve as input to  
> revision prior to the programming get too far ahead.  And there are at  
> least a dozen other techniques.  Some of them can extend over several  
> sprints.
>
> Rather than have the developers or even the developers and the UX  
> folks buy stories, I'd like to have users buy stories!   Buying is  
> only one of several metaphors that you can use.
>
> Additional advantage of getting in front of users:  Having users rank  
> or sort or arrange or buy stories means you get feedback on how well  
> the team has been channeling the known stories, revisions to stories  
> and new stories that you haven't thought of (because you're not the  
> users of the target product, you don't operate in the work settings  
> they do, and you don't manage their specific tasks with their  
> interruptions, you don't have their background and they don't have  
> yours).  Product owners can stand in for users or customers only so far.
>
> Plus, it's fun.
>
> May I invite you and others to join us at Usability Professionals  
> Association's 2009 meeting in Portland Oregon, where I'll be  
> moderating a panel about "Agile User Experience:
> Strategy and Design Research above and beyond Sprint 0" on the last  
> morning?  I expect a lively discussion, especially if *you're* there!
> http://www.usabilityprofessionals.org/conference/2009/ (Early  
> registration will open today or later this week.)
>
>   -- Nancy
>
> Nancy Frishberg [phone] mobile
> nancyf@...
> Certified Innovation Games® Facilitator
> http://www.linkedin.com/in/nfrishberg
>
> On Mar 9, 2009, at 5:58 PM, Srinivas Manda wrote:
>
> > Thanks Mike ....
> >
> > in a project we usually take all the features and build them in the  
> > form of  " user stories"  and place all of these stories in the  
> > project backlog and we as a team take some of the stories  and buy  
> > them in each iteration.
> >
> > example : -
> >
> > say in total we have around 20 stories in the product backlog
> > say we have 4 iterations
> >
> > 5 stories x 4 iterations = 20 stories
> > and the entire project (20 stories that are in the backlog) can be  
> > done in 4 iterations ....
> >
> > each iteration has 5  stories that team buys based on the priority  
> > that is what i mean
> > by "buy stories"..
> >
> >
> > let me know if you have questions ....
> >
> > -srinivas
> >
> > ----------------------------------------------------------------------------------
> >
> >
> > ----- Original Message -----
> > From: Mike Dwyer
> > To: agile-usability@...
> > Sent: Monday, March 09, 2009 6:40 PM
> > Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual  
> > Seminar
> >
> >
> > What do you mean when you say `buy stories'.  I am unfamiliar with  
> > that term.  It sounds like you have a supplier vendor relationship  
> > instead of a collaborative one.
> >
> > From what little I understand it seems you are attempting to retain  
> > a wall between the developers, designers and the users.  If I may  
> > suggest, you might find it interesting to think about beginning with  
> > defining everything according to its value, which I take to be  
> > usability as it is the only item worthy of testing.  However, by  
> > expanding the notion to value the customer can now define the  
> > comparative worth of stuff they use based on its value to them in  
> > getting the job at hand done.  This would expand the interaction of  
> > all by merging their contributions to the customer value needs and  
> > thus create a more complete test of usefulness.
> >
> >
> > Just a thought
> >
> >
> > Mike Dwyer
> > Principal, Agile Coach
> >
> > BigVisible Solutions
> > url:    http://www.bigvisible.com
> >
> > cell:   [phone]
> >
> > email: mdwyer@...
> >
> >
> >
> > From: Srinivas Manda [mailto:laksinu@...]
> > Sent: Monday, March 09, 2009 7:03 PM
> > To: agile-usability@...
> > Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual  
> > Seminar
> >
> >
> > Thanks William, the problem is in Agile you know that we always buy  
> > stories  and work on them in sprints ...
> > designers always do early designs so that it can be usability tested  
> > before developers actually code it ....
> >
> > in  iteration zero if designers work on the features that time  
> > developers might buy some stories (technical) and they are busy with  
> > it...
> >
> >
> > Put everybody in the same room.
> > if developers are working on other stories how can they be part of  
> > design stories
> > When designers design, encourage them to frequently get feedback  
> > from the developers.
> > developers are busy with other stories how can they contribute of  
> > the stories that designers might have bought
> > When developers develop, encourage them to frequently get feedback  
> > from the designers.
> >
> > -laksinu
> >
> >
> >
> > ----- Original Message -----
> >
> > From: William Pietri
> >
> > To: agile-usability@...
> >
> > Sent: Monday, March 09, 2009 4:38 PM
> >
> > Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual  
> > Seminar
> >
> >
> > Srinivas Manda wrote:
> >
> > (in Iteration ZERO developers may not be ready to participate with  
> > designer as they will work on some other technical tasks)
> >
> > Once we move on to SECOND Iteration and we will give Requirements /  
> > Screens / Spec of the First feature to the developers so that they  
> > can code it..   and this is where the problem comes
> >
> > Problem: If there is a technical problem/Limitation that arises for  
> > the designs that we already worked on ITERATION ZERO how do we  
> > handle it?
> >
> >
> >
> > My easy three-step solution:
> >
> > Put everybody in the same room.
> > When designers design, encourage them to frequently get feedback  
> > from the developers.
> > When developers develop, encourage them to frequently get feedback  
> > from the designers.
> >
> > I've seen this approach work well for quite a number of successful  
> > teams. It turns out people are never too busy to talk with the guy  
> > sitting right next to them, especially when it makes both of their  
> > jobs easier.
> >
> > 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/
> >
> >
> >
> >
> >
> >
>

[Srinivas Manda]

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@..., "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@...
> 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> , 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&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)
> >
>

[Nancy Frishberg]

Srinivas,

May I suggest Desiree Sy's article if you haven't seen it yet?  http://www.usabilityprofessionals.org/upa_publications/jus/2007may/agile-ucd.pdf

Sounds like you need to break the design and research bits into  
smaller chunks, iterate more frequently, and be patient with yourself/
yourselves:  there's a learning curve there.  From various people,  
I've heard the folk wisdom that it takes about 6 months of iterating/
sprinting together to get the team to function smoothly as a team.  
I've been a consulting user researcher to several teams, but not  
fulltime with a team moving through this process themselves.

Glad to hear you got user input early for your product.  Sorry to  
learn that you only have one opportunity for users to refine what they  
might mean.  Or for your team to hear what the users meant in the  
first place but couldn't express within the constraints provided.  How  
will you create breakthrough products?  You need many touchpoints with  
customers and users.

Don't know yet how the time is adjusted or what tools help most when  
you're not all in one physical location.  Yet, it's true for many  
Agile teams that you're distributed around the globe or just in 2 or 3  
locations in a metro area.

  -- Nancy

On Mar 10, 2009, at 2:02 PM, Srinivas Manda wrote:

> Nancy... when I refer to the product backlog , all the stories that  
> are there in the product backlog came from users and those are what  
> users asked for .. Basically we prioritize them and try to complete  
> them in a project...
>
> And on second thought once UI designer is done with the design we  
> take them back to users and get a feedback from them.. And that is  
> when developers start coding here we do not see any rework unless if  
> there is a technical limitation...
>
> -Srinivas
>
> --- In agile-usability@..., Nancy Frishberg <nancyf@...>  
> wrote:
>>
>> Srinivas (and all),
>>
>> I as a UX team member would want to get user input in a variety of
>> ways. Usability evaluation is a good one, and with a coordinated  
>> team,
>> it can happen within an amount of time that it can serve as input to
>> revision prior to the programming get too far ahead.  And there are  
>> at
>> least a dozen other techniques.  Some of them can extend over several
>> sprints.
>>
>> Rather than have the developers or even the developers and the UX
>> folks buy stories, I'd like to have users buy stories!   Buying is
>> only one of several metaphors that you can use.
>>
>> Additional advantage of getting in front of users:  Having users rank
>> or sort or arrange or buy stories means you get feedback on how well
>> the team has been channeling the known stories, revisions to stories
>> and new stories that you haven't thought of (because you're not the
>> users of the target product, you don't operate in the work settings
>> they do, and you don't manage their specific tasks with their
>> interruptions, you don't have their background and they don't have
>> yours).  Product owners can stand in for users or customers only so  
>> far.
>>
>> Plus, it's fun.
>>
>> May I invite you and others to join us at Usability Professionals
>> Association's 2009 meeting in Portland Oregon, where I'll be
>> moderating a panel about "Agile User Experience:
>> Strategy and Design Research above and beyond Sprint 0" on the last
>> morning?  I expect a lively discussion, especially if *you're* there!
>> http://www.usabilityprofessionals.org/conference/2009/ (Early
>> registration will open today or later this week.)
>>
>>  -- Nancy
>>
>> Nancy Frishberg [phone] mobile
>> nancyf@...
>> Certified Innovation Games® Facilitator
>> http://www.linkedin.com/in/nfrishberg
>>
>> On Mar 9, 2009, at 5:58 PM, Srinivas Manda wrote:
>>
>>> Thanks Mike ....
>>>
>>> in a project we usually take all the features and build them in the
>>> form of  " user stories"  and place all of these stories in the
>>> project backlog and we as a team take some of the stories  and buy
>>> them in each iteration.
>>>
>>> example : -
>>>
>>> say in total we have around 20 stories in the product backlog
>>> say we have 4 iterations
>>>
>>> 5 stories x 4 iterations = 20 stories
>>> and the entire project (20 stories that are in the backlog) can be
>>> done in 4 iterations ....
>>>
>>> each iteration has 5  stories that team buys based on the priority
>>> that is what i mean
>>> by "buy stories"..
>>>
>>>
>>> let me know if you have questions ....
>>>
>>> -srinivas
>>>
>>> ----------------------------------------------------------------------------------
>>>
>>>
>>> ----- Original Message -----
>>> From: Mike Dwyer
>>> To: agile-usability@...
>>> Sent: Monday, March 09, 2009 6:40 PM
>>> Subject: RE: [agile-usability] Question_Agile Process_ UIE Virtual
>>> Seminar
>>>
>>>
>>> What do you mean when you say `buy stories'.  I am unfamiliar with
>>> that term.  It sounds like you have a supplier vendor relationship
>>> instead of a collaborative one.
>>>
>>> From what little I understand it seems you are attempting to retain
>>> a wall between the developers, designers and the users.  If I may
>>> suggest, you might find it interesting to think about beginning with
>>> defining everything according to its value, which I take to be
>>> usability as it is the only item worthy of testing.  However, by
>>> expanding the notion to value the customer can now define the
>>> comparative worth of stuff they use based on its value to them in
>>> getting the job at hand done.  This would expand the interaction of
>>> all by merging their contributions to the customer value needs and
>>> thus create a more complete test of usefulness.
>>>
>>>
>>> Just a thought
>>>
>>>
>>> Mike Dwyer
>>> Principal, Agile Coach
>>>
>>> BigVisible Solutions
>>> url:    http://www.bigvisible.com
>>>
>>> cell:   [phone]
>>>
>>> email: mdwyer@...
>>>
>>>
>>>
>>> From: Srinivas Manda [mailto:laksinu@...]
>>> Sent: Monday, March 09, 2009 7:03 PM
>>> To: agile-usability@...
>>> Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual
>>> Seminar
>>>
>>>
>>> Thanks William, the problem is in Agile you know that we always buy
>>> stories  and work on them in sprints ...
>>> designers always do early designs so that it can be usability tested
>>> before developers actually code it ....
>>>
>>> in  iteration zero if designers work on the features that time
>>> developers might buy some stories (technical) and they are busy with
>>> it...
>>>
>>>
>>> Put everybody in the same room.
>>> if developers are working on other stories how can they be part of
>>> design stories
>>> When designers design, encourage them to frequently get feedback
>>> from the developers.
>>> developers are busy with other stories how can they contribute of
>>> the stories that designers might have bought
>>> When developers develop, encourage them to frequently get feedback
>>> from the designers.
>>>
>>> -laksinu
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>> From: William Pietri
>>>
>>> To: agile-usability@...
>>>
>>> Sent: Monday, March 09, 2009 4:38 PM
>>>
>>> Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual
>>> Seminar
>>>
>>>
>>> Srinivas Manda wrote:
>>>
>>> (in Iteration ZERO developers may not be ready to participate with
>>> designer as they will work on some other technical tasks)
>>>
>>> Once we move on to SECOND Iteration and we will give Requirements /
>>> Screens / Spec of the First feature to the developers so that they
>>> can code it..   and this is where the problem comes
>>>
>>> Problem: If there is a technical problem/Limitation that arises for
>>> the designs that we already worked on ITERATION ZERO how do we
>>> handle it?
>>>
>>>
>>>
>>> My easy three-step solution:
>>>
>>> Put everybody in the same room.
>>> When designers design, encourage them to frequently get feedback
>>> from the developers.
>>> When developers develop, encourage them to frequently get feedback
>>> from the designers.
>>>
>>> I've seen this approach work well for quite a number of successful
>>> teams. It turns out people are never too busy to talk with the guy
>>> sitting right next to them, especially when it makes both of their
>>> jobs easier.
>>>
>>> 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/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Nancy Frishberg [phone] mobile
nancyf@...

[Mike Dwyer-2]

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.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)
> >
>