RE: Question_Agile Process_ UIE Virtual Seminar

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:   (978) 376-4422

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@... - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
We'd love feedback on our new blog: http://agilefocus.com/