I only wanted to inform the world that he has done some research on the
subject. Forgot to mention that that both he and his wife (also a doctorate
on the same subject) have worked in this field of "Value Clarification" for
about 20 years, coached and trained over 5000 people worldwide on this
subject and have received raving feedback from the people they have coached
right from CEOs or large companies to young professionals in all industries
alike.

Lucky for them, they do not belong to the software industry and they are not
like those self styled consultants we have in our industry, like me, who
have become consultants not by choice but by default, because they couldn't
implement software that they could build.

I keep joking with my clients that consultants and trainers in our industry
become so, because they would not get a better job to do. This is surely not
true for consultants and thought leaders in the other mature industries.

Kripanidhi


Posted by: "Steven Gordon" sgordonphd@... on Sat May 31, 2008 6:31
am(PDT)

On Fri, May 30, 2008 at 10:33 PM, S M Kripanidhi wrote:

>> I wrote a paper on the Concept of Credibility Index over 2 years ago
> jointly with Dr.Sampath. He holds a Doctorate on Values. We both
> consult on this domain.

Sorry, but claiming a Doctorate on Values strains credibility.

On May 30, 2008, at 15:26 , jhrothjr wrote:

> Here's a very recent study that supports the notion that estimating is
> naturally logarithmic rather than linear. If anyone is collecting
> studies supporting various XP practices, this might fit.
>
> http://www.sciencedaily.com/releases/2008/05/080529141344.htm
>
Over short distances/ranges, what's the difference? Log, linear,
exponential, it's all the same. All the more reason narrow ranges are
key.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 30, 2008, at 02:24 , Amanda Abelove wrote:
> Sounds complicated. Agile and Scrum are about making money for the
> company,
> either by helping free up resources to take advantage of new
> opportunities,
> or reduce overhead spent on useless IT projects. Any company that is
> spending too much money on useless IT projects wants a product that
> will
> help it not waste money.
>
Agile is about returning the focus to streams of realizable business
value, whatever that means: additional revenue streams, improved
revenue streams, earlier realization of revenue, reduced costs,
shorter payback periods, and more.
> Most companies end up wasting money implementing Agile and Scrum
> processes.
> As products on the whole, Agile and Scrum have a very high field
> failure
> rate. If they were children's toys, they'd have been recalled by now.
>
Compared to what?
> So,.. The question isn't who wants to adopt them, but who will spend
> money
> to adopt them and why do they still believe despite empirical
> evidence that
> Agile and Scrum are not successful products?
>
Compared to what?
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 29, 2008, at 13:59 , Ant Grinyer wrote:
> Having worked in software development for over 15 years in many
> organisations using different development methodologies such as
> waterfall, RUP, SCRUM and XP, I'm still not sure if there is a
> specific `type' of organisation that is more likely to adopt
> agile approaches than others?
>
I can interpret your question at least two ways, and I'd like to know
what you meant when you asked it.

One interpretation, "Is there a specific type of organization more
likely to attempt to adopt agile approaches?"

Another: "Is there a specific type of organization more likely to reap
benefit (by their measure) from agile approaches?"

I don't want to look for a third interpretation. :)
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 28, 2008, at 07:22 , Doug Swartz wrote:
> eBay reviews are essentially anonymous, although you can see
> what others have said about the reviewer, and all of the
> reviewers reviews. Is this anonymity a good thing, or bad
> thing? Would it work in our environment?
>
My clients would likely want to be anonymous, but I don't mind putting
my name on some reviews.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 28, 2008, at 08:06 , S M Kripanidhi wrote:
> I thought we guys in XP trust each other, are honest, open and have
> the courage to say the truth.
>
> Have we changed our values in XP
>
I trust my client will help me deliver our project, but that doesn't
necessarily mean I trust everyone all the time to do anything.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On Sun, Jun 1, 2008 at 6:07 PM, J. B. Rainsberger <jbrains762@...> wrote:
> On May 28, 2008, at 07:22 , Doug Swartz wrote:
>> eBay reviews are essentially anonymous, although you can see
>> what others have said about the reviewer, and all of the
>> reviewers reviews. Is this anonymity a good thing, or bad
>> thing? Would it work in our environment?
>>
> My clients would likely want to be anonymous, but I don't mind putting
> my name on some reviews.

I do nto think allowing anonymous reviews will add any kind of
accountability to what you are saying or whom you are endorsing with
them. Anonymous feedback loops in community driven environments should
be banned when it comes to other people's opinions being based on
those endorsements.

-d

> ----
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contributions to Agile Software Practice
>
>
> ------------------------------------
>
> 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
>
>
>
>



--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

On May 30, 2008, at 13:54 , Laurent Bossavit wrote:

> Hi Ron,
>
> > I'm troubled already by a spate of vouchers stating that Joe Smith
> > is capable in skill Mumble because I, Suzy Brown, taught him in my
> > course.
>
> Could you point to an example ? I couldn't find one.
>
> In a sense that is already a success: we've gathered some actual data
> from running WeVouchFor, and we're learning that people are entering
> some certifications that we consider "good" and some that we consider
> "bad". If nothing else, we've honed our judgement.
>
> The next step would be to figure out how you can say "I'm troubled" to
> the system, rather than to me.
>
"Did you find this review helpful? Yes/No"
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 29, 2008, at 05:57 , Ron Jeffries wrote:

> Hello, George. On Thursday, May 29, 2008, at 12:29:34 AM, you
> wrote:
>
> > Ron Jeffries wrote:
> >> It's hard for me to see how to distinguish this list from a mutual
> >> admiration society, or a popularity contest. It's hard for me to
> see
> >> why it doesn't turn into a quid-pro-quo list. I think it's an
> >> interesting idea and I fear that it can't possibly work. The only
> >> thing I fear more is that it will seem to work.
>
> > Work for what purpose?
>
> I'm concerned that it will seem to work as a purpose to find good
> help. (But that in fact it won't.)
>
We could add feedback to the system. Give clients anonymity and let
them add a review saying "I hired Joe to teach my team to do TDD,
based on recommendations from Ron, Kent and Ward; but Joe was a
complete bust. What a moron. I'd never hire him again, and I don't
know what Ron, Kent and Ward were thinking."

I don't know how to motivate clients to write that review, but I think
it might address your concern.

Take care.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On May 28, 2008, at 22:24 , Chris Wheeler wrote:

> On Wed, May 28, 2008 at 10:56 PM, George Dinwiddie <lists@...
> >
> wrote:
>
> >
> > No, WeVouchFor isn't a review system, it's a chain of trust. If the
> > recommendation is by someone you trust, it means a lot. Perhaps
> it's by
> > someone who is trusted by someone you trust. Then it means less, but
> > still something.
>
> There are people on that list that I trust. Yet, when I read the
> reviews of
> those trusted people, written by people who were endorsed by the same
> trusted people, the LinkedIn effect kicks in for me - that is, I
> everyone
> recommends everyone, invalidating all recommends.
>
> The currency isn't rare enough.
>
I have another explanation to venture: I am only reminded to recommend
people for something when I see they have recommended me for
something. For me to dump my brain and recommend everyone I can think
of would take, well, days. I think it's quite natural, in the first
year, for there to be a lot of what you're seeing, for the reason I
cite here.

Take care.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

I've been meaning to read Bob Martin's for a while. I see there's a C#
edition and a Java/C++ one. I don't code any of these languages
professionally but I can understand them just fine. Any recommendation
on which one to get? Does it matter?

Pat

On Sun, Jun 1, 2008 at 6:43 PM, J. B. Rainsberger <jbrains762@...> wrote:
>
> On May 29, 2008, at 05:57 , Ron Jeffries wrote:
>
>> Hello, George. On Thursday, May 29, 2008, at 12:29:34 AM, you
>> wrote:
>>
>> > Ron Jeffries wrote:
>> >> It's hard for me to see how to distinguish this list from a mutual
>> >> admiration society, or a popularity contest. It's hard for me to
>> see
>> >> why it doesn't turn into a quid-pro-quo list. I think it's an
>> >> interesting idea and I fear that it can't possibly work. The only
>> >> thing I fear more is that it will seem to work.
>>
>> > Work for what purpose?
>>
>> I'm concerned that it will seem to work as a purpose to find good
>> help. (But that in fact it won't.)
>>
> We could add feedback to the system. Give clients anonymity and let
> them add a review saying

As I mentioned before anoymity removes accountability and that is the
last thing we want.

-d


--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

On Sat, 31 May 2008, Julian Hall wrote:

> There's a missing option in the poll, which most closely describes the
> way I feel: "I would use it, but it makes refactoring harder."

Ah! This is exactly the sort of thing I wanted to shake loose!

Now if you could explain why you believe that, it would be very interesting.

Why do I find it so interesting? Because I believe the opposite!

Whenever I start refactoring I sprinkling the code with a good bracing
of pre/post/invariant asserts documenting (in an executable way) how I
believe the internals of this stuff is working (or should work.)

I then run the unit tests, maybe adding a few more unit tests along
the way.

Often this phase coughs up a few false assumptions that I
made, or finds pre-existing bugs.

I then hack and slash the code, knowing that my brace of exo-tests (unit
tests) or endo-tests (pre/post/invariant asserts) will catch 99% of my
idiocy.

I find this doubly valuable in a dynamic language without static type
checking. like Ruby.

Static typing is sort of "check how I said it", DbC is sort of "check
do I mean what I said".

The important aspect of DbC and refactoring is DbC informs my design
taste. What is a Good Destination for a refactoring? One in which my
Invariant is better protected.

What is a Code Smell? A design where my invariant can be clobbered by
client code.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

+ 1


Kripanidhi


--- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@...>
wrote:
>
> On Sun, Jun 1, 2008 at 6:07 PM, J. B. Rainsberger <jbrains762@...>
wrote:
> > On May 28, 2008, at 07:22 , Doug Swartz wrote:
> >> eBay reviews are essentially anonymous, although you can see
> >> what others have said about the reviewer, and all of the
> >> reviewers reviews. Is this anonymity a good thing, or bad
> >> thing? Would it work in our environment?
> >>
> > My clients would likely want to be anonymous, but I don't mind
putting
> > my name on some reviews.
>
> I do nto think allowing anonymous reviews will add any kind of
> accountability to what you are saying or whom you are endorsing with
> them. Anonymous feedback loops in community driven environments
should
> be banned when it comes to other people's opinions being based on
> those endorsements.
>
> -d
>
> > ----
> > J. B. (Joe) Rainsberger :: http://www.jbrains.ca
> > Your guide to software craftsmanship
> > JUnit Recipes: Practical Methods for Programmer Testing
> > 2005 Gordon Pask Award for contributions to Agile Software
Practice
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to:   extremeprogramming@...
> >
> > To Unsubscribe, send a blank message to: extremeprogramming-
unsubscribe@...
> >
> > ad-free courtesy of objectmentor.comYahoo! Groups Links
> >
> >
> >
> >
>
>
>
> --
> Sent from gmail so do not trust this communication.
> Do not send me sensitive information here, ask for my none-gmail
accounts.
>
> "Therefore the considerations of the intelligent always include both
> benefit and harm." - Sun Tzu
>

Yes Indeed we should do that and use it to build the "Credibility
Index" of the Reviewers/Vouchers.

I had a wonderful experience when I wanted to give a negative
feedback to a vendor on ebay after I purchased an item from that
vendor.

First ebay explains the implications of a negative feedback.

Second, after that, it forces you to take a tutorial on implications
of negative feedback on ebay

Third, it forces a delay in your ability to provide negative feedback
so that the feedback is not impulsive  (just like the judge forces
divorce applicants to wait for some time before they are heard
again...I did not go through one of those experiences)

This way we can ensure the credibility and integrity of the negative
feedback and can to some extent ensure that they were considered
decions and not impulsive anger.

Kripanidhi

--- In extremeprogramming@yahoogroups.com, "J. B. Rainsberger"
<jbrains762@...> wrote:
>
>
> On May 29, 2008, at 05:57 , Ron Jeffries wrote:
>
> > Hello, George. On Thursday, May 29, 2008, at 12:29:34 AM, you
> > wrote:
> >
> > > Ron Jeffries wrote:
> > >> It's hard for me to see how to distinguish this list from a
mutual
> > >> admiration society, or a popularity contest. It's hard for me
to
> > see
> > >> why it doesn't turn into a quid-pro-quo list. I think it's an
> > >> interesting idea and I fear that it can't possibly work. The
only
> > >> thing I fear more is that it will seem to work.
> >
> > > Work for what purpose?
> >
> > I'm concerned that it will seem to work as a purpose to find good
> > help. (But that in fact it won't.)
> >
> We could add feedback to the system. Give clients anonymity and
let
> them add a review saying "I hired Joe to teach my team to do TDD,
> based on recommendations from Ron, Kent and Ward; but Joe was a
> complete bust. What a moron. I'd never hire him again, and I don't
> know what Ron, Kent and Ward were thinking."
>
> I don't know how to motivate clients to write that review, but I
think
> it might address your concern.
>
> Take care.
> ----
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contributions to Agile Software Practice
>

I suggested this in the WeVouchFor thread, but it didn't seem to get any
traction.

It would seem to be that when you want to know how well someone is
doing, in the software industry, there are two things you want. A proven
track record, and recent experience.

The problem with certifications and online vouches is that they are
text, so they don't go away.

Would you as an individual be willing to really "vouch" for someone -
that is, provide some sort of contact information, whether by email,
phone, IM, etc, where someone could get a hold of you to talk about a
specific individual's experience?

We'd perhaps have to have safeguards like I have to approve you if you
want to vouch for me, but it seems like the simple act of requiring
actual contact with the vouching party would help reduce many of the
issues (though not all).

--
Cory Foy
http://www.cornetdesign.com

On Jun 1, 2008, at 12:19 , David H. wrote:

> On Sun, Jun 1, 2008 at 6:07 PM, J. B. Rainsberger <jbrains762@...
> > wrote:
> > On May 28, 2008, at 07:22 , Doug Swartz wrote:
> >> eBay reviews are essentially anonymous, although you can see
> >> what others have said about the reviewer, and all of the
> >> reviewers reviews. Is this anonymity a good thing, or bad
> >> thing? Would it work in our environment?
> >>
> > My clients would likely want to be anonymous, but I don't mind
> putting
> > my name on some reviews.
>
> I do nto think allowing anonymous reviews will add any kind of
> accountability to what you are saying or whom you are endorsing with
> them. Anonymous feedback loops in community driven environments should
> be banned when it comes to other people's opinions being based on
> those endorsements.
>
While I agree with this, real client feedback can help mitigate the
"old boys network" effect. My clients, for legal reasons, are
unwilling to admit that they need my services, and so if they cannot
remain anonymous, then I cannot get their feedback. I imagine most
other consultants find themselves in the same situation. I do not know
another way to solve it.

Do you have another solution that allows my clients to give their
feedback safely?
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

On Jun 1, 2008, at 20:54 , Cory Foy wrote:

> I suggested this in the WeVouchFor thread, but it didn't seem to get
> any
> traction.
>
> It would seem to be that when you want to know how well someone is
> doing, in the software industry, there are two things you want. A
> proven
> track record, and recent experience.
>
> The problem with certifications and online vouches is that they are
> text, so they don't go away.
>
> Would you as an individual be willing to really "vouch" for someone -
> that is, provide some sort of contact information, whether by email,
> phone, IM, etc, where someone could get a hold of you to talk about a
> specific individual's experience?
>
> We'd perhaps have to have safeguards like I have to approve you if you
> want to vouch for me, but it seems like the simple act of requiring
> actual contact with the vouching party would help reduce many of the
> issues (though not all).
>
I would agree to allowing others to initiate contact by e-mail.
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice

Interesting thought. Although I'd wince at entering contact info. I can
always send the person that wants to buy from me an email with my
references. Plus just allowing people that vouched for me to get emails
lowers my personal brand. Unless I am about to close a deal, I don't want to
bother my references. They are busy people.



If a recruiter or a coworker wants my endorsement, but I don't feel
comfortable, can I choose a lower level of endorsement like "Thanks to?"
Like "Thanks to Bob, I chose the right training school." Or something less
than an endorsement?







   _____

From: J. B. Rainsberger [mailto:jbrains762@...]
Sent: Sunday, June 01, 2008 7:49 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Really Vouching For someone




On Jun 1, 2008, at 20:54 , Cory Foy wrote:

> I suggested this in the WeVouchFor thread, but it didn't seem to get
> any
> traction.
>
> It would seem to be that when you want to know how well someone is
> doing, in the software industry, there are two things you want. A
> proven
> track record, and recent experience.
>
> The problem with certifications and online vouches is that they are
> text, so they don't go away.
>
> Would you as an individual be willing to really "vouch" for someone -
> that is, provide some sort of contact information, whether by email,
> phone, IM, etc, where someone could get a hold of you to talk about a
> specific individual's experience?
>
> We'd perhaps have to have safeguards like I have to approve you if you
> want to vouch for me, but it seems like the simple act of requiring
> actual contact with the vouching party would help reduce many of the
> issues (though not all).
>
I would agree to allowing others to initiate contact by e-mail.
----
J. B. (Joe) Rainsberger :: http://www.jbrains. <http://www.jbrains.ca> ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice





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

Like oDesk?



On May 28, 2008, at 07:22 , Doug Swartz wrote:
> eBay reviews are essentially anonymous, although you can see
> what others have said about the reviewer, and all of the
> reviewers reviews. Is this anonymity a good thing, or bad
> thing? Would it work in our environment?
>
My clients would likely want to be anonymous, but I don't mind putting
my name on some reviews.







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

Please come to

www.i-vouch-for-waterfall.com

This site is done by many experienced software professionals who know
how to waterfall methodology correctly.

This site is supported by experienced developers, project managers,
many 6-sigma people, a lot of quality professionals, and many people
who believes in Waterfall.



OK, that is a joke. The moral is: reference within the framework does
not prove or un-prove the framework.

What we are practicing is not religion.  It has to be something
supported by stories and facts.

Probably it be helpful to grow the community, by creating one site
(provenagile.org), with real life software projects, and practices
using Agile practices, with masked project/company names, but real
professional names.  By dumping real-life project stories to the site,
the desperate project sponsors may get a better handle what agile is,
and the professionals get better vouching.

Probably that can achieve similar effect as wevouchfor.

Just my 2 cents.

~Andrew Chen
Automate acceptance testing
Agile Lamp - http://code.google.com/p/agilelamp/

I'm struggling with this on a product right now. Writing on someone's wall
is too vague. A personal endorsement is awkward and socially uncomfortable.
I've come up with sending "I owe you # beer(s) for." republishing on
twitter, counting up the beer points on the profile. I'm toying with
creating mad lib style thank you notes.



Entry:



"Thanks to [Pradeep] our project delivered value [better / faster / cheaper
/ smarter]. His role was [Project Manager]."

[Comment]



Profile:



Pradeep Maharesh

(pic)

(Last twitter | Follow)



Pradeep is owed 2,003 beers.

10 people said Pradeep made their last project smarter.

3 people said Pradeep made their last project better.



Comments:



[thumbnail] "Pradeep is super sharp and detail oriented. He never misses the
mark." - Barney S.

[thumbnail] "When I get my PMP, I want to be like Pradeep." - Wan Chen



Who does Pradeep owe a beer to?

Who's helped Pradeep?



Dunno if that helps.



A



   _____

From: Cory Foy [mailto:usergroup@...]
Sent: Sunday, June 01, 2008 6:55 PM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Really Vouching For someone



I suggested this in the WeVouchFor thread, but it didn't seem to get any
traction.

It would seem to be that when you want to know how well someone is
doing, in the software industry, there are two things you want. A proven
track record, and recent experience.

The problem with certifications and online vouches is that they are
text, so they don't go away.

Would you as an individual be willing to really "vouch" for someone -
that is, provide some sort of contact information, whether by email,
phone, IM, etc, where someone could get a hold of you to talk about a
specific individual's experience?

We'd perhaps have to have safeguards like I have to approve you if you
want to vouch for me, but it seems like the simple act of requiring
actual contact with the vouching party would help reduce many of the
issues (though not all).

--
Cory Foy
http://www.cornetde <http://www.cornetdesign.com> sign.com





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

Hello, Andrew.  On Monday, June 2, 2008, at 12:24:28 AM, you wrote:

> Probably that can achieve similar effect as wevouchfor.

But wevouchfor is about vouching for individuals as good coaches or
programmers or testers or such. It is not about vouching for Agile.

Ron Jeffries
www.XProgramming.com
Those who believe complexity is elegant or required don't understand
the problem. -- John Streiff

How much planning is too much/too little?  I understand that there are
a lot of variables that go into answering this.  I'll give details of
my team's particular situation and hopefully spur good discussion.

We're experiencing problems that I believe are due to our planning
process.  At the beginning of the iteration we sit down with my boss
(who plays the customer role) to come up with new stories and to
review the prioritization of existing stories.

The key problem we have is that we get a lot of stories rejected.  I'd
say about a third of the stories we do get rejected and need
additional work.  I believe that it's because we don't develop a deep
enough shared understanding with the customer's needs.  We're finding
it pretty difficult to do though.  A very common convo/situation goes
like the following:

Customer: "I want to show a list of locations where events were
previously scheduled."
Dev: "Okay.  Maybe a grid with the location name and address?"
C: "Yeah, that sounds good.  And let's embed the Google Map view also"
D: "Great.  Let's do a quick sketch to see what it might look like."
C: "I don't really care what it looks like.  Anything will be fine"
*we go to work, mark the story delivered.  at the end of the
iteration, customer rejects it saying it doesn't look right*

This is really frustrating from a developer standpoint.  One issue is
that it just doesn't feel good to have our work constantly rejected.
How much that counts or should count, I don't know.  More importantly,
it screws with our planning.  If we've completed a story, but then
have to allocate time in the next iteration to fix problems with it,
then we push back things that were planned for that iteration.  I
think that's okay in small amounts, but it makes our planning less
useful because we can't accurately estimate what we'll be able to get
to.

The first obvious thing to do is to explain to the customer the
problems this causes.  We've said in the past that we'd like to do
some deeper planning because we don't like having the stories
rejected.  The customer said it wasn't a really big deal to him that
we'd deliver a story and that he'd reject it, with specific items to
find.  I've pointed out that it hurts our productivity because it
requires us to switch contexts a couple days after the fact.  I
haven't said that it messes up our planning, because I hadn't really
thought of it until I wrote this message.  I'm not sure what impact
that will have, as my boss doesn't seem to find XP-style planning
particularly valuable.  He appears to feel that everything needs to
get done, and it doesn't really matter in what order.

I believe all of this is hurting the team's productivity.  I'm having
a tough time getting into the customer's head and framing my concerns
in a way that really matters to him.

Finally, I think there's a stigma against doing too much planning.
We're doing about 3 hours of planning a week, which I don't consider
to be very much.  So I realize this would vary a great deal from
project to project, but what is an "average" time to spend planning in
a week?

Pat

Have you tried pursuing acceptance during the iteration?  Iterations
need not be miniature black boxes.  As soon as something is able to be
played with, even if not complete, have the customer try it.  "Is this
what you were thinking?"  Then the requirements elaboration resulting
from use of the actual application becomes a normal part of the
iteration.  The customer then becomes part of the solution - helping to
figure out requirements and driving towards acceptance before the end of
the iteration...less spillover.

I believe that trying harder to figure it all out won't result in much
more true clarity (maybe some UCD (user-centered design) practices would
help, but there will still be things that aren't realized till the
customer tries it).

Pat Maddox wrote:
>
> How much planning is too much/too little? I understand that there are
> a lot of variables that go into answering this. I'll give details of
> my team's particular situation and hopefully spur good discussion.
>
> We're experiencing problems that I believe are due to our planning
> process. At the beginning of the iteration we sit down with my boss
> (who plays the customer role) to come up with new stories and to
> review the prioritization of existing stories.
>
> The key problem we have is that we get a lot of stories rejected. I'd
> say about a third of the stories we do get rejected and need
> additional work. I believe that it's because we don't develop a deep
> enough shared understanding with the customer's needs. We're finding
> it pretty difficult to do though. A very common convo/situation goes
> like the following:
>
> Customer: "I want to show a list of locations where events were
> previously scheduled."
> Dev: "Okay. Maybe a grid with the location name and address?"
> C: "Yeah, that sounds good. And let's embed the Google Map view also"
> D: "Great. Let's do a quick sketch to see what it might look like."
> C: "I don't really care what it looks like. Anything will be fine"
> *we go to work, mark the story delivered. at the end of the
> iteration, customer rejects it saying it doesn't look right*
>
> This is really frustrating from a developer standpoint. One issue is
> that it just doesn't feel good to have our work constantly rejected.
> How much that counts or should count, I don't know. More importantly,
> it screws with our planning. If we've completed a story, but then
> have to allocate time in the next iteration to fix problems with it,
> then we push back things that were planned for that iteration. I
> think that's okay in small amounts, but it makes our planning less
> useful because we can't accurately estimate what we'll be able to get
> to.
>
> The first obvious thing to do is to explain to the customer the
> problems this causes. We've said in the past that we'd like to do
> some deeper planning because we don't like having the stories
> rejected. The customer said it wasn't a really big deal to him that
> we'd deliver a story and that he'd reject it, with specific items to
> find. I've pointed out that it hurts our productivity because it
> requires us to switch contexts a couple days after the fact. I
> haven't said that it messes up our planning, because I hadn't really
> thought of it until I wrote this message. I'm not sure what impact
> that will have, as my boss doesn't seem to find XP-style planning
> particularly valuable. He appears to feel that everything needs to
> get done, and it doesn't really matter in what order.
>
> I believe all of this is hurting the team's productivity. I'm having
> a tough time getting into the customer's head and framing my concerns
> in a way that really matters to him.
>
> Finally, I think there's a stigma against doing too much planning.
> We're doing about 3 hours of planning a week, which I don't consider
> to be very much. So I realize this would vary a great deal from
> project to project, but what is an "average" time to spend planning in
> a week?
>
> Pat
>
>


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

Hello, Pat.  On Monday, June 2, 2008, at 7:33:04 AM, you wrote:

> How much planning is too much/too little?  I understand that there are
> a lot of variables that go into answering this.  I'll give details of
> my team's particular situation and hopefully spur good discussion.

> We're experiencing problems that I believe are due to our planning
> process.  At the beginning of the iteration we sit down with my boss
> (who plays the customer role) to come up with new stories and to
> review the prioritization of existing stories.

> The key problem we have is that we get a lot of stories rejected. I'd
> say about a third of the stories we do get rejected and need
> additional work.  I believe that it's because we don't develop a deep
> enough shared understanding with the customer's needs.  We're finding
> it pretty difficult to do though.  A very common convo/situation goes
> like the following:

> Customer: "I want to show a list of locations where events were
> previously scheduled."
> Dev: "Okay.  Maybe a grid with the location name and address?"
> C: "Yeah, that sounds good.  And let's embed the Google Map view also"
> D: "Great.  Let's do a quick sketch to see what it might look like."
> C: "I don't really care what it looks like.  Anything will be fine"
> *we go to work, mark the story delivered.  at the end of the
> iteration, customer rejects it saying it doesn't look right*

What if instead of rejecting it, the boss said, "OK, that's good,
now what I'd like is ... X", resulting in a new story?

After all, s/he said "I don't really care what it looks like," so it
is clearly passing that test.

So I'd take the boss aside and ask to have a story that meets the
criteria accepted and a new story created. That's probably the best
way to go with regard to look and feel anyway.

Or ...

What if when a new thing like this comes along, you do a first story
called "make the initial version" and a second story called "clean
up the initial version"?

Or ...

What if you drew the GUI on paper or mocked it up before doing the
work, and showed it to the boss?

Or ...

What if you said "OK, let's be sure we understand what you want,"
went to the whiteboard, and drew up a really stupid example of the
screen requested, and said "Like that?"  If the boss says Yes, then
leave the picture up and point to it when they go to reject. If the
boss says No, improve the sketch.

BTW, this is not planning, it's designing, as this example should
make clear.


Of these, my favorite is the first because the boss did say it
didn't matter. So they should say "OK, and what I'd like next is
... X." Then it wouldn't be rejection.

> This is really frustrating from a developer standpoint.  One issue is
> that it just doesn't feel good to have our work constantly rejected.
> How much that counts or should count, I don't know.  More importantly,
> it screws with our planning.  If we've completed a story, but then
> have to allocate time in the next iteration to fix problems with it,
> then we push back things that were planned for that iteration.  I
> think that's okay in small amounts, but it makes our planning less
> useful because we can't accurately estimate what we'll be able to get
> to.

Things planned for the next iteration? There is nothing planned for
the next iteration except what the customer asks for. If the
customer asks for more work on last week's story, so be it.

Managing the work into iterations is the boss's job. Your paragraph
above makes it sound to me as if somehow the plan belongs to you
(the developers?) rather than the boss.

> The first obvious thing to do is to explain to the customer the
> problems this causes.  We've said in the past that we'd like to do
> some deeper planning because we don't like having the stories
> rejected.  The customer said it wasn't a really big deal to him that
> we'd deliver a story and that he'd reject it, with specific items to
> find.

Customer is probably right. If it doesn't bother them, so be it. But
ask for another word.

It comes to me that both sides may be thinking that you are supposed
to take a story and complete everything about that story in one
iteration. That's not the case. A story is what you commit to do in
one iteration. If you do it, that story is done. If you don't like
how it looks or want to add a subtotal to it, then that is a new
story.

> I've pointed out that it hurts our productivity because it
> requires us to switch contexts a couple days after the fact.  I
> haven't said that it messes up our planning, because I hadn't really
> thought of it until I wrote this message.  I'm not sure what impact
> that will have, as my boss doesn't seem to find XP-style planning
> particularly valuable.  He appears to feel that everything needs to
> get done, and it doesn't really matter in what order.

IMO, that may be due to not understanding the impact of change. On
the other hand, XP planning is not about getting things right the
first time, it is about getting them right finally.

Are you estimating stories and laying them down roughly on the
calendar (Release Plan)?  Does the boss really have no deadline in
mind?

> I believe all of this is hurting the team's productivity.  I'm having
> a tough time getting into the customer's head and framing my concerns
> in a way that really matters to him.

I don't understand either.

Maybe it's not really affecting anything. Maybe it takes X time to
get the first version and Y time to clean it up. Maybe the

> Finally, I think there's a stigma against doing too much planning.
> We're doing about 3 hours of planning a week, which I don't consider
> to be very much.  So I realize this would vary a great deal from
> project to project, but what is an "average" time to spend planning in
> a week?

You didn't say how big your team was. I would think 3 hours a week
would be OK but not impressively low for most teams.

But again, I don't think you're asking for planning. I think you may
be worried about design.

Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear

I'm a little unclear on the situation - your boss says "do something
like this" and then he rejects the result, or is it that the end
customers are rejecting it?

I'd really like to recommend Jeff Patton's article on incremental vs.
iterative design:
<http://agileproductdesign.com/blog/dont_know_what_i_want.html>

I'd also consider - "who's got the problem?" It seems that the boss is
happy, the customers are happy, but the developers are not?

This weekend, I heard someone say something on the lines of "When
developers change their minds about the design, they call it
refactoring; when customers do it they call it fickle."

Alistair Cockburn has a nice view of this too - explicitly planning
stories as three rounds:
http://alistair.cockburn.us/index.php/Three_cards_for_user_rights

So, it's certainly possible that there are things going on that should
be improved on the customer side, but another possibility is that your
developers have unrealistic expectations about the difficulty of
specifying work, and that you're actually blessed with a customer that
"gets it" and doesn't resent the need for iteration.

(I'm reminded of an exercise: give one person a set of blocks,
arranged in a design of some sort. Another person sits facing away
with the same set of blocks (not having seen the arrangement). The
first person tells the person how to arrange them ("the spec"). Then
you might have a round where you let the specifier see what happened,
and try to give a spec to fix it. And finally have a round where the
specifier comes over to work directly with the builder ("move this
here").)

> So I realize this would vary a great deal from
> project to project, but what is an "average" time to spend planning in
> a week?
5-10% is what I use as a guideline, and you're in that range.

--Bill Wake    www.xp123.com

On Mon, Jun 2, 2008 at 7:33 AM, Pat Maddox <pergesu@...> wrote:
> The key problem we have is that we get a lot of stories rejected. I'd
> say about a third of the stories we do get rejected and need
> additional work. I believe that it's because we don't develop a deep
> enough shared understanding with the customer's needs. We're finding
> it pretty difficult to do though.

--
    Bill Wake  William.Wake@...  www.xp123.com

Acceptance Criteria like others have mentioned.  That seems key.  I'm
guessing it's pretty common for a customer to say "oh it doesn't matter" and
then when they get something turn around and say "oh gosh, that's not
right!".  Have that conversation up front.  Even if they say "it doesn't
matter".   See if the team can give a quick idea as to what it will
look/behave like.  Just take it the next step, rather than  having things
unsaid, just ask "if the team does that.  Will that satisfy this story?".

It seems like you're missing the final piece of a story conversation : what
does this story look like when it's completed.  What makes this story "done"
in the customer's mind.

On Mon, Jun 2, 2008 at 7:05 AM, Ron Jeffries <ronjeffries@...>
wrote:

>   Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:
>
> > How much planning is too much/too little? I understand that there are
> > a lot of variables that go into answering this. I'll give details of
> > my team's particular situation and hopefully spur good discussion.
>
> > We're experiencing problems that I believe are due to our planning
> > process. At the beginning of the iteration we sit down with my boss
> > (who plays the customer role) to come up with new stories and to
> > review the prioritization of existing stories.
>
> > The key problem we have is that we get a lot of stories rejected. I'd
> > say about a third of the stories we do get rejected and need
> > additional work. I believe that it's because we don't develop a deep
> > enough shared understanding with the customer's needs. We're finding
> > it pretty difficult to do though. A very common convo/situation goes
> > like the following:
>
> > Customer: "I want to show a list of locations where events were
> > previously scheduled."
> > Dev: "Okay. Maybe a grid with the location name and address?"
> > C: "Yeah, that sounds good. And let's embed the Google Map view also"
> > D: "Great. Let's do a quick sketch to see what it might look like."
> > C: "I don't really care what it looks like. Anything will be fine"
> > *we go to work, mark the story delivered. at the end of the
> > iteration, customer rejects it saying it doesn't look right*
>
> What if instead of rejecting it, the boss said, "OK, that's good,
> now what I'd like is ... X", resulting in a new story?
>
> After all, s/he said "I don't really care what it looks like," so it
> is clearly passing that test.
>
> So I'd take the boss aside and ask to have a story that meets the
> criteria accepted and a new story created. That's probably the best
> way to go with regard to look and feel anyway.
>
> Or ...
>
> What if when a new thing like this comes along, you do a first story
> called "make the initial version" and a second story called "clean
> up the initial version"?
>
> Or ...
>
> What if you drew the GUI on paper or mocked it up before doing the
> work, and showed it to the boss?
>
> Or ...
>
> What if you said "OK, let's be sure we understand what you want,"
> went to the whiteboard, and drew up a really stupid example of the
> screen requested, and said "Like that?" If the boss says Yes, then
> leave the picture up and point to it when they go to reject. If the
> boss says No, improve the sketch.
>
> BTW, this is not planning, it's designing, as this example should
> make clear.
>
> Of these, my favorite is the first because the boss did say it
> didn't matter. So they should say "OK, and what I'd like next is
> ... X." Then it wouldn't be rejection.
>
> > This is really frustrating from a developer standpoint. One issue is
> > that it just doesn't feel good to have our work constantly rejected.
> > How much that counts or should count, I don't know. More importantly,
> > it screws with our planning. If we've completed a story, but then
> > have to allocate time in the next iteration to fix problems with it,
> > then we push back things that were planned for that iteration. I
> > think that's okay in small amounts, but it makes our planning less
> > useful because we can't accurately estimate what we'll be able to get
> > to.
>
> Things planned for the next iteration? There is nothing planned for
> the next iteration except what the customer asks for. If the
> customer asks for more work on last week's story, so be it.
>
> Managing the work into iterations is the boss's job. Your paragraph
> above makes it sound to me as if somehow the plan belongs to you
> (the developers?) rather than the boss.
>
> > The first obvious thing to do is to explain to the customer the
> > problems this causes. We've said in the past that we'd like to do
> > some deeper planning because we don't like having the stories
> > rejected. The customer said it wasn't a really big deal to him that
> > we'd deliver a story and that he'd reject it, with specific items to
> > find.
>
> Customer is probably right. If it doesn't bother them, so be it. But
> ask for another word.
>
> It comes to me that both sides may be thinking that you are supposed
> to take a story and complete everything about that story in one
> iteration. That's not the case. A story is what you commit to do in
> one iteration. If you do it, that story is done. If you don't like
> how it looks or want to add a subtotal to it, then that is a new
> story.
>
> > I've pointed out that it hurts our productivity because it
> > requires us to switch contexts a couple days after the fact. I
> > haven't said that it messes up our planning, because I hadn't really
> > thought of it until I wrote this message. I'm not sure what impact
> > that will have, as my boss doesn't seem to find XP-style planning
> > particularly valuable. He appears to feel that everything needs to
> > get done, and it doesn't really matter in what order.
>
> IMO, that may be due to not understanding the impact of change. On
> the other hand, XP planning is not about getting things right the
> first time, it is about getting them right finally.
>
> Are you estimating stories and laying them down roughly on the
> calendar (Release Plan)? Does the boss really have no deadline in
> mind?
>
> > I believe all of this is hurting the team's productivity. I'm having
> > a tough time getting into the customer's head and framing my concerns
> > in a way that really matters to him.
>
> I don't understand either.
>
> Maybe it's not really affecting anything. Maybe it takes X time to
> get the first version and Y time to clean it up. Maybe the
>
> > Finally, I think there's a stigma against doing too much planning.
> > We're doing about 3 hours of planning a week, which I don't consider
> > to be very much. So I realize this would vary a great deal from
> > project to project, but what is an "average" time to spend planning in
> > a week?
>
> You didn't say how big your team was. I would think 3 hours a week
> would be OK but not impressively low for most teams.
>
> But again, I don't think you're asking for planning. I think you may
> be worried about design.
>
> Ron Jeffries
> www.XProgramming.com
> Fear is the mindkiller. --Bene Gesserit Litany Against Fear
>
>
>


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

Hello All,

   I just read the Alistair Cockburn article recommended by Bill Wake in the 'How
Much Planning Do We Need?' thread and it caused me to think about iteration
length.  I have been recommending iteration lengths of 1 to 2 weeks for some
time now.

Alistair's article caused me to wonder if iteration length should be some
function of Customer availability.

Should iteration length be some minimum multiple of the length of time between
Customer visits.

If your Customer is truly a member of the team and is in the team room every day
then very short iterations make sense.  If they they show up every week and a
half, then maybe they don't

--
Best regards,
  Chet                          mailto:lists@...

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

Pat,

It seems to me that this customer does not really know what they want
until the see something concrete.  The good news is that the customer
knows this and is not upset with the waste and slowness that results
from their inability to know what they really want.

Since the customer needs something concrete delivered in order to
figure out what they want, more detailed planning will only waste more
work before getting the customer something concrete to react to.

My suggestion is to do less instead of doing more.  If your iterations
were half as long and your stories were sliced half as thick, you
would waste about half as much work before discovering what the
customer really wants.  In your example, perhaps just do the grid with
text and links in order to get something to the customer as quickly as
possible for feedback.  Then harness the feedback the next iteration
to do what the customer has discovered that they really want.

Steven Gordon

On Mon, Jun 2, 2008 at 4:33 AM, Pat Maddox <pergesu@...> wrote:
> How much planning is too much/too little? I understand that there are
> a lot of variables that go into answering this. I'll give details of
> my team's particular situation and hopefully spur good discussion.
>
> We're experiencing problems that I believe are due to our planning
> process. At the beginning of the iteration we sit down with my boss
> (who plays the customer role) to come up with new stories and to
> review the prioritization of existing stories.
>
> The key problem we have is that we get a lot of stories rejected. I'd
> say about a third of the stories we do get rejected and need
> additional work. I believe that it's because we don't develop a deep
> enough shared understanding with the customer's needs. We're finding
> it pretty difficult to do though. A very common convo/situation goes
> like the following:
>
> Customer: "I want to show a list of locations where events were
> previously scheduled."
> Dev: "Okay. Maybe a grid with the location name and address?"
> C: "Yeah, that sounds good. And let's embed the Google Map view also"
> D: "Great. Let's do a quick sketch to see what it might look like."
> C: "I don't really care what it looks like. Anything will be fine"
> *we go to work, mark the story delivered. at the end of the
> iteration, customer rejects it saying it doesn't look right*
>
> This is really frustrating from a developer standpoint. One issue is
> that it just doesn't feel good to have our work constantly rejected.
> How much that counts or should count, I don't know. More importantly,
> it screws with our planning. If we've completed a story, but then
> have to allocate time in the next iteration to fix problems with it,
> then we push back things that were planned for that iteration. I
> think that's okay in small amounts, but it makes our planning less
> useful because we can't accurately estimate what we'll be able to get
> to.
>
> The first obvious thing to do is to explain to the customer the
> problems this causes. We've said in the past that we'd like to do
> some deeper planning because we don't like having the stories
> rejected. The customer said it wasn't a really big deal to him that
> we'd deliver a story and that he'd reject it, with specific items to
> find. I've pointed out that it hurts our productivity because it
> requires us to switch contexts a couple days after the fact. I
> haven't said that it messes up our planning, because I hadn't really
> thought of it until I wrote this message. I'm not sure what impact
> that will have, as my boss doesn't seem to find XP-style planning
> particularly valuable. He appears to feel that everything needs to
> get done, and it doesn't really matter in what order.
>
> I believe all of this is hurting the team's productivity. I'm having
> a tough time getting into the customer's head and framing my concerns
> in a way that really matters to him.
>
> Finally, I think there's a stigma against doing too much planning.
> We're doing about 3 hours of planning a week, which I don't consider
> to be very much. So I realize this would vary a great deal from
> project to project, but what is an "average" time to spend planning in
> a week?
>
> Pat