So Maybe we should not call it "Agile" but it works for us

[Amber-21]

Thanks for your feedback Yes you are correct the reason we recommend many of these items are because of issues/problems we have faced. Our solutions have solved the issues so I do not need other recommendations however I do understand many of your concerns.

I work for a large enterprise organization with segmented teams/roles incorporating "non" development stories and tasks helps us track all aspects of the project. We have quarterly releases so finishing an agile sprint does not allow the customer to get the features any faster.  

Thank you for all of the constructive feedback. I was just commenting on the post as for what works for us.  I understand maybe we should not call it "Agile" but some hybrid approach but the important point here is that it works for us and that to me is good enough.

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

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


We are not co located. I know I know but nothing we can do about it.

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

Our BSAs, IAs and Designers would not be able to gather the complex requirements communicate them to the IA/Designers have a design and then transition to the development team all in one sprint. I could see this working if the requirements were already defined, design already complete, or they did not have complex business rules.

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

>Work ahead of the team is what Lean calls "Work In Process". Work In
>Process is uniformly considered waste and one tries to eliminate it.
>If UX is two sprints ahead of the team, then the proper accounting
>for stories is that the fastest possible story is three sprints
>long. That's a long damn time, and this waste is solely caused by
>trying to get ahead.

As I said we have quarterly releases, legal reviews of content and other processes that require this type of "Agile" process. Maybe you should not call it "Agile" but it is a heck of a lot faster then waterfall use to be.

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

You are correct and this would be an ideal situation.

> --provides a way to track UX time and resources.
>That's moderately useful. What is more important in these processes
>is cycle time, not time and resource allocation.

Cycle time is not as important when you have quarterly releases, legal review, other regulated processes to slow you down. Resource allocation is very important in an enterprize organization!

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

If a usability test is completed after the development story is closed, you need a story in the future sprints to implement changes.

[Mike Dwyer-2]

Ignore the dogmatists.  Agile is not some quaint book of sayings.  Agile is
all about improving.  Sounds like you have a great handle on the reality of
your situation.  This is the first step.  Second you seem to have a good
idea where things are not working as well as you would like.  This is the
second step.  Now work on the issues.  OK so how can you help your folks get
closer together?  There is a lot of good stuff out there. Alistair Cockburn,
myself, Ron Jeffries, all have opinions and empirical evidence that our
approaches work.  And yes they are conflicting and we argue about them all
the time. So what, the point is there are lots of different ways to go at
improving.

This is where dogmatists fall down, they think either you  follow the path
to get to the goal or you don't win.  News flash.  Getting value to the
customer in ways that make your teams thrive is what it is all about.

 

That being said some paths you choose are well worn and have high returns
and to follow them you need to fit into the path.  Sounds like your
organizational feet don't fit on those paths.  OK so there are other paths,
not as fast to productivity but they will give you improvement.  Once you
get to where they lead, look around, your organization may be ready to taste
more success.  But that will not happen until you move the ball forward to
show them it can be done.

 

This fact I know to be true.   No one instance of Scrum or Agile is
identical to another, even in the same organization.  This is a truth
because the teams are not made up of clones who all share the same day,
everyday and do the same work in that day.  Go on, try it, when what ever
you are doing stops returning value, ask why adapt and go again.

 

Learning from failure is the only sure way to find the path to success.

 

Mike Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."

"A Plan is a complex situation, adapting to an emerging solution."

 

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of jasarask8
Sent: Tuesday, September 08, 2009 12:09 PM
To: agile-usability@...
Subject: [agile-usability] So Maybe we should not call it "Agile" but it
works for us

 

 

Thanks for your feedback Yes you are correct the reason we recommend many of
these items are because of issues/problems we have faced. Our solutions have
solved the issues so I do not need other recommendations however I do
understand many of your concerns.

I work for a large enterprise organization with segmented teams/roles
incorporating "non" development stories and tasks helps us track all aspects
of the project. We have quarterly releases so finishing an agile sprint does
not allow the customer to get the features any faster.

Thank you for all of the constructive feedback. I was just commenting on the
post as for what works for us. I understand maybe we should not call it
"Agile" but some hybrid approach but the important point here is that it
works for us and that to me is good enough.

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

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

We are not co located. I know I know but nothing we can do about it.

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

Our BSAs, IAs and Designers would not be able to gather the complex
requirements communicate them to the IA/Designers have a design and then
transition to the development team all in one sprint. I could see this
working if the requirements were already defined, design already complete,
or they did not have complex business rules.

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

>Work ahead of the team is what Lean calls "Work In Process". Work In
>Process is uniformly considered waste and one tries to eliminate it.
>If UX is two sprints ahead of the team, then the proper accounting
>for stories is that the fastest possible story is three sprints
>long. That's a long damn time, and this waste is solely caused by
>trying to get ahead.

As I said we have quarterly releases, legal reviews of content and other
processes that require this type of "Agile" process. Maybe you should not
call it "Agile" but it is a heck of a lot faster then waterfall use to be.

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

You are correct and this would be an ideal situation.

> --provides a way to track UX time and resources.
>That's moderately useful. What is more important in these processes
>is cycle time, not time and resource allocation.

Cycle time is not as important when you have quarterly releases, legal
review, other regulated processes to slow you down. Resource allocation is
very important in an enterprize organization!

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

If a usability test is completed after the development story is closed, you
need a story in the future sprints to implement changes.




 
 

[Adrian Howard]

On 8 Sep 2009, at 17:08, jasarask8 wrote:
[snip]
> Thank you for all of the constructive feedback. I was just  
> commenting on the post as for what works for us.  I understand maybe  
> we should not call it "Agile" but some hybrid approach but the  
> important point here is that it works for us and that to me is good  
> enough.
[snip]

Indeed :-)

I'd still be interested, if you can spare the time, in learning more  
about the problems that led to your current solutions. I'd especially  
like to learn more about the kinds of thing that are appearing on your  
non-coding cards.

[snip]

>> Writing UX stories or tasks
>> I recommend having all UX tasks done in-Sprint. Failing that, I
>> recommend considering them to be overhead work done in the
>> product owner's office.
>
> Our BSAs, IAs and Designers would not be able to gather the complex  
> requirements communicate them to the IA/Designers have a design and  
> then transition to the development team all in one sprint. I could  
> see this working if the requirements were already defined, design  
> already complete, or they did not have complex business rules.

I'm wondering, again, if different people are hearing different  
definitions of "design" here.

In my experience most UX folk read "design" to be the things that  
happen (mostly) before the story is written. Most dev folk read  
"design" to be the things that happen (mostly) after the story is  
written.

Cheers,

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