Question_Agile Process_ UIE Virtual Seminar

[Marjorie H Pries]

Srinivas wrote:
" 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
...  "
 
I give up. Don't try to be agile. Design and prototype the whole
application. then hand it off to the developers and test it when it's
done. Charter a second release and plan to fix everything that needs to
change in the second release. Sounds like everyone on your team will be
much happier that way. Don't kill yourself trying to be what you are not.



Marjorie H. Pries
Lead Consultant / Utility Infielder

ThoughtWorks, Inc.
http://www.thoughtworks.com

"Don't believe everything you think."
     --seen on a bumpersticker

[Srinivas Manda]

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

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

Srinivas - I agree to what you say we would like to sit together and
that is what AGILE says , if everyone is working on same set of features
for 3 weeks then

1)  when do we have time to do a usability test to the feature that we
worked on with the end users and get feedback from them   ?  cause we
may take the whole 3 weeks to work on a set of feature ...  say if we do
the test after the iteration and we get some feedback from user ..if it
is a good amount of change then should there be a rework and that
extends the project deadline ..




>
> William
>

[William Pietri]

Srinivas Manda wrote:
>
> **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 .**
>

Do you think that behavior is a useful one?

To me, when a product owner behaves like that, it can be a sign that the
development team has issues that should be addressed by adopting various
technical practices. If changing the code is quick and easy, then the
product manager doesn't need to pre-test everything to death. But if
changing the code is hard, risky, or slow, then their behavior may be
perfectly reasonable.


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

In which case, your company culture may be a poor fit for Agile methods.

For the companies I see doing the best with Agile approaches, they have
cross-functional teams that are strongly focused on specific products,
audiences, or interactions. There may be specialists in the company that
float, and resources that teams pull in as needed. But by and large,
Agile is strongly team-oriented.


William

[William Pietri]

James Page wrote:
> 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.

I think this was an argument waiting to happen.

For a long time, development processes have unintentionally excluded
designers. Some of the methods that designers have created also treat
design as a very separate activity. But if we want to build great
products, I think we do have to work side by side.

I think Agile approaches both force and reward that merging of tribes,
and I think a lot of the heat around this would have come no matter what
was forcing people to confront this old and unnecessarily deep divide.

But it will be a great relief when I don't have to hear about it
anymore, the way I no longer have to hear much about suits vs. geeks feuds.

William

[Adrian Howard]

On 11 Mar 2009, at 16:24, William Pietri wrote:
[snip]

> I think this was an argument waiting to happen.
>
> For a long time, development processes have unintentionally excluded  
> designers. Some of the methods that designers have created also  
> treat design as a very separate activity. But if we want to build  
> great products, I think we do have to work side by side.
>
> I think Agile approaches both force and reward that merging of  
> tribes, and I think a lot of the heat around this would have come no  
> matter what was forcing people to confront this old and  
> unnecessarily deep divide.
>
> But it will be a great relief when I don't have to hear about it  
> anymore, the way I no longer have to hear much about suits vs. geeks  
> feuds.

Amen!

Adrian
--
delicious.com/adrianh - twitter.com/adrianh - adrianh@...

[Srinivas Manda]

--- In agile-usability@..., William Pietri <william@...>
wrote:
>
> Srinivas Manda wrote:
> >
> > **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 .**
> >
>
> Do you think that behavior is a useful one?
>
> To me, when a product owner behaves like that, it can be a sign that
the
> development team has issues that should be addressed by adopting
various
> technical practices. If changing the code is quick and easy, then the
> product manager doesn't need to pre-test everything to death. But if
> changing the code is hard, risky, or slow, then their behavior may be
> perfectly reasonable.
>
>
> > *Srinivas : We cannot tell to Management that we only want to work
on
> > 1 project.... that does not WORK*
> >
>
> In which case, your company culture may be a poor fit for Agile
methods.

This is the catch here – Developers , Testing are always full time
and they work on only 1 project but designers , usability folks ,
Database are some sort of Specialty roles and we work on multiple
projects at  a time I am not sure if this is same elsewhere and this is
where the problem arises when working with Agile ....


>
> For the companies I see doing the best with Agile approaches, they
have
> cross-functional teams that are strongly focused on specific products,
> audiences, or interactions. There may be specialists in the company
that
> float, and resources that teams pull in as needed. But by and large,
> Agile is strongly team-oriented.
>
>
> William
>

[Mike Dwyer-2]

Good luck

 

Mike Dwyer
Principal, Agile Coach

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

cell:   [phone]

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

 

 

From: Marjorie H Pries [mailto:mhpries@...]
Sent: Wednesday, March 11, 2009 12:01 PM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 


Srinivas wrote:

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

 

I give up. Don't try to be agile. Design and prototype the whole
application. then hand it off to the developers and test it when it's done.
Charter a second release and plan to fix everything that needs to change in
the second release. Sounds like everyone on your team will be much happier
that way. Don't kill yourself trying to be what you are not.



Marjorie H. Pries
Lead Consultant / Utility Infielder

ThoughtWorks, Inc.
http://www.thoughtworks.com

"Don't believe everything you think."
    --seen on a bumpersticker




 
 

[Adrian Howard]

On 11 Mar 2009, at 16:05, Srinivas Manda wrote:

> 1)  when do we have time to do a usability test to the feature that  
> we worked on with the end users and get feedback from them   ?  
> cause we may take the whole 3 weeks to work on a set of feature ...  
> say if we do the test after the iteration and we get some feedback  
> from user ..if it is a good amount of change then should there be a  
> rework and that extends the project deadline ..
>

Three suggestions come to mind.

* Try and work on smaller features that take less time to implement -  
allowing you to get user feedback more quickly than once every three  
weeks.

* Do lo-fi prototyping and user testing (paper prototypes, etc.)  
before you implement features to give yourself more confidence that  
you're implementing the right thing. These should take hours - not  
days to do. Regularly having the post-iteration usability tests show  
lots of serious problems is a sign there is something wrong earlier in  
the process.

* As elements of the functionality are made to work during the  
iteration - do gorilla usability testing on those during the sprint.  
Use the results to steer the rest of the iteration.

Basically - gather more information earlier - but use more lightweight  
techniques the earlier in the iteration you are so you're not slowing  
up progress.

Cheers,

Adrian

--
delicious.com/adrianh - twitter.com/adrianh - adrianh@...

[Mike Dwyer-2]

Ok  thanks for being transparent.  I find the notion of enemy to be of
little value as there is no stability in the term.  It is a way to freeze
the masses and to then have time to reposition yourself.  Conflict is not
necessarily associated with what you are talking about as conflict is the
most constructive force around, when used in a collaborative manner.

Think of this way.  Teamwork has nothing to do with friendship, teamwork has
everything to do with excelling.  The conflicts I have seen have lead to
unbelievable insights and great strides forward and on the otherhand, fields
pooled in futility and blood.

To all of these issues I look to Nash's work and realize that if we muddle
through looking for the best overall solution, we each get to go home at
night and come back to joust tomorrow.  Albeit I could be jouist ing with
you at my side today and opposing you the next.

 

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 11:23 AM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 

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
<http://en.wikipedia.org/wiki/Scientific_law> scientific 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-w
ith-maria-giudice-of-hot-studio>
http://blog.carbonfive.com/2009/03/agile/when-worlds-collide-conversation-wi
th-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 <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

 

 




 
 

[Adrian Howard]

On 11 Mar 2009, at 16:42, Srinivas Manda wrote:
[snip]
> This is the catch here – Developers , Testing are always full time
> and they work on only 1 project but designers , usability folks ,
> Database are some sort of Specialty roles and we work on multiple
> projects at  a time I am not sure if this is same elsewhere and this  
> is
> where the problem arises when working with Agile ....
[snip]

My approach in these situations is to make more UX resources. Remove  
the bottleneck by educating the rest of the team.

I find that the time spent spreading UX skills/knowledge about to the  
rest of the team is more than made up by the time you save by not  
doing it all yourself.

You certainly can't turn everybody into a UX designer - but you can  
give people enough information and skills to spot/solve the easier  
issues leaving you free to concentrate on the harder ones.

Cheers,

Adrian
--
delicious.com/adrianh - twitter.com/adrianh - adrianh@...

[Adrian Howard]

On 11 Mar 2009, at 15:40, William Pietri wrote:
[snip]
> 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.
[snip]

Seconded.

Adrian

[Mike Dwyer-2]

In many cases the Product Owner is the Product Manager and the team s/he
they are on.

 

Mike Dwyer
Principal, Agile Coach

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

cell:   [phone]

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

 

 

From: Adrian Howard [mailto:adrianh@...]
Sent: Wednesday, March 11, 2009 1:10 PM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 


On 11 Mar 2009, at 15:40, William Pietri wrote:
[snip]
> 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.
[snip]

Seconded.

Adrian




 
 

[Mike Dwyer-2]

Amen to this

 

Mike Dwyer
Principal, Agile Coach

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

cell:   [phone]

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

 

 

From: Adrian Howard [mailto:adrianh@...]
Sent: Wednesday, March 11, 2009 1:08 PM
To: agile-usability@...
Subject: Re: [agile-usability] Re: Question_Agile Process_ UIE Virtual
Seminar

 


On 11 Mar 2009, at 16:42, Srinivas Manda wrote:
[snip]
> This is the catch here - Developers , Testing are always full time
> and they work on only 1 project but designers , usability folks ,
> Database are some sort of Specialty roles and we work on multiple
> projects at a time I am not sure if this is same elsewhere and this
> is
> where the problem arises when working with Agile ....
[snip]

My approach in these situations is to make more UX resources. Remove
the bottleneck by educating the rest of the team.

I find that the time spent spreading UX skills/knowledge about to the
rest of the team is more than made up by the time you save by not
doing it all yourself.

You certainly can't turn everybody into a UX designer - but you can
give people enough information and skills to spot/solve the easier
issues leaving you free to concentrate on the harder ones.

Cheers,

Adrian
--
delicious.com/adrianh - twitter.com/adrianh - adrianh@...
<mailto:adrianh%40quietstars.com>




 
 

[Adrian Howard]

On 11 Mar 2009, at 04:56, William Pietri wrote:
[snip]
> 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.
[snip]

Yeah. That's a failure mode that worries me too. It's one of the  
things that wants me to have more folk in the team with coding as a  
secondary skill - makes it much harder to do (even accidentally).

Adrian
--
delicious.com/adrianh - twitter.com/adrianh - adrianh@...

[Larry Constantine]

Adrian said:

 

My approach in these situations is to make more UX resources. Remove
the bottleneck by educating the rest of the team.

I find that the time spent spreading UX skills/knowledge about to the
rest of the team is more than made up by the time you save by not
doing it all yourself.

You certainly can't turn everybody into a UX designer - but you can
give people enough information and skills to spot/solve the easier
issues leaving you free to concentrate on the harder ones.



 

Lucy and I have been arguing this for 15 years. Developers often by default
end up having to make decisions on the fly that strongly impact usability;
and the UX pros can never cover everything in what they hand over to
development. The more developers know about basic UI design principles, the
better for everyone. Which is one of the reasons we started training
developers, which got us in trouble with some of the HCI community.

 

Besides, cross-training and increasing fungibility are core agile values!

 

--Larry Constantine, IDSA, ACM Fellow

[Andy Edmonds]

Indeed, in the spirit of "generalizing specialists" even.

I'm a big fan of Jakob Nielsen's heuristics as handy "commandments" for UX design:
http://www.useit.com/papers/heuristic/heuristic_list.html

I phrase them typically as guidelines:
1) Keep the user informed of system status
2) Match the real world
3) Keep the user in control
4) Be consistent
5) Prevent user error
6) Enable recognition, don't require recall
7) Provide shortcuts for flexibility and efficiency
8) Keep the design minimal
9) Enable recovery from error (barring #5)
10) Provide help

These principles can be revisited in design dialogues until they are standard concerns.  Prevent user error with enable easy recovery as a fallback in particular has been internalized well by developers I've worked with.

-Andy
http://uxagile.com

--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:
>
> Amen to this
[snip]
> On 11 Mar 2009, at 16:42, Srinivas Manda wrote:
> [snip]

> My approach in these situations is to make more UX resources. Remove
> the bottleneck by educating the rest of the team.
[snip]

[Jeff Patton]

Hi,

I know the thread on this is very long.  I'm about to respond to this  
not having reviewed the thread, so it's likely I'll mention things  
others already have.

On iteration 0 or sprint 0: There always seems to be a "getting  
started" phase to an agile project where we get our backlog in order.  
This is the place where I expect to see high-level design.

For me high-level design means identifying the business goals that  
motivate the product's creation, the customers and users of the  
product, and what they'll be doing as user tasks and activities  
(roughly how Larry Constantine defines those terms).  I use user tasks  
and activities as large user stories suitable for both understanding  
the prospective system from the usage perspective and for planning.  I  
also find that using these tasks I can identify screens and build  
basic navigation models and simple wireframes of the whole system.  I  
likely don't have time for much validation - maybe a few reviews of a  
key scenario and sketchy prototype with prospective users.  Sometimes  
maybe not.  it depends on the risks in the project.  I definitely make  
plans for how I'm going to involve users in the coming weeks and  
months of sprinting.

In your question, you mentioned 6 features. Assuming all features are  
in scope for the release, my high level design (napkin sketch level of  
detail) incorporates all 6 features.  It's not just for one.  I want  
to think of the product holistically - even though I intend to  
construct it iteratively and incrementally.

Then those 6 features need to be sliced very thin.  User stories that  
go into a sprint are ideally very small - completable in a matter of  
days.  So, a system with 6 features may decompose to dozens if not  
hundreds of stories.  As a UX person you need to help with this - get  
good at this.  If you're not involved with the planning and slicing up  
of your design into smaller stories, expect to "lose the plot" pretty  
soon.

UI prototypes help make some early design decisions visible - more  
concrete.  They help me break the features down into smaller buildable  
chunks.  They help developers estimate.  Ideally they estimate time  
and consider implementation ideas while estimating and discussing the  
features.

Taking Lynn Williams recommendation, the design I prepare for the  
first sprint is for a critical feature low in IxD concerns and high in  
engineering concerns.  This buys me time to start to get ahead on IxD.

Your question below was "If there is a technical problem/Limitation  
that arises for the designs that we already worked on ITERATION ZERO  
how do we handle it?"

On iteration 0 you also said: "in Iteration ZERO developers may not be  
ready to participate with designer as they will work on some other  
technical tasks"

I'll tell you if developers don't participate in some way with design,  
all bets are off.  What makes agile agile is this collaboration - is  
the back and forth discussion between those who design and those who  
implement.  Without the discussion you're practicing a sequential  
development approach - a waterfall approach.  You may be using words  
like "user story" and "iteration" or "sprint" - but don't be fooled.  
It's not an agile approach.

Assuming I understand your questions correctly, if developers aren't  
involved early you're more likely to encounter technical constraints  
later - more likely to be surprised.  It's a project risk that you  
mitigate by overlapping development and design concerns.  Choosing not  
to overlap them is simply choosing to accept the risk.  If developers  
don't have time to talk, make sure the whole team is aware of the risk  
we've all chosen to accept.

Finally, stuff happens.  Unforeseen technical challenges will arise.  
The reason for slicing big features into smaller stories is to see  
work being built, measure how long it took, and evaluate the  
incomplete product that came out.  By doing this you learn about  
technical challenges sooner - ideally soon enough to respond to them.  
Ideally soon enough to face reality and adjust schedules or thin out  
features further to keep schedules.

Hope this helps - and frankly I'll be shocked if the other smart  
people on the list haven't said all this already.

Off to catch my plane.  I'll read through the remainder of this thread  
on the plane.

Thanks very much for posting - and thanks very much for listening to  
the webinar.

-Jeff
-----------------------------------------
Jeff Patton
jpatton@...
+1 801.910.7908
skype; jeff_patton
www.agileproductdesign.com



On Mar 9, 2009, at 2:21 PM, Srinivas Manda wrote:

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

[manish pillewar-2]

'You certainly can't turn everybody into a UX designer - but you can

give people enough information and skills to spot/solve the easier

issues leaving you free to concentrate on the harder ones.'

That said, you'll have to be careful to miss not reviewing work(basic design) done by
developers. The tendency is to design what can be coded by the team, rather than
explore new concepts and then find some help to get it done. Good design often gets
killed on the coding table, if you, as a designer on the team, don't have a watchful eye.
I have seen  brilliant UI solutions come up from the developers at times.

Good profiles to start educating are the BA's and the PM on the project. Talk to the
group for an hour about design, ideally before the project inception or iteration 0.Train
BA's to capture information that is critical from the end user perspective. Teach them
to make basic wireframes to help them capture information most effectively. Not all
Agile projects have designers on them. BA's can cover up for designer deficiency by
a good mile.

With developers, it works best to work with them on the coding table. Design happens
upfront and once the stories are listed, the designer moves from the screen to make way
for the developers.Designers work is sinusoidal. Once the design is done, she can move around helping other projects.Though, a designer with some coding skills and pairing with a developer, adds much more value educating on design, on the same project.

Awesome thread :-)

Manish
www.Thoughtworks. com
http://linkedin.com/manishpillewar







--- On Wed, 11/3/09, Mike Dwyer <mdwyer@...> wrote:

From: Mike Dwyer <mdwyer@...>
Subject: RE: [agile-usability] Re: Question_Agile Process_ UIE Virtual Seminar
To: agile-usability@...
Date: Wednesday, 11 March, 2009, 5:43 PM











   
           







Amen to this

  



Mike Dwyer

Principal, Agile Coach

BigVisible Solutions

url:    http://www.bigvisib le.com

cell:   [phone]

email: mdwyer@bigvisible. com

  



  





From: Adrian Howard
[mailto:adrianh@ quietstars. com]

Sent: Wednesday, March 11, 2009 1:08 PM

To: agile-usability@ yahoogroups. com

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





  









On 11 Mar 2009, at 16:42, Srinivas Manda wrote:

[snip]

> This is the catch here – Developers , Testing are always full time

> and they work on only 1 project but designers , usability folks ,

> Database are some sort of Specialty roles and we work on multiple

> projects at a time I am not sure if this is same elsewhere and this

> is

> where the problem arises when working with Agile ....

[snip]



My approach in these situations is to make more UX resources. Remove

the bottleneck by educating the rest of the team.



I find that the time spent spreading UX skills/knowledge about to the

rest of the team is more than made up by the time you save by not

doing it all yourself.



You certainly can't turn everybody into a UX designer - but you can

give people enough information and skills to spot/solve the easier

issues leaving you free to concentrate on the harder ones.



Cheers,



Adrian

--

delicious.com/ adrianh - twitter.com/ adrianh - adrianh@quietstars. com





 









 

     

   
   
       
         
       
       








       


       
       


     

[Srinivas Manda]

Thanks Jeff  for your detailed reply

-Srinivas




--- In agile-usability@..., Jeff Patton <jpatton@...> wrote:

>
> Hi,
>
> I know the thread on this is very long. I'm about to respond to this
> not having reviewed the thread, so it's likely I'll mention things
> others already have.
>
> On iteration 0 or sprint 0: There always seems to be a "getting
> started" phase to an agile project where we get our backlog in order.
> This is the place where I expect to see high-level design.
>
> For me high-level design means identifying the business goals that
> motivate the product's creation, the customers and users of the
> product, and what they'll be doing as user tasks and activities
> (roughly how Larry Constantine defines those terms). I use user tasks
> and activities as large user stories suitable for both understanding
> the prospective system from the usage perspective and for planning. I
> also find that using these tasks I can identify screens and build
> basic navigation models and simple wireframes of the whole system. I
> likely don't have time for much validation - maybe a few reviews of a
> key scenario and sketchy prototype with prospective users. Sometimes
> maybe not. it depends on the risks in the project. I definitely make
> plans for how I'm going to involve users in the coming weeks and
> months of sprinting.
>
> In your question, you mentioned 6 features. Assuming all features are
> in scope for the release, my high level design (napkin sketch level of
> detail) incorporates all 6 features. It's not just for one. I want
> to think of the product holistically - even though I intend to
> construct it iteratively and incrementally.
>
> Then those 6 features need to be sliced very thin. User stories that
> go into a sprint are ideally very small - completable in a matter of
> days. So, a system with 6 features may decompose to dozens if not
> hundreds of stories. As a UX person you need to help with this - get
> good at this. If you're not involved with the planning and slicing up
> of your design into smaller stories, expect to "lose the plot" pretty
> soon.
>
> UI prototypes help make some early design decisions visible - more
> concrete. They help me break the features down into smaller buildable
> chunks. They help developers estimate. Ideally they estimate time
> and consider implementation ideas while estimating and discussing the
> features.
>
> Taking Lynn Williams recommendation, the design I prepare for the
> first sprint is for a critical feature low in IxD concerns and high in
> engineering concerns. This buys me time to start to get ahead on IxD.
>
> Your question below was "If there is a technical problem/Limitation
> that arises for the designs that we already worked on ITERATION ZERO
> how do we handle it?"
>
> On iteration 0 you also said: "in Iteration ZERO developers may not be
> ready to participate with designer as they will work on some other
> technical tasks"
>
> I'll tell you if developers don't participate in some way with design,
> all bets are off. What makes agile agile is this collaboration - is
> the back and forth discussion between those who design and those who
> implement. Without the discussion you're practicing a sequential
> development approach - a waterfall approach. You may be using words
> like "user story" and "iteration" or "sprint" - but don't be fooled.
> It's not an agile approach.
>
> Assuming I understand your questions correctly, if developers aren't
> involved early you're more likely to encounter technical constraints
> later - more likely to be surprised. It's a project risk that you
> mitigate by overlapping development and design concerns. Choosing not
> to overlap them is simply choosing to accept the risk. If developers
> don't have time to talk, make sure the whole team is aware of the risk
> we've all chosen to accept.
>
> Finally, stuff happens. Unforeseen technical challenges will arise.
> The reason for slicing big features into smaller stories is to see
> work being built, measure how long it took, and evaluate the
> incomplete product that came out. By doing this you learn about
> technical challenges sooner - ideally soon enough to respond to them.
> Ideally soon enough to face reality and adjust schedules or thin out
> features further to keep schedules.
>
> Hope this helps - and frankly I'll be shocked if the other smart
> people on the list haven't said all this already.
>
> Off to catch my plane. I'll read through the remainder of this thread
> on the plane.
>
> Thanks very much for posting - and thanks very much for listening to
> the webinar.
>
> -Jeff
> -----------------------------------------
> Jeff Patton
> jpatton@...
> +1 801.910.7908
> skype; jeff_patton
> www.agileproductdesign.com
>
>
>
> On Mar 9, 2009, at 2:21 PM, Srinivas Manda wrote:
>
> >
> > 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
> >
> >
> >
> >
>

[manish pillewar-2]

'On iteration 0 or sprint 0: There always seems to be a "getting
started" phase to an agile project where we get our backlog in order.
 This is the place where I expect to see high-level design.'

Referring to this Jeff, some of the projects that I have worked on, have benefited from having started earlier than Iteration 0. Lets call it an Iteration (n) -1. This is the phase just before the project inception that a designer can cover a lot of ground  on. Some of the stuff that can be done during Iteration -1 are:

User Research ( Collating data from marketing folks, referring web analytics, profiling use base, contextual inquiries, etc. )
Usability Testing ( Data from usability testing ( videos & figures ) can be a high energy shot while putting forward a strong case of usability to the stakeholders)
Design Reviews ( Heuristics Evaluation to find out basic usability issues from UI standards perspective )
Design Concepts ( Preparing initial concepts for the designs based on the inputs above and be Inception ready )

Of course, not all projects have a screen to review or enough data to come up with design concepts.

Questions for all:

What percentage of agile projects allow User Research ?
Also, what percentage of projects perform Usability Testing at the end of an Iteration or Release and do include the feedback into the next cycle?

-Manish
www.thoughtworks.com
http://linkedin.com/manishpillewar


--- On Wed, 11/3/09, Jeff Patton <jpatton@...> wrote:

From: Jeff Patton <jpatton@...>
Subject: Re: [agile-usability] Question_Agile Process_ UIE Virtual Seminar
To: agile-usability@...
Date: Wednesday, 11 March, 2009, 8:10 PM











   
            Hi,
I know the thread on this is very long.  I'm about to respond to this not having reviewed the thread, so it's likely I'll mention things others already have.
On iteration 0 or sprint 0: There always seems to be a "getting started" phase to an agile project where we get our backlog in order.  This is the place where I expect to see high-level design.  
For me high-level design means identifying the business goals that motivate the product's creation, the customers and users of the product, and what they'll be doing as user tasks and activities (roughly how Larry Constantine defines those terms).  I use user tasks and activities as large user stories suitable for both understanding the prospective system from the usage perspective and for planning.  I also find that using these tasks I can identify screens and build basic navigation models and simple wireframes of the whole system.  I likely don't have time for much validation - maybe a few reviews of a key scenario and sketchy prototype with prospective users.  Sometimes maybe not.  it depends on the risks in the project..  I definitely make plans for how I'm going to involve users in the coming weeks and months of sprinting.
In your question, you mentioned 6 features. Assuming all features are in scope for the release, my high level design (napkin sketch level of detail) incorporates all 6 features.  It's not just for one.  I want to think of the product holistically - even though I intend to construct it iteratively and incrementally.
Then those 6 features need to be sliced very thin.  User stories that go into a sprint are ideally very small - completable in a matter of days.  So, a system with 6 features may decompose to dozens if not hundreds of stories.  As a UX person you need to help with this - get good at this.  If you're not involved with the planning and slicing up of your design into smaller stories, expect to "lose the plot" pretty soon.    
UI prototypes help make some early design decisions visible - more concrete..  They help me break the features down into smaller buildable chunks.  They help developers estimate.  Ideally they estimate time and consider implementation ideas while estimating and discussing the features.
Taking Lynn Williams recommendation, the design I prepare for the first sprint is for a critical feature low in IxD concerns and high in engineering concerns.  This buys me time to start to get ahead on IxD.
Your question below was "If there is a technical problem/Limitation that arises for the designs that we already worked on ITERATION ZERO how do we handle it?"
On iteration 0 you also said: "in Iteration ZERO developers may not be ready to participate with designer as they will work on some other technical tasks"
I'll tell you if developers don't participate in some way with design, all bets are off.  What makes agile agile is this collaboration - is the back and forth discussion between those who design and those who implement.  Without the discussion you're practicing a sequential development approach - a waterfall approach.  You may be using words like "user story" and "iteration" or "sprint" - but don't be fooled.  It's not an agile approach.  
Assuming I understand your questions correctly, if developers aren't involved early you're more likely to encounter technical constraints later - more likely to be surprised.  It's a project risk that you mitigate by overlapping development and design concerns.  Choosing not to overlap them is simply choosing to accept the risk.  If developers don't have time to talk, make sure the whole team is aware of the risk we've all chosen to accept.
Finally, stuff happens.  Unforeseen technical challenges will arise.  The reason for slicing big features into smaller stories is to see work being built, measure how long it took, and evaluate the incomplete product that came out.  By doing this you learn about technical challenges sooner - ideally soon enough to respond to them.  Ideally soon enough to face reality and adjust schedules or thin out features further to keep schedules.
Hope this helps - and frankly I'll be shocked if the other smart people on the list haven't said all this already.  
Off to catch my plane.  I'll read through the remainder of this thread on the plane.
Thanks very much for posting - and thanks very much for listening to the webinar.
-Jeff ------------ --------- --------- --------- --Jeff Pattonjpatton@acm. org+1 801.910.7908skype; jeff_pattonwww.agileproductdes ign.com

 
On Mar 9, 2009, at 2:21 PM, Srinivas Manda wrote:

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 comesProblem: 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