I saw a presentation by Scott Downey last night at Agile SoCal on
hyperproductive Scrum teams. Downey defines a hyperproductive team as a team
that achieves a 500% increase over its initial velocity, as measured in story
points.

I've seen Ron Jeffries recommend not using story points, instead sizing stories
consistently around a couple of days, and counting stories instead of points.
That's always seemed like a good idea to me, but after Downey's presentation, I
was trying to think about how to measure productivity gains when sizing stories
at a couple of days.

To take a simple example, if I can do a story every two days, then I can do five
stories in a two-week sprint. By definition (story = 2 days), I will continue to
complete five stories per sprint forever. In order to demonstrate improvement
over time, I would need a new measurement, e.g., value, right?

Any ideas on how to measure team productivity over time using consistent story
sizes?

Thanks...

Paul Epps

Hello Paul,

Please describe the process that this 'productivity measure' will be input to. 
What is its purpose?

chet

Thursday, June 21, 2012, 1:27:06 PM, you wrote:



I saw a presentation by Scott Downey last night at Agile SoCal on
hyperproductive Scrum teams. Downey defines a hyperproductive team as a team
that achieves a 500% increase over its initial velocity, as measured in story
points.

I've seen Ron Jeffries recommend not using story points, instead sizing stories
consistently around a couple of days, and counting stories instead of points.
That's always seemed like a good idea to me, but after Downey's presentation, I
was trying to think about how to measure productivity gains when sizing stories
at a couple of days.

To take a simple example, if I can do a story every two days, then I can do five
stories in a two-week sprint. By definition (story = 2 days), I will continue to
complete five stories per sprint forever. In order to demonstrate improvement
over time, I would need a new measurement, e.g., value, right?

Any ideas on how to measure team productivity over time using consistent story
sizes?

Thanks...

Paul Epps






--
Best regards,
  Chet Hendrickson                          mailto:lists@...
  Check out our upcoming CSM Plus courses @
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28

[Non-text portions of this message have been removed]

Hi Chet -

> Please describe the process that this 'productivity measure' will be input to.
What is its purpose?

Downey described the purpose with this user story: AS A Scrum Product Owner who
is trying to evaluate the efficacy of the product directions I have chosen, I
NEED a reliable way to measure the increased value
contribution of the Team sprint-over-sprint SO THAT I can compare the Team's
rate of value contribution increase to the changes in revenue we are generating
and adjust our direction if the value isn't being realized.

Thanks...

pe

> Thursday, June 21, 2012, 1:27:06 PM, you wrote:
>
>
>
> I saw a presentation by Scott Downey last night at Agile SoCal on
hyperproductive Scrum teams. Downey defines a hyperproductive team as a team
that achieves a 500% increase over its initial velocity, as measured in story
points.
>
> I've seen Ron Jeffries recommend not using story points, instead sizing
stories consistently around a couple of days, and counting stories instead of
points. That's always seemed like a good idea to me, but after Downey's
presentation, I was trying to think about how to measure productivity gains when
sizing stories at a couple of days.
>
> To take a simple example, if I can do a story every two days, then I can do
five stories in a two-week sprint. By definition (story = 2 days), I will
continue to complete five stories per sprint forever. In order to demonstrate
improvement over time, I would need a new measurement, e.g., value, right?
>
> Any ideas on how to measure team productivity over time using consistent story
sizes?
>
> Thanks...
>
> Paul Epps
>
>
>
>
>
>
> --
> Best regards,
>  Chet Hendrickson                          mailto:lists@...
>  Check out our upcoming CSM Plus courses @
> http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
>
> [Non-text portions of this message have been removed]
>

I suspect the relationship is backwards here: We should be finding that the
bigger the stories a team works on, the slower the team would increase its
productivity.

Productivity should be measure as actual value delivered to the customer
over time, not something based on estimates.

(BTW, I really enjoy the pushback I get from management on that - that
development should be responsible for precise enough estimations to support
all sorts of management metrics whereas the business does not have to be
responsible for determining the actual value of being delivered what they
ask for).

SteveG

On Thu, Jun 21, 2012 at 10:27 AM, Paul Epps <paul@...> wrote:

> **
>
>
> I saw a presentation by Scott Downey last night at Agile SoCal on
> hyperproductive Scrum teams. Downey defines a hyperproductive team as a
> team that achieves a 500% increase over its initial velocity, as measured
> in story points.
>
> I've seen Ron Jeffries recommend not using story points, instead sizing
> stories consistently around a couple of days, and counting stories instead
> of points. That's always seemed like a good idea to me, but after Downey's
> presentation, I was trying to think about how to measure productivity gains
> when sizing stories at a couple of days.
>
> To take a simple example, if I can do a story every two days, then I can
> do five stories in a two-week sprint. By definition (story = 2 days), I
> will continue to complete five stories per sprint forever. In order to
> demonstrate improvement over time, I would need a new measurement, e.g.,
> value, right?
>
> Any ideas on how to measure team productivity over time using consistent
> story sizes?
>
> Thanks...
>
> Paul Epps
>
>
>


[Non-text portions of this message have been removed]

What else contributes to revenue changes?  How can knowing how much the
team delivered differentiate among all those contributions to revenue
changes?

Root cause the revenue problems and see where development, marketing,
sales, product ownership, etc. is involved.  Assuming that the quantity
delivered indicates whether development is the problem is lazy.

SteveG

On Thu, Jun 21, 2012 at 11:27 AM, Paul Epps <paul@...> wrote:

> **
>
>
> Hi Chet -
>
> > Please describe the process that this 'productivity measure' will be
> input to. What is its purpose?
>
> Downey described the purpose with this user story: AS A Scrum Product
> Owner who is trying to evaluate the efficacy of the product directions I
> have chosen, I NEED a reliable way to measure the increased value
> contribution of the Team sprint-over-sprint SO THAT I can compare the
> Team's rate of value contribution increase to the changes in revenue we are
> generating and adjust our direction if the value isn't being realized.
>
> Thanks...
>
> pe
>
>
> > Thursday, June 21, 2012, 1:27:06 PM, you wrote:
> >
> >
> >
> > I saw a presentation by Scott Downey last night at Agile SoCal on
> hyperproductive Scrum teams. Downey defines a hyperproductive team as a
> team that achieves a 500% increase over its initial velocity, as measured
> in story points.
> >
> > I've seen Ron Jeffries recommend not using story points, instead sizing
> stories consistently around a couple of days, and counting stories instead
> of points. That's always seemed like a good idea to me, but after Downey's
> presentation, I was trying to think about how to measure productivity gains
> when sizing stories at a couple of days.
> >
> > To take a simple example, if I can do a story every two days, then I can
> do five stories in a two-week sprint. By definition (story = 2 days), I
> will continue to complete five stories per sprint forever. In order to
> demonstrate improvement over time, I would need a new measurement, e.g.,
> value, right?
> >
> > Any ideas on how to measure team productivity over time using consistent
> story sizes?
> >
> > Thanks...
> >
> > Paul Epps
> >
> >
> >
> >
> >
> >
> > --
> > Best regards,
> > Chet Hendrickson mailto:lists@...
>
> > Check out our upcoming CSM Plus courses @
> > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


[Non-text portions of this message have been removed]

Paul,

On 6/21/12 1:27 PM, Paul Epps wrote:
	 [snip]
> Any ideas on how to measure team productivity over time using
> consistent story sizes?

Any ideas on how to measure team productivity?

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hi Paul,

On Jun 21, 2012, at 2:27 PM, Paul Epps wrote:

> Downey described the purpose with this user story: AS A Scrum Product Owner
who is trying to evaluate the efficacy of the product directions I have chosen,
I NEED a reliable way to measure the increased value
> contribution of the Team sprint-over-sprint SO THAT I can compare the Team's
rate of value contribution increase to the changes in revenue we are generating
and adjust our direction if the value isn't being realized.


That strikes me as ... how can I put this nicely ... overly indirect. It's a red
herring.

I suspect the real purpose of wanting to know this is to "measure" how hard the
team is working and how much they are accomplishing. This is a cost focus. Scrum
projects are supposed to have a value focus: the PO is responsible for producing
the highest possible value by the deadline. This is done quite simply: have the
highest value possible in every Sprint.

The team is producing valuable stories at some rate. The PO's job is to select
them so as to have the best possible value at every moment in time. If the
stories are all the same "size", and the team is doing quality work (suitable
testing and design improvement), the flow of work will be perfectly clear: you
can draw a line to see how many more stories will be done.

If and when the team improves, the stories they can do in two days will be
discernibly "larger". Everyone who is paying attention will notice this and take
it into account when guessing how much they'll get done.

BUT THIS IS NOT IMPORTANT, because the PO always has the highest possible value
attainable at the current moment, in potentially shippable form.

If the revenue potential of an idea is anywhere near the cost of the team
building it, it is an incredibly bad idea and well past time to stop investing
in the product. Therefore, at any moment in time, the PO can pick up her most
favorite story and say to herself "This will bring in $11,000 in revenue and the
team costs me $10,000 per Sprint. Screw this, time to get a better idea."

Hyperproductivity is a marketing idea made up by Jeff Sutherland to sell Scrum.
It does exist, more or less. Teams doing good Scrum will get more done than they
used to -- usually because they used to get nothing done. Nonetheless, this is a
cost-based measure and is therefore inferior to managing by choosing valuable
things to do.

Relatedly, Arlo Belshee has some evidence that choosing the most valuable thing
no matter what it costs (within reason, I suppose) is a better strategy than
considering the value/cost ratio.

Bottom line, cost focus is a danger sign in a Scrum / Agile project.

Ron Jeffries
www.XProgramming.com
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
   -- Kelly Easterley



[Non-text portions of this message have been removed]

George ...

On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:

> Any ideas on how to measure team productivity?


Any ideas on WHY to measure team productivity?

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense"
and "I don't understand". -- Mary Doria Russell



[Non-text portions of this message have been removed]

Ron,

On 6/21/12 2:44 PM, RonJeffries wrote:
> George ...
>
> On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:
>
>> Any ideas on how to measure team productivity?
>
>
> Any ideas on WHY to measure team productivity?

Another good question. My initial point is that the rest of the sentence
is superfluous. Even if we think we have a good reason (or are just
curious), we have /no/ way to measure this concept "productivity" in
knowledge work.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hi George,

On Jun 21, 2012, at 3:03 PM, George Dinwiddie wrote:

> My initial point is that the rest of the sentence
> is superfluous. Even if we think we have a good reason (or are just
> curious), we have /no/ way to measure this concept "productivity" in
> knowledge work.


Yes, I do fully agree, of course. In addition, I've never seen a proposed
measure that I could not immediately game to my advantage.

Ron Jeffries
www.XProgramming.com
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
   -- Tom Jeffries



[Non-text portions of this message have been removed]

Hi Paul,

On 2012-06-21, at 1:27 PM, Paul Epps wrote:

> I saw a presentation by Scott Downey last night at Agile SoCal on
hyperproductive Scrum teams. Downey defines a hyperproductive team as a team
that achieves a 500% increase over its initial velocity, as measured in story
points.
>

I saw Scott give a presentation with Jeff Sutherland at Agile 2010 about this. 
During the session, I called BS to all of the numbers he and Jeff said you
should track, but the crowd ate it up.  Clearly I was swimming upstream against
a torrent.

I had a discussion with another conference attendee afterwards, someone who had
been a VP of development.  His org had a policy that allowed employees to order
pizza if they were working late into supper hours.  He said the only metric he
used to evaluate whether he needed to ask some questions was the number of
pizzas ordered in a given week.  He didn't need velocity, he didn't need
utilization vs. capacity, he didn't need *any* of the BS numbers that Downey &
Sutherland say are critical.

This is my opinion, but I do know that it's shared with other people:
Hyperproductivity is marketing BS that has done much more harm than good by
being the Promised Land of Scrum.  Your mileage (and opinion) may vary, of
course. :)

Dave Rooney
daverooneyca@...



>
> I've seen Ron Jeffries recommend not using story points, instead sizing
stories consistently around a couple of days, and counting stories instead of
points. That's always seemed like a good idea to me, but after Downey's
presentation, I was trying to think about how to measure productivity gains when
sizing stories at a couple of days.
>
> To take a simple example, if I can do a story every two days, then I can do
five stories in a two-week sprint. By definition (story = 2 days), I will
continue to complete five stories per sprint forever. In order to demonstrate
improvement over time, I would need a new measurement, e.g., value, right?
>
> Any ideas on how to measure team productivity over time using consistent story
sizes?
>
> Thanks...
>
> Paul Epps
>
>



[Non-text portions of this message have been removed]

On 21 Jun 2012, at 20:42, Dave Rooney wrote:

> He said the only metric he used to evaluate whether he needed to ask some
questions was the number of pizzas ordered in a given week.

The scary thing about that metric is that I've seen too many places where they
would consider more pizza orders to be a *good* thing :-)

Adrian
--
http://quietstars.com    adrianh@...    twitter.com/adrianh
t. +44 (0)7752 419080    skype adrianjohnhoward    pinboard.in/u:adrianh

Il 21/06/2012 21:17, RonJeffries ha scritto:
Hi Ron and George,

the point is always the same, some questions seem done by a manager that
needs to know when things will be done (not agile manager) and others by
a perfect XP team leader.
I think that both may be superfluous in a perfect XP contest and both
may be necessary in a not XP contest. The problem is what Scott Downey
said during the presentation.
>
>
> Hi George,
>
> On Jun 21, 2012, at 3:03 PM, George Dinwiddie wrote:
>
> > My initial point is that the rest of the sentence
> > is superfluous. Even if we think we have a good reason (or are just
> > curious), we have /no/ way to measure this concept "productivity" in
> > knowledge work.
>
> Yes, I do fully agree, of course. In addition, I've never seen a
> proposed measure that I could not immediately game to my advantage.
>
> Ron Jeffries
> www.XProgramming.com
> I try to Zen through it and keep my voice very mellow and low.
> Inside I am screaming and have a machine gun.
> Yin and Yang I figure.
> -- Tom Jeffries
>
> [Non-text portions of this message have been removed]
>
>



[Non-text portions of this message have been removed]

--- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
>
> (BTW, I really enjoy the pushback I get from management on that - that
> development should be responsible for precise enough estimations to support
> all sorts of management metrics whereas the business does not have to be
> responsible for determining the actual value of being delivered what they
> ask for).

Good observation!

Thanks everyone for the helpful replies.

pe

> Downey described the purpose with this user story: AS A Scrum Product Owner
who
> is trying to evaluate the efficacy of the product directions I have chosen, I
> NEED a reliable way to measure the increased value
> contribution of the Team sprint-over-sprint SO THAT I can compare the Team's
> rate of value contribution increase to the changes in revenue we are
generating
> and adjust our direction if the value isn't being realized.

What is the relation between the two? 

If the value is low, would you improve it by increasing or decreasing the rate
of production? 

It sounds to me like checking the speedometer to determine the direction of
travel.
 
Tim Ottinger
http://IndustrialLogic.com/

--- George Dinwiddie <lists@...> wrote:
> [W]e have /no/ way to measure this concept "productivity" in
> knowledge work.

Knowledge Gained, divided by Time.


;->

--- "Paul Epps" <paul@...> wrote:
> ... Downey defines a hyperproductive team as a team that
> achieves a 500% increase over its initial velocity, as
> measured in story points.

Oh; so all I have to do to be hyper-productive is start out really crappy.  Hey;
I think I can do that!   >;->

On 23 Jun 2012, at 09:29, JeffGrigg wrote:
> --- "Paul Epps" <paul@...> wrote:
>> ... Downey defines a hyperproductive team as a team that
>> achieves a 500% increase over its initial velocity, as
>> measured in story points.
>
> Oh; so all I have to do to be hyper-productive is start out really crappy. 
Hey; I think I can do that!   >;->

funny you should say that.... have you seen the baseline Sutherland's team
started from?

S.

Dear Practitioners,

There is a great opportunity to contribute to the knowledge of lean and agile
development! We are looking for organizations/companies/practitioners that are
willing to share their experience with agile approaches. You will get feedback
from researchers belonging to a high-ranked research institution. Once the
research is completed, the results will be shared among the participants and all
the known agile communities!

The research is addressed to anybody who interacts with software development
processes, both: adopters that have used agile for some time as well as new
adopters. Each organization/company provides answers from different perspectives
(e.g., development, project management, product management, quality assurance,
etc.). The goal is to receive as many answers as possible for each perspective.
All data will be kept anonymous.

The survey is available at: http://goo.gl/Cl4Ku It will only take you
approximately 20 minutes to complete the survey.

The situation: A number of researches have shown that organizations move from
their plan-driven approaches toward lean and agile methodologies. That leads to
both: benefits and limitations. Moreover, what has been observed is that the
applied methodologies are very often hybrids of agile and plan-driven approaches
(eg. Scrum + XP, XP + V-model etc.).

The problem: the effects of using agile methods in industry are not well
understood. Process changes can affect a variety of parameters, like
productivity, quality, motivation, etc. There is little information of what
organizations expect from agile adoption and what they actually achieve over
time (short-term vs. long-term).

The instrument: the survey consists of a few steps. First you will be asked to
provide context information to allow further results comparisons. Secondly, you
will be asked to define your organization/company development process in terms
of agile and plan-driven practices. Then, using cumulative voting method you
will be asked to rank agile adoption benefits and limitations that you are
experiencing with your current development approach.

Please direct any questions or feedback to my account or just post below. I will
do my best to reply ASAP. Thank you in advance,

Kind regards,
Adam

P.S. We would be grateful if you could distribute the survey further in agile
communities. http://goo.gl/Cl4Ku

Hi, Adam,

Where did you get the idea that organizations with lean and agile approaches
have no plan??

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of agileadam8
> Sent: Thursday, June 28, 2012 5:06 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Agile adoption benefits and limitations research:seeking for
> agile practitioners
>
<snip>
> The situation: A number of researches have shown that organizations move
> from their plan-driven approaches toward lean and agile methodologies.
> That leads to both: benefits and limitations. Moreover, what has been
> observed is that the applied methodologies are very often hybrids of agile
> and plan-driven approaches (eg. Scrum + XP, XP + V-model etc.).

Kay A Pentecost wrote:
> Hi, Adam,
>
> Where did you get the idea that organizations with lean and agile approaches
> have no plan??
>
> Kay Pentecost
>
Just to jump on the bandwagon. I would also like to know where that
misconception comes from.

-d



[Non-text portions of this message have been removed]

I did not see anyone saying that lean / agile approaches have no plan.
Did I miss a memo?
R
On Jun 28, 2012, at 3:26 PM, Darian Lanx wrote:

> Kay A Pentecost wrote:
> > Hi, Adam,
> >
> > Where did you get the idea that organizations with lean and agile approaches
> > have no plan??
> >
> > Kay Pentecost
> >
> Just to jump on the bandwagon. I would also like to know where that
> misconception comes from.


Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide



[Non-text portions of this message have been removed]

Hey, Ron,

It's a point of a pre-assumption.

The OP wrote: "A number of researches have shown that organizations move
from their plan-driven approaches toward lean and agile methodologies."

The implication is that lean/agile organizations are not "plan-driven." And
that implies that lean/agile don't have a plan, since the purpose of a plan
is to direct outcomes. At the very least, it implies that lean/agile
organizations don't *follow* a plan.  But having a plan and not following
it, is just stupid, IMHO. Notice here I'm referring to an organization, not
a human being.

Oh, wait.  I'm wrong. I forgot. An organization *is* a person.


<grin>

Are you agreeing with the OP that lean/agile companies *don't* have plan, or
that they are not "driven" by a plan?

Seems to me that many anti-(lean/XP/agile) folks assume that (lean/XP/agile)
are just haphazard.  I for one would like to see that message disappear.



Kay Pentecost


> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of RonJeffries
> Sent: Thursday, June 28, 2012 3:29 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Agile adoption benefits and limitations research:seeking
> for agile practitioners
>
> I did not see anyone saying that lean / agile approaches have no plan.
> Did I miss a memo?
> R
> On Jun 28, 2012, at 3:26 PM, Darian Lanx wrote:
>
> > Kay A Pentecost wrote:
> > > Hi, Adam,
> > >
> > > Where did you get the idea that organizations with lean and agile
> approaches
> > > have no plan??
> > >
> > > Kay Pentecost
> > >
> > Just to jump on the bandwagon. I would also like to know where that
> > misconception comes from.
>
>
> Ron Jeffries
> www.XProgramming.com
> Everything that needs to be said has already been said.
> But since no one was listening, everything must be said again. -- Andre
> Gide
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

Hi Adam,

The whole premise that opinion surveys in any way contribute to actual
research is totally flawed, unless your work is being done in a field such
as psychology or marketing, where perception is the reality being studied.
  The raw opinions of an uncontrolled sample is just noise.  I am not the
only one who refuses in participating in the echoing of that noise.

If you want to understand agile well enough to contribute to academic
knowledge about it, you must actively observe a sample of real agile
projects somewhat intimately.  Of course, the more actual experience doing
agile software development, the more informed your study can be.

Granted, collecting nosy, biased opinions does enable you to prove to your
committee that you know how to do statistical analysis.  But the data is
meaningless, so the analysis can lead to no valid conclusions (unless you
are studying the perception of agile rather than agile itself).

Steven Gordon, PhD

On Thu, Jun 28, 2012 at 2:06 AM, agileadam8 <solinski.a@...> wrote:

> **
>
>
> Dear Practitioners,
>
> There is a great opportunity to contribute to the knowledge of lean and
> agile development! We are looking for organizations/companies/practitioners
> that are willing to share their experience with agile approaches. You will
> get feedback from researchers belonging to a high-ranked research
> institution. Once the research is completed, the results will be shared
> among the participants and all the known agile communities!
>
> The research is addressed to anybody who interacts with software
> development processes, both: adopters that have used agile for some time as
> well as new adopters. Each organization/company provides answers from
> different perspectives (e.g., development, project management, product
> management, quality assurance, etc.). The goal is to receive as many
> answers as possible for each perspective. All data will be kept anonymous.
>
> The survey is available at: http://goo.gl/Cl4Ku It will only take you
> approximately 20 minutes to complete the survey.
>
> The situation: A number of researches have shown that organizations move
> from their plan-driven approaches toward lean and agile methodologies. That
> leads to both: benefits and limitations. Moreover, what has been observed
> is that the applied methodologies are very often hybrids of agile and
> plan-driven approaches (eg. Scrum + XP, XP + V-model etc.).
>
> The problem: the effects of using agile methods in industry are not well
> understood. Process changes can affect a variety of parameters, like
> productivity, quality, motivation, etc. There is little information of what
> organizations expect from agile adoption and what they actually achieve
> over time (short-term vs. long-term).
>
> The instrument: the survey consists of a few steps. First you will be
> asked to provide context information to allow further results comparisons.
> Secondly, you will be asked to define your organization/company development
> process in terms of agile and plan-driven practices. Then, using cumulative
> voting method you will be asked to rank agile adoption benefits and
> limitations that you are experiencing with your current development
> approach.
>
> Please direct any questions or feedback to my account or just post below.
> I will do my best to reply ASAP. Thank you in advance,
>
> Kind regards,
> Adam
>
> P.S. We would be grateful if you could distribute the survey further in
> agile communities. http://goo.gl/Cl4Ku
>
>
>


[Non-text portions of this message have been removed]

Hi everybody,

First, I would like to thank you for your interest in the survey. Could you
indicate where the idea of "no plan" is mentioned in the survey? That would
be a misconception, however, I would have never meant that on purpose.
Thanks in advance,

Regards,
Adam


[Non-text portions of this message have been removed]

Hi Kay,

On Jun 28, 2012, at 4:54 PM, Kay A Pentecost wrote:

> The OP wrote: "A number of researches have shown that organizations move
> from their plan-driven approaches toward lean and agile methodologies."
>
> The implication is that lean/agile organizations are not "plan-driven."


That is correct, at least for Agile. Agile is not plan driven.  Not being
plan-driven does not mean "does not have a plan". The term might be seen as
referring to  such ideas as "responding to change over following a plan".

I do not know what the OP thinks. I do know that what he said does not imply
"does not have a plan" as I understand English, and logic.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide



[Non-text portions of this message have been removed]

Hi, Adam,

I didn't take the survey, and I won't, so I can't show you where *anything*
is mentioned in the survey.  I did quote, in my previous post, exactly where
the term "plan-driven" existed in your email, and in the post to Ron why I
objected to it.

I further suggest that you replace "plan-driven" in your description of the
survey with something more accurate. Perhaps organizations using
"traditional methods,"  or "classical methods," or "waterfall" or "code and
fix."  Even if you used "plan-driven" there are plenty of different
methodologies used in the wild... Many, in my experience who claim to be
using a specific methodology, but in reality are just doing "code and fix."

But that's a whole other can of worms...

Kay Pentecost



> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Solinski
> Sent: Thursday, June 28, 2012 4:52 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Agile adoption benefits and limitations research:seeking
> for agile practitioners
>
> Hi everybody,
>
> First, I would like to thank you for your interest in the survey. Could
> you
> indicate where the idea of "no plan" is mentioned in the survey? That
> would
> be a misconception, however, I would have never meant that on purpose.
> Thanks in advance,
>
> Regards,
> Adam
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

+1

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Steven Gordon
> Sent: Thursday, June 28, 2012 5:07 PM
> To: extremeprogramming@yahoogroups.com; solinski.a@...
> Subject: Re: [XP] Agile adoption benefits and limitations research:seeking
> for agile practitioners
>
> Hi Adam,
>
> The whole premise that opinion surveys in any way contribute to actual
> research is totally flawed, unless your work is being done in a field such
> as psychology or marketing, where perception is the reality being studied.
>  The raw opinions of an uncontrolled sample is just noise.  I am not the
> only one who refuses in participating in the echoing of that noise.
>
> If you want to understand agile well enough to contribute to academic
> knowledge about it, you must actively observe a sample of real agile
> projects somewhat intimately.  Of course, the more actual experience doing
> agile software development, the more informed your study can be.
>
> Granted, collecting nosy, biased opinions does enable you to prove to your
> committee that you know how to do statistical analysis.  But the data is
> meaningless, so the analysis can lead to no valid conclusions (unless you
> are studying the perception of agile rather than agile itself).
>
> Steven Gordon, PhD
>
> On Thu, Jun 28, 2012 at 2:06 AM, agileadam8 <solinski.a@...> wrote:
>
> > **
> >
> >
> > Dear Practitioners,
> >
> > There is a great opportunity to contribute to the knowledge of lean and
> > agile development! We are looking for
> organizations/companies/practitioners
> > that are willing to share their experience with agile approaches. You
> will
> > get feedback from researchers belonging to a high-ranked research
> > institution. Once the research is completed, the results will be shared
> > among the participants and all the known agile communities!
> >
> > The research is addressed to anybody who interacts with software
> > development processes, both: adopters that have used agile for some time
> as
> > well as new adopters. Each organization/company provides answers from
> > different perspectives (e.g., development, project management, product
> > management, quality assurance, etc.). The goal is to receive as many
> > answers as possible for each perspective. All data will be kept
> anonymous.
> >
> > The survey is available at: http://goo.gl/Cl4Ku It will only take you
> > approximately 20 minutes to complete the survey.
> >
> > The situation: A number of researches have shown that organizations move
> > from their plan-driven approaches toward lean and agile methodologies.
> That
> > leads to both: benefits and limitations. Moreover, what has been
> observed
> > is that the applied methodologies are very often hybrids of agile and
> > plan-driven approaches (eg. Scrum + XP, XP + V-model etc.).
> >
> > The problem: the effects of using agile methods in industry are not well
> > understood. Process changes can affect a variety of parameters, like
> > productivity, quality, motivation, etc. There is little information of
> what
> > organizations expect from agile adoption and what they actually achieve
> > over time (short-term vs. long-term).
> >
> > The instrument: the survey consists of a few steps. First you will be
> > asked to provide context information to allow further results
> comparisons.
> > Secondly, you will be asked to define your organization/company
> development
> > process in terms of agile and plan-driven practices. Then, using
> cumulative
> > voting method you will be asked to rank agile adoption benefits and
> > limitations that you are experiencing with your current development
> > approach.
> >
> > Please direct any questions or feedback to my account or just post
> below.
> > I will do my best to reply ASAP. Thank you in advance,
> >
> > Kind regards,
> > Adam
> >
> > P.S. We would be grateful if you could distribute the survey further in
> > agile communities. http://goo.gl/Cl4Ku
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

Hey everybody,

Are Plan-Driven Methodologies limited to RUP, PSP and TSP?

When did the term appear first?  And in what context?

Did the term originate in the field or in academia?

What is important about the term, and what is important of the
methodologies?

Please educate me.

Kay Pentecost

Hey, Ron,

After checking Google, I see that there is an accepted definition for
plan-driven methodologies, so I retract my comment for people who knew that
definition.

I must have missed *that* memo.

I'll also retract my message about being more accurate and using terms like
"waterfall" or "classic methodologies."

Ignorance is bliss.

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of RonJeffries
> Sent: Thursday, June 28, 2012 5:24 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Agile adoption benefits and limitations research:seeking
> for agile practitioners
>
> Hi Kay,
>
> On Jun 28, 2012, at 4:54 PM, Kay A Pentecost wrote:
>
> > The OP wrote: "A number of researches have shown that organizations move
> > from their plan-driven approaches toward lean and agile methodologies."
> >
> > The implication is that lean/agile organizations are not "plan-driven."
>
>
> That is correct, at least for Agile. Agile is not plan driven.  Not being
> plan-driven does not mean "does not have a plan". The term might be seen
> as referring to  such ideas as "responding to change over following a
> plan".
>
> I do not know what the OP thinks. I do know that what he said does not
> imply "does not have a plan" as I understand English, and logic.
>
> Ron Jeffries
> www.XProgramming.com
> Everything that needs to be said has already been said.
> But since no one was listening, everything must be said again. -- Andre
> Gide
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>