I've changed the subject line because we are now some distance
from the orginal topic.

I think Steve's view on this is very reasonable, as are Joe's
comments. The idea seems to relate to the idea of doing a service,
vs. being done a service.

So, for example, when the software people are seen as doing a service
for the business people (as is common), there do seem to be different
perspectives on the exchange. So, the business people pay money, and the
software people provide a service, which is of utility to the business.

In my "Pat and Sandy" stories, I suggested this could be done the other
way, too. If the software people have some cool technology, they might
pay some business people to help them make money from the idea. So in
this case, following Steve's suggestion, the business people might need
to get more details from the software people, and themselves provide
less. Does that make sense?

And, of course, if it was some kind of joint venture, then they would be
in balance.

The crux of the idea seems to be that someome "providing a service" is
mostly interested in the overall outcome inasmuch as it satisfies
someone else. Does that make sense?

Cheers
Robert



Steven Gordon wrote:
>
>
> Do you really believe that when I say the /level of detail/ is /more
> critical/ in one direction than the other, that I am saying that there
> should be no communication at all in the other direction?
>
> The lawyer needs more details about our situation and objectives to give
> good advice than we need about the legal precedents that his advice depends
> on in order to apply that advice. If we ask for it, he should be able to
> point us to at least a solid week's worth of reading.
>
> The doctor needs more details about our symptoms and health metrics and
> history to make a good diagnosis than we need about the medical research
> that underlies his advice in order to apply that advice. If we ask for it,
> he should be able to point us to at least a solid week's worth of reading.
> ...
>
> This does not mean that there is no communication in the other direction,
> just less detail.
>
> And this is the case between the development team and the customer. Vital
> communication in both directions, but much more detail in the communication
> from customer to development team. If the customer really wants to know
> more detail about our design decisions, we can provide it.
>
> Steve

On 7/28/07, Ilja Preuss <it@...> wrote:
> Ron Jeffries wrote:
>
>  > Absolutely. Pay needs to be perceived to be fair. Equal is not
>  > generally perceived as fair, IMO.
>
>  I suspect that this is more a result of our culture, and less of human
>  nature. We are used to measuring our own value by what we receive from
>  others. I'm not convinced that's generally the best way to think about
>  ones own value, though.

I would guess that a lot of this is cultural. In France it is
considered fair to have 8 weeks of vacation along with 12-14 holidays
and short work weeks. If you thought that in most parts of America,
you would be seen as extremely lazy. If you actually did it you would
be fired of course.

So, with the right cultural basis, any number of things could be
considered "fair"... However, you are right in that in our culture,
equal is not perceived as fair. In communist Russia, it might have
been considered so by some people. Die hard communists think that's
the only thing that's fair.

We have to work within the culture in which we find ourselves (or
relocate to a place where the culture is more compatible with our
beliefs. I suspect Ilja would be quite comfortable in Fiji... :-)

-Kelly

Hello, Ilja.  On Saturday, July 28, 2007, at 10:40:43 AM, you
wrote:

> Ron Jeffries wrote:

>> Absolutely. Pay needs to be perceived to be fair. Equal is not
>> generally perceived as fair, IMO.

> I suspect that this is more a result of our culture, and less of human
> nature. We are used to measuring our own value by what we receive from
> others. I'm not convinced that's generally the best way to think about
> ones own value, though.

You may well be right on both counts. That said, the way I'd bet is
that people have to perceive their pay to be fair.

Ron Jeffries
www.XProgramming.com
Talent determines how fast you get good, not how good you get.
   -- Richard Gabriel

Hi Ron,

> Hello, Ilja.  On Saturday, July 28, 2007, at 10:40:43 AM, you
> wrote:
>
>> Ron Jeffries wrote:
>
>>> Absolutely. Pay needs to be perceived to be fair. Equal is not
>>> generally perceived as fair, IMO.
>
>> I suspect that this is more a result of our culture, and less of human
>> nature. We are used to measuring our own value by what we receive from
>> others. I'm not convinced that's generally the best way to think about
>> ones own value, though.
>
> You may well be right on both counts. That said, the way I'd bet is
> that people have to perceive their pay to be fair.

I'm sorry, but on this I have to totally agree with you.

Regards, Ilja

Hi John,

>>> A software development team's responsibility is to produce
>>> running, tested software on time, within budget and which
>>> meets the requestor's stated functional objectives for the software.
>>>
>>> It's not a software development team's responsibility to determine
>>> if a requested piece of software is actually going to raise revenue,
>>> reduce costs, meet program goals, comply with new regulations
>>> or whatever the next level goal is. That's the project sponsor's
>>> responsibility.
>> So, say a software development team member gets the impression that just
>> perhaps, some new regulation might have been ignored until now. Do you
>> want him to do something about it?
>
> Certainly. He should discuss it with the appropriate stakeholder.
> One or the other of them is likely to learn something. It's the
> stakeholder's job to do something about it, though - that is, write
> a card and schedule the work.

Well, having a bonus program come into play, I then see two scenarios:

- you are lucky and the bonus program doesn't motivate this developer, or

- the developer concentrates on the work he gets a bonus for and doesn't
raise the issue

Of course this is based on a somewhat simplified view of the world, but
so are bonus programs. The reality will be more complex, but there is a
quite high likelihood for a bonus program to lead to dysfunctional
behavior like the above.

Cheers, Ilja

Kelly Anderson wrote:

> We have to work within the culture in which we find ourselves (or
> relocate to a place where the culture is more compatible with our
> beliefs. I suspect Ilja would be quite comfortable in Fiji... :-)

I don't know about Fiji. But I think we don't just have to accept the
culture we live in. We are part of it, and can influence it.

Cheers, Ilja

Hello, Ilja.  On Saturday, July 28, 2007, at 4:10:00 PM, you wrote:

>> You may well be right on both counts. That said, the way I'd bet is
>> that people have to perceive their pay to be fair.

> I'm sorry, but on this I have to totally agree with you.

You're forgiven.

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
   -- after Mark Vaughn, Autoweek.

That made me think how you differ business people from software people

So, for example, when the software people are seen as doing a service
> for the business people (as is common), there do seem to be different
> perspectives on the exchange. So, the business people pay money, and the
> software people provide a service, which is of utility to the business.
>
> 1st scenario:

Business People: Ones that have a problem
Software People: Ones that have (or can create) a solution


In my "Pat and Sandy" stories, I suggested this could be done the other
> way, too. If the software people have some cool technology, they might
> pay some business people to help them make money from the idea. So in
> this case, following Steve's suggestion, the business people might need
> to get more details from the software people, and themselves provide
> less. Does that make sense?
>

2nd scenario:

Business People: Ones that have resources (money, environment)
Software People: Ones that have work power (ideas, experience, free time)


Although in my environment I mostly see the 2nd scenario, mostly 1st
scenario ends better.


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

Seyit Caglar Abbasoglu wrote:
> That made me think how you differ business people from software people
>
> So, for example, when the software people are seen as doing a service
>  > for the business people (as is common), there do seem to be different
>  > perspectives on the exchange. So, the business people pay money, and the
>  > software people provide a service, which is of utility to the business.

> Business People: Ones that have a problem
> Software People: Ones that have (or can create) a solution

That seems reasonable.

> In my "Pat and Sandy" stories, I suggested this could be done the other
>  > way, too. If the software people have some cool technology, they might
>  > pay some business people to help them make money from the idea. So in
>  > this case, following Steve's suggestion, the business people might need
>  > to get more details from the software people, and themselves provide
>  > less. Does that make sense?
>  >
>
> 2nd scenario:
>
> Business People: Ones that have resources (money, environment)
> Software People: Ones that have work power (ideas, experience, free time)

Hmm, this is very different than I intended. In fact, I intended pretty
much the same points as the first case, only reversed.

In particular, it isn't that the business people have either money or
some evironment. They may have neither.

What I would expect them to produce is a way of turning a technical idea
into something that would generate a profit. So, for example, if
software people developed a kind of new graphics algorithm, I might
expect business people to figure out that it might be suitable for doing
visualizations of new homes for a real estate company, or for dentists
explaining dental implants. More generally, given the idea for the web,
they might invent online bookstores or travel agents.

Does that help?

Cheers
Robert

Hi Robert,

It's an interesting question.

  I would expect that business people would be less interested in the detail
of the technology
and processes around it and more interested in what it can do.
For example, you may not need to understand the algorithms behind Page Rank,

or massive scalability to come up with the idea for Adwords (or borrow it
from Overture).

Most interestingly, business people helping with monetising a technology,
seem less inclined to consultancy than developers,
and instead seem to either join / buy the company or buy / copy the
technology.





On 28/07/07, Robert Biddle <Robert_Biddle@...> wrote:
>
> I've changed the subject line because we are now some distance
> from the orginal topic.
>
> I think Steve's view on this is very reasonable, as are Joe's
> comments. The idea seems to relate to the idea of doing a service,
> vs. being done a service.
>
> So, for example, when the software people are seen as doing a service
> for the business people (as is common), there do seem to be different
> perspectives on the exchange. So, the business people pay money, and the
> software people provide a service, which is of utility to the business.
>
> In my "Pat and Sandy" stories, I suggested this could be done the other
> way, too. If the software people have some cool technology, they might
> pay some business people to help them make money from the idea. So in
> this case, following Steve's suggestion, the business people might need
> to get more details from the software people, and themselves provide
> less. Does that make sense?
>
> And, of course, if it was some kind of joint venture, then they would be
> in balance.
>
> The crux of the idea seems to be that someome "providing a service" is
> mostly interested in the overall outcome inasmuch as it satisfies
> someone else. Does that make sense?
>
> Cheers
> Robert
>
>
>
> Steven Gordon wrote:
> >
> >
> > Do you really believe that when I say the /level of detail/ is /more
> > critical/ in one direction than the other, that I am saying that there
> > should be no communication at all in the other direction?
> >
> > The lawyer needs more details about our situation and objectives to give
> > good advice than we need about the legal precedents that his advice
> depends
> > on in order to apply that advice. If we ask for it, he should be able to
> > point us to at least a solid week's worth of reading.
> >
> > The doctor needs more details about our symptoms and health metrics and
> > history to make a good diagnosis than we need about the medical research
> > that underlies his advice in order to apply that advice. If we ask for
> it,
> > he should be able to point us to at least a solid week's worth of
> reading.
> > ...
> >
> > This does not mean that there is no communication in the other
> direction,
> > just less detail.
> >
> > And this is the case between the development team and the customer.
> Vital
> > communication in both directions, but much more detail in the
> communication
> > from customer to development team. If the customer really wants to know
> > more detail about our design decisions, we can provide it.
> >
> > Steve
>
>
> 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.com
> Yahoo! Groups Links
>
>
>
>


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

Well, I guess there are many kinds of business people.
And some, as you say, come in late and their contribution
is mostly management or marketing.

But I do think there is a different kind, who do engage at a more
detail level, and help figure out how interesting technology could
lead to a business model.

Robert



Craig Davidson wrote:
>
>
> Hi Robert,
>
> It's an interesting question.
>
> I would expect that business people would be less interested in the detail
> of the technology
> and processes around it and more interested in what it can do.
> For example, you may not need to understand the algorithms behind Page Rank,
>
> or massive scalability to come up with the idea for Adwords (or borrow it
> from Overture).
>
> Most interestingly, business people helping with monetising a technology,
> seem less inclined to consultancy than developers,
> and instead seem to either join / buy the company or buy / copy the
> technology.

This made me think of a kind of counterexample to my original point:  There
may be business people who are responsible for installation/deployment,
training, maintenance, governance or compliance with policies or
regulations.  Such people may sometimes need to obtain greater detail from
the software development team than they are providing.

Perhaps, all general rules have exceptions.  If so, would that rule apply to
itself?  ;-}

Steve

On 7/29/07, Robert Biddle <Robert_Biddle@...> wrote:
>
>   Well, I guess there are many kinds of business people.
> And some, as you say, come in late and their contribution
> is mostly management or marketing.
>
> But I do think there is a different kind, who do engage at a more
> detail level, and help figure out how interesting technology could
> lead to a business model.
>
> Robert
>
> Craig Davidson wrote:
> >
> >
> > Hi Robert,
> >
> > It's an interesting question.
> >
> > I would expect that business people would be less interested in the
> detail
> > of the technology
> > and processes around it and more interested in what it can do.
> > For example, you may not need to understand the algorithms behind Page
> Rank,
> >
> > or massive scalability to come up with the idea for Adwords (or borrow
> it
> > from Overture).
> >
> > Most interestingly, business people helping with monetising a
> technology,
> > seem less inclined to consultancy than developers,
> > and instead seem to either join / buy the company or buy / copy the
> > technology.
>
>


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

On 7/28/07, Ilja Preuss <it@...> wrote:
> Kelly Anderson wrote:
>
>  > We have to work within the culture in which we find ourselves (or
>  > relocate to a place where the culture is more compatible with our
>  > beliefs. I suspect Ilja would be quite comfortable in Fiji... :-)
>
>  I don't know about Fiji. But I think we don't just have to accept the
>  culture we live in. We are part of it, and can influence it.

Ilja, it is my impression that you are a pretty bright fellow. With
time, I am sure that Ron and I can convert you to our cynical
curmudgeonly view of the world, but it may take a few decades. In the
mean time, brush up on your Cervantes... and keep on charging!! :-)

-Kelly

:D

Kelly Anderson wrote:
> On 7/28/07, Ilja Preuss <it@...> wrote:
>> Kelly Anderson wrote:
>>
>>  > We have to work within the culture in which we find ourselves (or
>>  > relocate to a place where the culture is more compatible with our
>>  > beliefs. I suspect Ilja would be quite comfortable in Fiji... :-)
>>
>>  I don't know about Fiji. But I think we don't just have to accept the
>>  culture we live in. We are part of it, and can influence it.
>
> Ilja, it is my impression that you are a pretty bright fellow. With
> time, I am sure that Ron and I can convert you to our cynical
> curmudgeonly view of the world, but it may take a few decades. In the
> mean time, brush up on your Cervantes... and keep on charging!! :-)
>
> -Kelly
>
>
> 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.com
> Yahoo! Groups Links
>
>
>
>

>
> Hmm, this is very different than I intended. In fact, I intended pretty
> much the same points as the first case, only reversed.
>
> In particular, it isn't that the business people have either money or
> some evironment. They may have neither.
>
> What I would expect them to produce is a way of turning a technical idea
> into something that would generate a profit. So, for example, if
> software people developed a kind of new graphics algorithm, I might
> expect business people to figure out that it might be suitable for doing
> visualizations of new homes for a real estate company, or for dentists
> explaining dental implants. More generally, given the idea for the web,
> they might invent online bookstores or travel agents.
>
> Does that help?
>
>
Yes I got it, seems like I have missed the point at first. I've seen that
scenario succeeded.

But every instance I had witnessed that, the 'invention' was a result of a
business need at first. Then some business people find other areas to use
that 'invention'. I have never seen an 'invention', which is not direct
consequence of a (explicit or implicit) business need, but succeeded in
business area. And in my dictionary, ones who defines business needs are the
business people.

Sometimes software developers might put on the business hat (define the
software), but mostly it does not succeed, if the product is not related to
a software need.


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

Hi all,

I thought that some of your may be interested in sharing your
experiences, especially from the agile perspective, on software
modeling.

My name is Andrew Forward, and I am a PhD candidate in computer
science at the University of Ottawa, Canada.  I am conducting a survey
on the attitudes towards modeling, and if you have time to help I
would appreciate if you could fill out the survey (that will take
about 20 minutes of your time).

The survey is available at:
http://cruise.site.uottawa.ca/awf2/ask/models

  If you know one or two colleagues that may also like to participate,
please share the link with them.

Thanks again, your professional opinions are greatly appreciated.

--
aforward

Friday night, I hung out with a pal who has been learning TDD. He is
naturally full of questions, and one exchange went like this:

     "If I have tested all the low-level methods, I don't need to test
     the components together, do I?"

     "Did you run it to see if it worked?"

     "Sure! I tried a few different options, and carefully looked at the
     output to be sure it was ok."

     "If you had to check it, then you weren't sure it worked. Ergo, you
     should have written a test."

     "Doh!"


I realized later that this was one of my favorite tricks for getting
people to test. And it provides an easy way forward for them, as often
all they have to do is take their scratch code, chuck it in a test, and
add a few asserts.


What other tricks do you folks have for pushing people forward with XP?

William

--- In extremeprogramming@yahoogroups.com, "Manuel Klimek"
<klimek@...> wrote:
>
> John,
>
> perhaps my question has an obvious flaw. Unfortunately I don't see
> it (yet), so I just re-post it:
> Doesn't everybody think that they do ISD or PSD? Isn't everybody
> trying to do what provides the most business value? What value
> is there in a name that describes a concept of which everybody
> thinks they're already doing it?

Maybe it depends on who you include under the heading, "everybody."
If you mean everybody who bothers to participate in a forum like
this one, on a topic related to effective delivery of business value
through software, then sure, "everybody" already thinks they do ISD
or PSD.

If you mean "everybody" as in Everybody, then I suspect the answer
is no: Most people just do whatever they're assigned to do, while
being sure to do the things on which their job performance is
measured, and then they go home and forget about work until the next
day.

Dave

>
> To pick up the spirit of a recent thread: How do you recognize
> somebody is doing ISD / PSD? Does it boil down to how to
> measure business value? To measure at all?
>
> Cheers,
> Manuel
>
> On 7/28/07, J. B. Rainsberger <jbrains762@...> wrote:
> >
> >   J. B. Rainsberger wrote:
> >
> > <snip />
> > > So let me propose an idea. I'm sure it's not new.
> >
> > <snip />
> >
> > I'm trying out another name, just to see how it looks in type.
> >
> > I wanted to let this discussion germinate for a while before
coming back
> > to it. It hasn't gone as far as I'd have liked, but I hope those
who
> > have replied will stick with it.
> >
> > To recapitulate the theme: is there anything valuable about
agile or XP
> > that we wouldn't do in PSD?
> >
> > Thanks.
> > --
> > 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 contribution Agile Software Practice
> >
> >
>
>
>
> --
> http://klimek.box4.net
>
>
> [Non-text portions of this message have been removed]
>

Manuel Klimek wrote:

> John,

I assume you mean me. I'm "Joe" or "J. B.", not John. :)

> perhaps my question has an obvious flaw. Unfortunately I don't see
> it (yet), so I just re-post it:
> Doesn't everybody think that they do ISD or PSD? Isn't everybody
> trying to do what provides the most business value? What value
> is there in a name that describes a concept of which everybody
> thinks they're already doing it?

You've just hit it: if you think you already do PSD, but what we
describe is different from what you do, and if you have an open mind,
you'll take the opportunity to rethink just how purposeful your work is.
I think that's good.

> To pick up the spirit of a recent thread: How do you recognize
> somebody is doing ISD / PSD? Does it boil down to how to
> measure business value? To measure at all?

No. I think I described it minimally. You need to be able to explain the
Good Business Reason why you do everything. I think every word in that
sentence is needed and matters.

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 contribution Agile Software Practice

William Pietri wrote:

> I realized later that this was one of my favorite tricks for getting
> people to test. And it provides an easy way forward for them, as often
> all they have to do is take their scratch code, chuck it in a test, and
> add a few asserts.

I have one to help customers describe customer tests. If they seem not
to want to do it, or have trouble, then when they ask me to build the
feature, I immediately say "Done!"

They look puzzled. "You are not."

"Sure I am. Done!"

"You haven't done anything!"

"How do you know?"

The next thing out of their mouth is usually something we can easily
turn into a customer test.

Granted, this is a good trick only if you have a good personal
relationship with the personal acting as customer.

----

Also, I like Ron's way to get customers to prioritize stories. :)
--
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 contribution Agile Software Practice

J. B. Rainsberger wrote:
> Cory Foy wrote:
>
>> J. B. Rainsberger wrote:
>>  > 1. There is no good business reason to do this.
>>  > 2. X is the good business reason to do this.
>>  > 3. We aren't sure whether there is a good business reason to do this.
>>  > (Alternately: we think there's a good business reason to do this, but
>>  > can't put our finger on it.)
>>
>> It seems like this would just be a good pattern for either Planning
>> games or when a team goes to pull a card (or sign up for stories in a
>> Sprint Planning session). But it really doesn't seem to give any
>> guidance beyond that, so I'm wondering if it would be able to stand on
>> its own (and I may have missed something).
>
> OK. Propose a question you might ask on a software team, or a problem
> you might encounter, and show us how this simple 3-step process doesn't
> adequately address the problem. This is the kind of thing I'm looking for.

I can think of a couple:

   - Is pair programming appropriate for this task?
   - Doing this Test-First seems like we won't get a lot of benefit for
it. Can we skip writing the tests?
   - Do we /really/ need an onsite customer?

All of these would probably fall into the "3" category from your list.
Intentional, Purposeful, Test-Driven, Test-First - these seem (to me) to
describe the coding implementation of a team more than the other
supporting business practices that make it agile.

But, rereading your original post, I think we perhaps went down the
wrong path. If I was practicing ISD, I could do any of the above as long
as I understand the intention behind them. Therefore I can define what
works for my team outside of the bounds of XP/Scrum/Crystal/etc.

You then ask:

  > So is there anything valuable about agile or XP that we wouldn't do
in ISD?

And I would answer, "No, if we know about it". In other words, a team
that knows all of the practices of XP or Scrum or Crystal could then use
those to find the process that fits best for their team. And there is a
lot of value in that - I'm sure you would agree that it is the best
interest of teams to pay attention to what works and what doesn't.

But to a team that /isn't/ agile - might they be able to use this as
justification to continue how they are working? I think the value in XP
and the other practices is that it sets up a framework to stretch what a
team thinks is possible in their day-to-day practices.

I guess I could see ISD/PSD being the abstract class (in OO terms) of
other agile practices - in other words, use it to make sure the other
practices fit into your hierarchy. But people still need concrete
implementations and guidance of ways they can become more agile.

My question back would be - how do the XP/Scrum/Crystal practices today
/not/ implement ISD, and how could we reword them or otherwise modify
them so that they fit within your model?

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

Seyit Caglar Abbasoglu wrote:

> But every instance I had witnessed that, the 'invention' was a result of a
> business need at first. Then some business people find other areas to use
> that 'invention'. I have never seen an 'invention', which is not direct
> consequence of a (explicit or implicit) business need, but succeeded in
> business area. And in my dictionary, ones who defines business needs are the
> business people.

I would agree this is a typical way of thinking about things. But I
don't think it  reflects the way things really happen. The idea of
"needs" is too general, for example. What is a need? Is it different to
a want, or a desire, a dream? Did we need cars? Do we need iPods?
Will we need Karbaggles? We make it all up on the fly.

Ok, maybe that's coming on too strong. But consider this: how can you
describe what you want, except in terms of what you can imagine?

One of the reasons I am enthusiastic about agile development is
exactly because of the greater engagement between business people and
software people. And I do not see it as simply involving the software
people providing a service to the business people. I like it when the
business people are exposed and involved in the technical discussions:
it seems to me this is the kind of conversation that can lead not just
to answering a business need, but to identifying both a software and a
business opportunity.

Steve Jobs and Steve Wozniak both needed each other.

Robt

On 7/30/07, J. B. Rainsberger <jbrains762@...> wrote:
>
> Manuel Klimek wrote:
>
> > To pick up the spirit of a recent thread: How do you recognize
> > somebody is doing ISD / PSD? Does it boil down to how to
> > measure business value? To measure at all?
>
> No. I think I described it minimally. You need to be able to explain the
> Good Business Reason why you do everything. I think every word in that
> sentence is needed and matters.



I like where Manuel is taking this, because  unless an idea is banged on, it
won't toughen up...

That said, I think one can justify anything as a Good Business Reason. Why
we won't accept pairing now, why we must generate design docs for every line
of code, etc... all can be given a Good Business Reason.

So, while I like minimal definitions, is there too much leeway in this
method, or is there some error-proofing that can be done to get to the
intended result?

Chris.


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

On 7/30/07, Robert Biddle <Robert_Biddle@...> wrote:
>
>
>
> One of the reasons I am enthusiastic about agile development is
> exactly because of the greater engagement between business people and
> software people. And I do not see it as simply involving the software
> people providing a service to the business people. I like it when the
> business people are exposed and involved in the technical discussions:
> it seems to me this is the kind of conversation that can lead not just
> to answering a business need, but to identifying both a software and a
> business opportunity.



Robert, I am so glad you said this because I've experienced this. I can't
quite describe in any concise fashion what happens when both 'sides' get
together in a technical discussion, but there is a lot of 'right! I can see
how to do this cheaper' and a lot of 'yes! our customers will like this much
better'.  That's why I'm not as convinced as an earlier poster is that we
are kind of like medics or lawyers in our communication with the business
side.

Chris.


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

Chris Wheeler wrote:

>  > No. I think I described it minimally. You need to be able to explain the
>  > Good Business Reason why you do everything. I think every word in that
>  > sentence is needed and matters.
>
> I like where Manuel is taking this, because unless an idea is banged on, it
> won't toughen up...

Agreed. I wasn't trying to stop Manuel from asking questions; I just
answered the one he asked.

> That said, I think one can justify anything as a Good Business Reason. Why
> we won't accept pairing now, why we must generate design docs for every line
> of code, etc... all can be given a Good Business Reason.

You might be right. However, if you give me a GBR not to pair, and I
give you a GBR to pair, we should be able to compare those and decide
which is better for us right now.

Also, do keep in mind that having a GBR not to pair is probably better
than pairing without a purpose.

> So, while I like minimal definitions, is there too much leeway in this
> method, or is there some error-proofing that can be done to get to the
> intended result?

I'm not sure I understand your question about "error-proofing". Is it
possible to do something stupid while having GBRs to do it?

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 contribution Agile Software Practice

Joe,

(sorry for getting the name wrong)

On 7/31/07, J. B. Rainsberger <jbrains762@...> wrote:
>  You might be right. However, if you give me a GBR not to pair, and I
>  give you a GBR to pair, we should be able to compare those and decide
>  which is better for us right now.
>
>  Also, do keep in mind that having a GBR not to pair is probably better
>  than pairing without a purpose.

In a different thread people here hit me with a trout for theoretically
pondering over the business value of certain XP practices, especially
about introducing XP step-by-step or "do it by the book first".

I argued into the direction of your proposal why I am trying to do it
incrementally.

What I learned from the thread is that it's (probably) impossible
to tell the business value of something without some kind of measure.

How do you quantify the business value of pairing?

>  > So, while I like minimal definitions, is there too much leeway in this
>  > method, or is there some error-proofing that can be done to get to the
>  > intended result?
>
>  I'm not sure I understand your question about "error-proofing". Is it
>  possible to do something stupid while having GBRs to do it?

Yes. If the GBRs are not quantified correctly. For example, I see not
pairing gives GBR, since I am twice as productive. How can you dare
to say I am wrong? :-) Not TDDing gives GBR because I write half the
code, I am twice as productive again.

So the GBR for not doing XP is that I'm at least four times as productive.
But I am not. How do I know this? Because I tested it, measured it
and saw that it worked.

So I think you'll have to specify GBR more precisely, and not
as "what one perceives as possible GBR with the experience at hand".

Cheers,
Manuel

--
http://klimek.box4.net

Hello, Chris.  On Monday, July 30, 2007, at 10:17:10 PM, you wrote:

> Robert, I am so glad you said this because I've experienced this. I can't
> quite describe in any concise fashion what happens when both 'sides' get
> together in a technical discussion, but there is a lot of 'right! I can see
> how to do this cheaper' and a lot of 'yes! our customers will like this much
> better'.  That's why I'm not as convinced as an earlier poster is that we
> are kind of like medics or lawyers in our communication with the business
> side.

Agreed. Teams and individuals who try to communicate, and who find
themselves in a conducive environment, can generally collaborate
quite effectively. It's not like we are /all/ autistic. Just a lucky
few.

Ron Jeffries
www.XProgramming.com
You don't want to sell me waterfall.
You want to go home and rethink your life.

Hi all,

A San Antonio agile group (affiliated with Agile Alliance and APLN)
is starting.  We are having an organizational meeting Wed night at 7pm.

Contact me if you can join us.  Then or later.

Regards, Joe

Dave

I think your "everybody" includes only mentally healthy people, not the sickos
who can't stop working just because the clock ticks over one too many times.
;-)

---
A scientist in Russia completely cured OCD in the 80s, and says that he'll
publish his method when he gets around to it. ;)

----- Original Message ----
From: Dave Nicolette <dnicolet@...>
To: extremeprogramming@yahoogroups.com
Sent: Monday, July 30, 2007 4:28:24 PM
Subject: Purposeful Software Development (Re: [XP] Intentional Software
Development)

--- In extremeprogramming@yahoogroups.com, "Manuel Klimek"
<klimek@...> wrote:
>
> John,
>
> perhaps my question has an obvious flaw. Unfortunately I don't see
> it (yet), so I just re-post it:
> Doesn't everybody think that they do ISD or PSD? Isn't everybody
> trying to do what provides the most business value? What value
> is there in a name that describes a concept of which everybody
> thinks they're already doing it?

Maybe it depends on who you include under the heading, "everybody."
If you mean everybody who bothers to participate in a forum like
this one, on a topic related to effective delivery of business value
through software, then sure, "everybody" already thinks they do ISD
or PSD.

If you mean "everybody" as in Everybody, then I suspect the answer
is no: Most people just do whatever they're assigned to do, while
being sure to do the things on which their job performance is
measured, and then they go home and forget about work until the next
day.

Dave

>
> To pick up the spirit of a recent thread: How do you recognize
> somebody is doing ISD / PSD? Does it boil down to how to
> measure business value? To measure at all?
>
> Cheers,
> Manuel
>
> On 7/28/07, J. B. Rainsberger <jbrains762@...> wrote:
> >
> >   J. B. Rainsberger wrote:
> >
> > <snip />
> > > So let me propose an idea. I'm sure it's not new.
> >
> > <snip />
> >
> > I'm trying out another name, just to see how it looks in type.
> >
> > I wanted to let this discussion germinate for a while before
coming back
> > to it. It hasn't gone as far as I'd have liked, but I hope those
who
> > have replied will stick with it.
> >
> > To recapitulate the theme: is there anything valuable about
agile or XP
> > that we wouldn't do in PSD?
> >
> > Thanks.
> > --
> > 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 contribution Agile Software Practice
> >
> >
>
>
>
> --
> http://klimek.box4.net
>
>
> [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.com
Yahoo! Groups Links











________________________________________________________________________________\
____
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

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

FYI:

  The next Agile Philly meeting will be presented by Comcast.  The meeting
starts at 6:30PM on *Tuesday, August 7th* and directions and location of the
event is still being determined. When I know more details on this, I will
let you know.

The meeting is open to all. If you want to attend, *please RSVP via email*to
AgilePhillyCoordinators@yahoogroups.com. Please include your name and
organization.

More details:

http://wiki.agilephilly.com/index.php?title=Agile_Adoption

If you have any questions or comments regarding the meeting, location, or
anything else, either email AgilePhillyCoordinators@yahoogroups.com or
feel free to call toll free 1-888-AGILEPHILLY (1-888-244-5374).

Summary of the topic:

Agile Adoption at Comcast Interactive Media — The Top 10 Things We Did Wrong
(and lived to tell about)

Comcast Interactive Media (CIM) is a new division of Comcast focused on the
digital distribution of media and rich-media websites.  Our video-centric
properties include the comcast.net ( www.comcast.net) portal for Comcast
high-speed data subscribers, the Ziddio user-generated video site
(www.ziddio.com
) and the Game Invasion gaming site (www.gameinvasion.net).  While
developing these and other soon to be released web sites, we have spent the
last year moving our software development teams to an agile methodology.
  While the transition is nowhere near complete, we'll discuss the good, the
bad, and (of course) the ugly of that transition.  At CIM, we've adopted a
new motto when it comes to agile -- "you can do just about anything for 30
days" -- and we have put it to good use experimenting with all sorts of
permutations on traditional agile principles and most importantly having the
courage to change those things that aren't working at the end of an
iteration.  We don't pretend to have all the answers (we don't) but we are
hoping to host an interactive session and share our lessons learned and
perhaps learn a few new lessons ourselves.


--
.Chris.

Christopher K. Joiner, Jr.
Senior Agile Software Developer
XP Coach
PrimeTel Communications, Inc.


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