Home > Archive > Extreme Programming > June 2004 > Requirements Misalignment
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Requirements Misalignment
|
|
| Scott Kinney 2004-04-24, 2:34 pm |
| Deep within the 'Irony' thread was a
question as to what 'software development
process' specifically dealt with the
instance 'where management requirements
and customer requirements aren't aligned.'
The quick answer was 'any methodology
that gets requirements sign-off', which
generated a spate of 'well, what if....'
objections.
It's not sign-off per se that addresses
requirements misalignment, but the activity
preceeding sign-off, requirements analysis.
The project manager (and team) review the
requirements for certain attributes. If they
find requirements out of alignment with one another,
then they are re-negotiated, re-worked until
alignment is achieved. There won't be sign-off
until the requirements are clean, and there
certainly won't be a project if they remain
out of alignment.
There was a "What if management changes mid-stream?"
objection.
Well, in a classically managed project; you'd
have documented business goals, measures, estimated
costs and a written strategy (and requirements)
to achieve the goals. In short, enough written
description for the new management to decide
whether they agree or disagree with the project.
It's their prerogative to maintain, cancel or
alter the project.
Another objection was "what if the requirements
are what the customer asked for, but not what
the customer wants?"
Frankly, if you have not captured what the customer
wants, in business terms, then you've done a terrible
job of gathering and/or documenting the requirements.
The practioner fell down, not the methodology.
There are lots of tools and techniques for gathering
and understanding requirements. Learn them, get good
at them, and use them.
FWIW, I agree with the person who suggested that the
root business requirements really change very little.
That matches my experience as well.
Finally, the sentiment "...customers seldom know
what they really want..." is probably the most
disrespectful and condescending notion I've heard
come out of a discipline that holds "Open and Honest
Communication" as a core value.
The customer always knows exactly what they want
from a business perspective. If you can't figure it out,
your requirements gathering skills need work.
Scott Kinney
Project Manager
Amateur Barbarian
| |
| Jason Nocks 2004-04-25, 12:30 am |
| Scott Kinney wrote:
> Deep within the 'Irony' thread was a
> question as to what 'software development
> process' specifically dealt with the
> instance 'where management requirements
> and customer requirements aren't aligned.'
Yes, I believe that I asked this question.
> The quick answer was 'any methodology
> that gets requirements sign-off', which
> generated a spate of 'well, what if....'
> objections.
Yes, and all of these objections were relevant to the context of the
project that was being referred to as an example.
> It's not sign-off per se that addresses
> requirements misalignment, but the activity
> preceeding sign-off, requirements analysis.
If you wish to perform "requirements analysis", that's fine, but IMHO it
does not address all of the "what if"s that were mentioned, particularly
when a manager is lying to higher levels of management (who do not have
the time to be involved in "requirements analysis").
> The project manager (and team) review the
> requirements for certain attributes. If they
> find requirements out of alignment with one another,
> then they are re-negotiated, re-worked until
> alignment is achieved. There won't be sign-off
> until the requirements are clean, and there
> certainly won't be a project if they remain
> out of alignment.
You are still not considering the fact that this "misalignment" may be
occurring higher up within the organization. The CEO of a company, or
the Senior Vice President, or Vice President, or ..., for example, are
not expected to attend every meeting during "requirements analysis".
> There was a "What if management changes mid-stream?"
> objection.
>
> Well, in a classically managed project; you'd
> have documented business goals, measures, estimated
> costs and a written strategy (and requirements)
> to achieve the goals. In short, enough written
> description for the new management to decide
> whether they agree or disagree with the project.
> It's their prerogative to maintain, cancel or
> alter the project.
Yes, and they chose to cancel. Where's the beef?
> Another objection was "what if the requirements
> are what the customer asked for, but not what
> the customer wants?"
>
> Frankly, if you have not captured what the customer
> wants, in business terms, then you've done a terrible
> job of gathering and/or documenting the requirements.
Rudeness objection.
I prefer working with humans rather than robots, and sometimes humans
make mistakes, even customers (and even me). I prefer to work with the
customer and try to correct mistakes as early as possible, whether they
are the customer's or mine (which of course is a very rare event :), or
even someone else's on the team.
The customer team contains the domain experts. If they are wrong about
what *they think* that they want, I prefer to try to adopt myself to
this change in understanding on *their* part. IMHO, this is not even a
mistake, but actually an expected event, see below.
> The practioner fell down, not the methodology.
Not at all. If the customer team indicates that what was delivered is
exactly what the customer team asked for, then what was delivered is
what the customer team *thought* they wanted at the start of the
project. They are indicating that the development team did the correct
job that they were asked to do. The developers came through, why would
you indicate otherwise?
The customer team is indicating that their understanding was off to some
degree earlier in the project. This happens all the time. IMHO, this is
human nature. It's almost along the lines of "the grass is greener" or
"appearances can be deceiving". Often things seem to be more attractive
for some purpose than they really are until we get to experience them
for ourselves.
You are completely overlooking the possibility that the customer team
might actually learn something during the course of a project, as they
gain experience with what is being created. The fact that a software
development project needs to be undertaken highly suggests that
something exactly like it does not already exist, so the customer team
is going to be lacking some relevant experience to at least some degree.
This is despite the fact that they are the real domain experts.
So, almost every software development project has a uniqueness aspect to
it. When a project is somewhat unique, the customer has to try to
anticipate what is going to be delivered. Customers are often not nearly
as skilled at anticipating what the result of Use Case analysis will be.
Furthermore, they may construct a model in their own mind that seems to
be what they want. Until they actually have a chance to work with the
resulting product, there is a high likelihood that the result will not
be *exactly* what the customer wants or needs.
> There are lots of tools and techniques for gathering
> and understanding requirements. Learn them, get good
> at them, and use them.
We're not talking about gathering requirements. I can gather
requirements for months (been there done that) and do "requirements
analysis" just fine. I just no longer *prefer* to do "requirements
analysis" as a required lengthy step at the beginning of every project.
We're talking about the customer not being able to anticipate how useful
what they *think* they want is actually going to be until they actually
work with it. The greater the complexity of the system, and the more
unique the project, the higher the likelihood that there will be some
disparity between what they think they want at the beginning of the
project and what they will realize that they really want or need at the
end of the project. The only way to completely address this issue is to
embrace the fact that the customer team will want to make changes
throughout the course of the project.
That is probably one of the reasons why Change Orders are introduced in
plan-driven approaches.
> FWIW, I agree with the person who suggested that the
> root business requirements really change very little.
> That matches my experience as well.
So, what would be the reason for Change Orders then? You indicate that
the business requirements change very little and that you expect to have
captured 100% of what the customer wants. Why would an organization ever
need to go through a Change Order? In my experience, the more complex
the project, the more likely Change Orders will occur in a plan-driven
approach.
Further, I think that you misunderstood the point. I think the point was
that the likelihood of the customer learning during a project is nearly
guaranteed due to human nature. The same may not be true of changes due
to the actual business changing.
There are businesses that have been around long enough that a core need
they are looking to fill may not be changing much anymore. It is likely
still changing but perhaps slowly enough that it might not impact the
delivered vs wanted or needed issue much on a particular project.
> Finally, the sentiment "...customers seldom know
> what they really want..." is probably the most
> disrespectful and condescending notion I've heard
> come out of a discipline that holds "Open and Honest
> Communication" as a core value.
IMHO, it's more honest and less condescending than requiring people to
be infallible.
> The customer always knows exactly what they want
IMHO, this view is very simplistic. This requires that customers be
beyond human fallibility. Particularly with increasing complexity. Most
non-technical people (business domain experts) cannot look at a complex
design, with complex Use Cases and confidently say that the result will
address what they actually need with 100% certainty. They may sign off,
indicating that it *seems* like what they want, and that it is
definitely in alignment with what they are asking for. But, at the end
of the project, they will most likely have learned something, and would
prefer that some changes be made.
I have seen 2 distinct approaches to dealing with this disparity between
"what the customer asks for" and "what the customer really wants":
1) Some believe that /the customers are all idiots/.
2) Some believe that the customer doesn't "always knows exactly what
they want" at the start of a project.
I prefer the second option, although I had trouble preserving the quote
and working out all of the grammar.
> from a business perspective. If you can't figure it out,
> your requirements gathering skills need work.
Rudeness objection.
I have worked with teams that have successfully delivered projects with
plan driven approaches with extensive upfront requirements gathering.
I've done this at many levels, including as Project Manager and as head
of a line of software at a company. These projects were considered
successful by both the development team, the customer team, and
management. Unfortunately, while some projects made it through rollout,
more than one or two were shelved at the completion of development and
testing. More than once, the stated reasons were that the business had
changed too much or that the customer team had misjudged some of the
requirements, when this feedback was even collected at all. I no longer
prefer this approach because I have personally seen the benefits of
"embrace change".
I prefer to work on what the customer team *know that they need* rather
than what everyone thinks *might be needed*. I prefer to work on things
in the priority that the customer team wants these things done. And,
lastly, I prefer to gather feedback from the customer to make sure that
what is being delivered is actually what the customer team wants and
needs, not what they thought they wanted when they agreed to the
requirements at the start of a project.
I prefer to focus on the fact that "Software development is people". If
we were talking about hardware, then maybe robots would be desirable.
Software development, however, is supposed to be able to adapt to changes.
If you don't want to work this way, that's completely 100% OK with me.
I'm not asking you to change how you do things. But, I will defend what
works for me, and what I think has worked for others.
> Scott Kinney
> Project Manager
> Amateur Barbarian
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Scott Kinney 2004-04-25, 12:37 pm |
|
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:108m7b8t2icbpab@news.supernews.com...
>
> Exactly. One of the things I find isn't emphasized
> by the XP literature out there is that the standard
> requirements analysis is split into two distinct
> activities. The first activity does "just enough"
> analysis to pull the project together, create
> the story cards, get them estimated and lay
> out a tentative release plan.
>
> The second activity takes each story card
> and fleshes it out into the Automated Acceptance
> Tests. This activity is either the first activity in
> implementing the story, or takes place on the
> iteration prior to the planned implementation.
>
>
> I think the process is somewhat different, but
> the goal is the same. If different stakeholders'
> requirements are not in alignment, you can't
> get "the customer speaks with one voice."
>
The part that seems to be missing from XP is the
review of 'the forest' in addition to the review of 'the trees'.
Mis-alignment is as often the result of conflicts between
requirements as it is flawed requirements themselves.
>
>
>
> Agreed. Unfortunately, this happens a lot.
>
>
> Many of those tools and techniques come out
> of the "we have to have all the requirements nailed
> down up front because changing any detail is going
> to be horribly expensive" school of thought.
Two quibbles:
1. Are you suggesting that you won't use effective tools
because you don't like a methodology that uses them?
2. Changing requirements, or even design details, is cheaper
on paper than it is in code, and production code at that.
That's part of the value of doing those things up front.
>
> Well, here I'm going to both agree and disagree with
> you. The customer does know what they want from
> a business perspective, but that doesn't mean they
> know exactly what they want the system to do in
> the detail needed to implement it.
Requirements are 'what' and design is 'how'. Again,
in classical project management, design gets worked, reviewed
and agreed to when it's cheap and on paper.
Changes will certainly occur, and the project structure has to
have a mechanism that reflects the effect that changes will have on
the project as a whole, and then, for accepting or rejecting them.
| |
| Scott Kinney 2004-04-25, 12:37 pm |
|
"Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
misalignment, but the activity
>
> If you wish to perform "requirements analysis", that's fine, but IMHO it
> does not address all of the "what if"s that were mentioned, particularly
> when a manager is lying to higher levels of management (who do not have
> the time to be involved in "requirements analysis").
>
Let's leave the word 'lying' aside for the moment.
Managing communications, and playing politics are part of the job
of the project manager. The PM has to have or cultivate a
senior management champion (usually it's the project sponsor, but
it's better to have more than one champion. A gang of senior/executive
VPs is always nice to have on your side.) The PM has to provide
the message and the ammunition. If for some reason the only
voice being heard is your critic's, then you've not plotted, planned,
communicated or prepped your senior representative appropriately.
Now, on to lying. Maybe they're lying, maybe they just didn't understand
the information your team provided and interpreted it badly. They're both
addressable, but can be messy.
[editorial break] If you're managing a project that has any real impact or
benefit, you'll have critics and enemies. It's a given. Plan for it. [end
editorial break]
>
> You are still not considering the fact that this "misalignment" may be
> occurring higher up within the organization. The CEO of a company, or
> the Senior Vice President, or Vice President, or ..., for example, are
> not expected to attend every meeting during "requirements analysis".
>
See previous response. It's the project manager's job to manage those
communications and get that message out correctly at that level.
>
> Rudeness objection.
Obliquity objection. What are you talking about?
> That is probably one of the reasons why Change Orders are introduced in
> plan-driven approaches.
>
For the reasons you gave (and I snipped for bandwidth) I'd think Change
Orders
occur in every approach.
>
> So, what would be the reason for Change Orders then? You indicate that
> the business requirements change very little and that you expect to have
> captured 100% of what the customer wants. Why would an organization ever
> need to go through a Change Order? In my experience, the more complex
> the project, the more likely Change Orders will occur in a plan-driven
> approach.
>
In a previous response, I draw a distinction between business requirements
("what" statements) changing much less frequently than design ("how"
statements).
>
>
> IMHO, it's more honest and less condescending than requiring people to
> be infallible.
I'm not requiring infallibility, just reasonable degrees of skill and
professionalism.
>
>
> IMHO, this view is very simplistic. This requires that customers be
> beyond human fallibility. Particularly with increasing complexity. Most
> non-technical people (business domain experts) cannot look at a complex
> design, with complex Use Cases and confidently say that the result will
> address what they actually need with 100% certainty. They may sign off,
> indicating that it *seems* like what they want, and that it is
> definitely in alignment with what they are asking for. But, at the end
> of the project, they will most likely have learned something, and would
> prefer that some changes be made.
>
> I have seen 2 distinct approaches to dealing with this disparity between
> "what the customer asks for" and "what the customer really wants":
> 1) Some believe that /the customers are all idiots/.
> 2) Some believe that the customer doesn't "always knows exactly what
> they want" at the start of a project.
>
> I prefer the second option, although I had trouble preserving the quote
> and working out all of the grammar.
>
>
> Rudeness objection.
Objection overruled.
| |
| John Roth 2004-04-25, 5:33 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:AuednQDOL8DIRRbd4p2dnA@comcast.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:108m7b8t2icbpab@news.supernews.com...
>
> The part that seems to be missing from XP is the
> review of 'the forest' in addition to the review of 'the trees'.
> Mis-alignment is as often the result of conflicts between
> requirements as it is flawed requirements themselves.
You're usually not going to get to the level of detail
that will reveal inconsistencies with XP.
>
>
> Two quibbles:
> 1. Are you suggesting that you won't use effective tools
> because you don't like a methodology that uses them?
There is a difference between "effective" and "cost
effective." Many of the tools that come out of the
plan driven environment are effective, but they are
not cost effective in an agile environment.
> 2. Changing requirements, or even design details, is cheaper
> on paper than it is in code, and production code at that.
> That's part of the value of doing those things up front.
Now that's where we're going to disagree. Strongly.
The basic fact is that the longer the time between
the original research and the implementation, the
more likely it is that changes will obsolete the original work.
The devil is in the details, and it's the details that
don't get right unless they're tested in the real world
by real people using the real implementation. The more
work that's put into getting the details right, the more
cost that is at risk of being obsoleted by the mere
passage of time and events over which the requriements
team has no knowledge.
>
> Requirements are 'what' and design is 'how'. Again,
> in classical project management, design gets worked, reviewed
> and agreed to when it's cheap and on paper.
And in XP, design is proved by being reduced to code
immediately. The time lag between design and code is
minimal.
The point of disagreement is expense. Classical development
is expensive because it is very wasteful. XP is significantly
cheaper because it eliminates most of the sources of waste.
> Changes will certainly occur, and the project structure has to
> have a mechanism that reflects the effect that changes will have on
> the project as a whole, and then, for accepting or rejecting them.
Of course.
John Roth
>
>
>
| |
| Ronald E Jeffries 2004-04-25, 6:42 pm |
| On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>The part that seems to be missing from XP is the
>review of 'the forest' in addition to the review of 'the trees'.
>Mis-alignment is as often the result of conflicts between
>requirements as it is flawed requirements themselves.
How does the XP "Release Plan" practice affect this concern, in your
mind?
>Two quibbles:
>1. Are you suggesting that you won't use effective tools
>because you don't like a methodology that uses them?
I would think that the OP was saying that since they do not use a
methodology that requires the tools, they are of less value in such a
case.
>
>2. Changing requirements, or even design details, is cheaper
>on paper than it is in code, and production code at that.
>That's part of the value of doing those things up front.
Yes. But part of the cost is that the importance and the understanding
of the requirements is at least partly conditioned by things that can
only be learned from the implementation.
Similarly, changing design details without feedback from the code is
quite error-prone beyond a certain high level. We can't select
features without understanding their individual cost, and quite often,
we aren't even sure what we want until we see it coming into being.
Another part of the cost is that waiting longer to ship value reduces
return on investment.
The result of these observations -- I would call them "truths" -- is
that one needs always to find a balance between enough analysis and
design to keep the cost of change low, and enough development to get
the ROI high and to learn the things that can best be learned through
the implementation.
Agile methods in general, and XP in particular, observe that with
today's tools and practices, the balance favors moving to
implementation much sooner than folks normally anticipate it before
experimenting with the power of simple design supported by tests, and
refactoring.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-04-25, 8:33 pm |
| Xref: kermit comp.software.extreme-programming:29209
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@
4ax.com...
> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> How does the XP "Release Plan" practice affect this concern, in your
> mind?
>
Not at all. It seems much more concerned with scheduling the
work on individual stories. I don't see anything that reviews all
the stories as making sense together. Nothing that I've seen
would prevent you from simply scheduling conflicting work.
>
> I would think that the OP was saying that since they do not use a
> methodology that requires the tools, they are of less value in such a
> case.
So interviews, use cases, prototypes, storyboarding, brainstorming
sessions, review of existing documents, and so on, are of little value
in XP?
[color=darkred]
>
> Yes. But part of the cost is that the importance and the understanding
> of the requirements is at least partly conditioned by things that can
> only be learned from the implementation.
But those are a sub-set, and I suspect, not a majority. In XP, when
a customer declares after delivery, "It's not what I wanted", what happens?
Does it create a new story, that will be re-prioritized with all the
existing stories, do you simply work on it until it *is* what they wanted?
>
> Similarly, changing design details without feedback from the code is
> quite error-prone beyond a certain high level.
>We can't select features without understanding their individual cost, and
quite often,
> we aren't even sure what we want until we see it coming into being.
>
> Another part of the cost is that waiting longer to ship value reduces
> return on investment.
>
Not convinced, and what kind of time horizon are you ascribing to
plan-driven development anyway?
Also, where user training are required, or integration with a larger
application set is required, the products of development *can't* go
into production any sooner than they can for plan driven deliverables,
so there's no incremental benefit.
> The result of these observations -- I would call them "truths" -- is
> that one needs always to find a balance between enough analysis and
> design to keep the cost of change low, and enough development to get
> the ROI high and to learn the things that can best be learned through
> the implementation.
>
> Agile methods in general, and XP in particular, observe that with
> today's tools and practices, the balance favors moving to
> implementation much sooner than folks normally anticipate it before
> experimenting with the power of simple design supported by tests, and
> refactoring.
>
> Regards,
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Paul Sinnett 2004-04-25, 8:33 pm |
| >> Scott Kinney wrote:
[color=darkred]
> Jason Nocks wrote:
Scott Kinney wrote:[color=darkred]
> Obliquity objection. What are you talking about?
I think it's a reference to:
http://c2.com/cgi/wiki?RudenessObjection
Ironically, the use here more closely resembles the description than
whatever slight it was supposed to highlight:
"the kind of rudeness that uses one's superior knowledge of Wiki
concepts and content to imply that a newcomer is barely literate or
intelligent."
But perhaps not as close as me pointing this out :-).
As for what is so objectionable about what you wrote: your guess is as
good as mine.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@
4ax.com...
>
>Not at all. It seems much more concerned with scheduling the
>work on individual stories. I don't see anything that reviews all
>the stories as making sense together. Nothing that I've seen
>would prevent you from simply scheduling conflicting work.
Nothing except people coming together to consider all the stories and
their estimates.
If two stories actually conflict, then the estimate for one would be
infinite given the other. But no matter.
What happens is that all the people are sitting around the table
talking about all the stories at once. Unless they are all really
dull, they wind up considering how it all makes sense.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>So interviews, use cases, prototypes, storyboarding, brainstorming
>sessions, review of existing documents, and so on, are of little value
>in XP?
Did I say that? I don't recall doing so. However:
First of all, I would expect that an XP team would use any practices
that they knew if they thought they would be useful. XP isn't "do only
these things", it is "do these things".
Given that ...
Formal interviews are probably of lower value when we have someone who
understands the needs with us all the time;
Use cases might be of lower value when we have someone who understands
the needs with us all the time, and when we have one or more automated
acceptance tests for every requirement;
Prototypes are of lower value to the extent that we have the ability
to build real, running software cost effectively.
I've seen storyboarding used on many XP projects, at least if the term
means what I think it means. What do you mean by the term?
Brainstorming sessions are common on XP projects, as they would be in
most any sensible team situation.
Naturally if there were existing documents a team would review them.
I would think it clear that doing things in different ways changes the
value of other things that one might do. Does that not seem true to
you as well?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
|
|
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Sat, 24 Apr 2004 13:05:48 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Finally, the sentiment "...customers seldom know
>what they really want..." is probably the most
>disrespectful and condescending notion I've heard
>come out of a discipline that holds "Open and Honest
>Communication" as a core value.
On the contrary. The customers are being asked to imagine a thing
which does not exist -- a software program. They are being asked to
describe it in quite some detail, and they lack, at the beginning of
this effort, any knowledge of the cost of the individual features.
"Would you like to have a Ferrari?" "Yes!"
"They cost $250,000." "Oh. Never mind."
There's no disrespect or condesension in the observation that
customers seldom know what they really want, merely observation.
That's why we prefer to work closely with them, to give them cost
estimates on all the features they imagine, and to show them the
software as it grows.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ilja Preuß 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> Now, on to lying. Maybe they're lying, maybe they just didn't
> understand the information your team provided and interpreted it
> badly. They're both addressable, but can be messy.
If I remember correctly, Ron reported the responsible manager stating
something along the lines of "I can't possibly say them *that*."
> See previous response. It's the project manager's job to manage those
> communications and get that message out correctly at that level.
Yes. And if the manager refuses to do it, no process, wether including
"sign-off" or not, will help, so it seems to me.
Take care, Ilja
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:tuuo80hnqsor9vkh0452b4c98si93ak5f4@
4ax.com...
> On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Formal interviews are probably of lower value when we have someone who
> understands the needs with us all the time;
>
> ......snippage........
> I would think it clear that doing things in different ways changes the
> value of other things that one might do. Does that not seem true to
> you as well?
'Interviewing', to me, is a collection of skills to elicit information;
skills like asking open-ended questions (even knowing which sorts
of attributes to 'unravel'), testing understanding, being able to recreate
key arguments and concerns,building rapport,
mirroring, and many others. I may do this in words, I may use pictures,
I may mimic processes on 3x5 cards, and so on.
What I hear and read in XP literature, if I may paraphrase, is;
"We don't need that level of skill/practice because we have the
people in the room."
Have I misinterpreted, are there other expectations of the XP
practitioner (specific skills and attitudes) that are assumed, or left
undescribed?
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@
4ax.com...
> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> Yes. But part of the cost is that the importance and the understanding
> of the requirements is at least partly conditioned by things that can
> only be learned from the implementation.
>
> Similarly, changing design details without feedback from the code is
> quite error-prone beyond a certain high level. We can't select
> features without understanding their individual cost, and quite often,
> we aren't even sure what we want until we see it coming into being.
>
> Another part of the cost is that waiting longer to ship value reduces
> return on investment.
>
I meant to ask this earlier; when you use the term 'return on investment'
do you mean it literally (an actual model of costs, returns, value over time
return on separate features of the project, etc.) or more figuratively?
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Ilja Preuß" <preuss@disy.net> wrote in message
news:c6itsr$vk8$1@stu1id2.ip.tesion.net...
> Scott Kinney wrote:
>
>
> If I remember correctly, Ron reported the responsible manager stating
> something along the lines of "I can't possibly say them *that*."
>
>
> Yes. And if the manager refuses to do it, no process, wether including
> "sign-off" or not, will help, so it seems to me.
Agreed, it's more a matter of the skills, practices, even the aggressiveness
of the project manager, than it is one of process or methodology.
I don't know if there were other lines of communications to senior
management, a back door. I don't know why it wasn't appropriate to
work with the manager to find another way to deliver the critical message.
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Paul Sinnett" <paul.sinnett@btinternet.com> wrote in message
news:408c9592$1@news.totallyobjects.com...
> Scott Kinney wrote:
>
> The idea that people seldom know what they really want has been verified
> by experiment.
>
> ...snippage about 'proving that customers don't know what they want'
> And that seems to match the sentiment: "customers seldom know what they
> really want" quite well. However, this view is not a product of XP. Most
> requirements gathering techniques go to great lengths to address this
issue.
If we are thinking of the same requirements gathering techniques, they do
not
come from a base of 'the customer doesn't know what they want', they come
from
a base of 'the project team doesn't know what the customer wants.'
My objection to the attitude is:
1. I don't believe that it's true. The customer knows their business, they
know
it way better than I do, and they know their business needs better than I do
(at least at the beginning.)
2. The attitude has no payoff in the requirements gathering process, it
gives
me no advantage, and it poisons my ability to build rapport with them.
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:cbpp80503la7h4dcdvkp1keoqcq98qb7jk@
4ax.com...
> On Sat, 24 Apr 2004 13:05:48 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> On the contrary. The customers are being asked to imagine a thing
> which does not exist -- a software program. They are being asked to
> describe it in quite some detail, and they lack, at the beginning of
> this effort, any knowledge of the cost of the individual features.
>
Aha! he said...we're still talking about 2 separate things.
The customer is the expert in the business requirements:
the information they need to have, decisions that need to be
made, actions that need to be taken under what circumstances,
when they need to take place, who else needs them, and so on.
They absolutely know these things and I (as a project manager)
need to learn them.
Once I've got a fair grip on those business requirements, I may
turn to the technical experts and ask for designs that satisfy
those requirements.
With a fair grip on that, I bring the business customer back in
and walk through the design, showing why or how I think the design
meets their business needs. They get to disagree, add detail, and so on.
In other words, I let the business people be expert on the business
questions, and the technical people be expert in the technical questions.
Business requirements and system design are separate endeavors. Heck,
I even hold back from assuming that a systems change is needed until
it's shown that simpler process changes can satisfy the requirements.
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Paul Sinnett wrote:
> And that seems to match the sentiment: "customers seldom know what they
> really want" quite well. However, this view is not a product of XP. Most
> requirements gathering techniques go to great lengths to address this
> issue.
Exactly. I just was noting my preference for a much shorter, to the
point approach.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
> misalignment, but the activity
>
>
> Let's leave the word 'lying' aside for the moment.
Let's not. It wasn't my word. It was Ron's. I wasn't on the C3 project
and it doesn't sound like you were either.
>
> Obliquity objection. What are you talking about?
I was stating that your statement seemed a bit offensive, rude, and
uncalled for to me. What don't you understand about that? You don't have
to agree with it. It's just my opinion.
>
> For the reasons you gave (and I snipped for bandwidth) I'd think Change
> Orders
> occur in every approach.
Right, except XP makes change a more integral part of the process rather
than treating it as an exception. Since as you stated, changes "occur in
every approach".
So, if you admit that Change Orders are occuring, then what is the
reason for those changes? I see three: customers gaining a better
understanding of what they desire or need, programmers gaining a better
understanding of what is really desired or needed, and business changes.
The first two are basically the same thing, the shared knowledge of the
team at the start of the project did not completely represent in detail
what was actually needed or desired. That was my main point.
If these changes happen on every project, then how can you claim that
the result of "requirements analysis" is 100% of what the customer
acutally needs or wants. If so, then you would never need a change
order. The fact that you almost always need a change order means that
"requirements analysis" does not result in capturing 100% of what the
customer actually needs or wants. Again, this was my point.
>
> Objection overruled.
Not even remotely humorous. You might try to actually understand someone
else's reasons for taking offense. Perhaps your perspective is not the
only valid one here.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> Two quibbles:
> 1. Are you suggesting that you won't use effective tools
> because you don't like a methodology that uses them?
What tools are you referring to? I would probably not object to tools
when they make a job simpler and easier. I think the main objection is
when the tools are nearly *required* by a process that has been put in
place.
> 2. Changing requirements, or even design details, is cheaper
> on paper than it is in code, and production code at that.
> That's part of the value of doing those things up front.
Well, literally that may be true, except for one small detail. If you
change it on the paper itself, then you have to change it again in the
electronic copy, assuming that you do actually use electronic documents.
Now, if you mean changing a design document is cheaper than changing
code, I would ask you what evidence you have to this statement?
Why should changing text in one location (design document) be cheaper
than changing text in another (source code)?
In fact, the opposite seems to be true. Changing the design document
*also* requires changing the source code.
This may be one of the reasons why design documents become out-of-date
as the schedule gets tighter and tighter in many instances of
plan-driven projects. This is just my personal observation.
I think that what you are talking about is making *correct* changes. If
I have automated tests, then it is easier for me to make *correct*
changes without breaking other code.
[color=darkred]
> Requirements are 'what' and design is 'how'. Again,
> in classical project management, design gets worked, reviewed
> and agreed to when it's cheap and on paper.
First, why would a non-technical person want to review a technical
design document?
Second, document changes are significantly cheaper than implementation
changes when you are talking about hardware. What evidence do you have
to support this claim when discussing software?
As for storing requirements in one central location that the customer
can review to make sure the requirements are captured in detail as
desired, acceptance tests are probably a much better place than a design
document.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Scott Kinney 2004-04-27, 1:19 am |
| Xref: kermit comp.software.extreme-programming:29328
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:ce76a$408d17ef$cff54506$2574@dcanet
.allthenewsgroups.com...
> Scott Kinney wrote:
>
>
> Let's not. It wasn't my word. It was Ron's. I wasn't on the C3 project
> and it doesn't sound like you were either.
>
That's my point. To call something lying is requires knowledge neither
you nor I possess. Also, calling it lying is irrelevant to the
communications
planning/skills or approach required to address it.
>
>
> Right, except XP makes change a more integral part of the process rather
> than treating it as an exception. Since as you stated, changes "occur in
> every approach".
>
> So, if you admit that Change Orders are occuring, then what is the
> reason for those changes? I see three: customers gaining a better
> understanding of what they desire or need, programmers gaining a better
> understanding of what is really desired or needed, and business changes.
> The first two are basically the same thing, the shared knowledge of the
> team at the start of the project did not completely represent in detail
> what was actually needed or desired. That was my main point.
>
This is a good breakdown, but I disagree that your first two points are
'basically the same'. Yes, they both derive from 'learning more', but
learning more about 'business needs' is different from learning more about
'technical approach'.
Before getting deeper into your rant about "100% completeness" let me
explain the process of project initiation.
To get approval, money, resources etc for a project I, as a project manager
need to make this sort of case:
Here is the business goal my customer wishes to achieve:
Here is a description of what (requirements) my customer needs to
do/have/be to achieve those goals.
Here is a description of how (design) we will support these goals.
Here is a description of our approach for delivering the system/process...
Here is an estimate of the time, people, money, other resources needed.
Skipping for the moment statement of Risk Assessment, Risk Management
Here is our approach for managing changes to scope, requirements, design,
delivery, resources, schedule or budget,
Assuming the TPB think that's a good deal we go forward.
Change management process is an
integral part of a plan-driven process. Changes will occur,
for all the reasons you describe and others not forseen. They
*are* exceptions, and they must be evaluated for their effect
on the scope, requirements, delivery, schedule etc.
Not every change needs to be accepted, not every change
is worth its other effects on the project.
My work on requirements gathering, requirements analysis, design
and estimates *up front* has to be good enough to secure project
funding and resources. If I don't do these things, then I'm not helping
my customer. Going in with a half-assed set of requirements and estimates
just because it's faster won't help my customer if it gets me turned down
or sent back to the drawing board.
Now, I've explained my process. If you would, please explain how
change management is done in XP?
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> What I hear and read in XP literature, if I may paraphrase, is;
> "We don't need that level of skill/practice because we have the
> people in the room."
Where do you see that?
My expectation of other developers on an XP project goes up a few
notches. I expect everyone to be more disciplined, to have higher
standards of quality, etc.
> Have I misinterpreted, are there other expectations of the XP
> practitioner (specific skills and attitudes) that are assumed, or left
> undescribed?
Have you read the Agile Manifesto?
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Scott Kinney 2004-04-27, 1:19 am |
| Xref: kermit comp.software.extreme-programming:29331
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:3bc9b$408d1e23$cff54506$2726@dcanet
.allthenewsgroups.com...
> Scott Kinney wrote:
>
>
>
> Well, literally that may be true, except for one small detail. If you
> change it on the paper itself, then you have to change it again in the
> electronic copy, assuming that you do actually use electronic documents.
>
> Now, if you mean changing a design document is cheaper than changing
> code, I would ask you what evidence you have to this statement?
>
> Why should changing text in one location (design document) be cheaper
> than changing text in another (source code)?
"Code" as it seems to be consistently used in this and other threads on
the newsgroup means ; tested, working, delivered code.
To my simple mind, that implies efforts to change design, change source
code, test, correct and port to production. Unless labor is free, changing
code costs more than changing design.
>
> In fact, the opposite seems to be true. Changing the design document
> *also* requires changing the source code
Why does changing the design automatically trigger coding those changes?
>
>
> First, why would a non-technical person want to review a technical
> design document?
We have to demonstrate to the customer that what we've designed
actually meets their requirements. A design walkthrough that
demonstrates that the 'Acceptance Test' will be met does this
pretty well, and certainly helps us distinguish between design problems
and translation problems when the design is coded.
>
> Second, document changes are significantly cheaper than implementation
> changes when you are talking about hardware. What evidence do you have
> to support this claim when discussing software?
>
The fact that programming effort costs money. Do I need more evidence?
Is labor free?
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:ce76a$408d17ef$cff54506$2574@dcanet
.allthenewsgroups.com...
>
>
> That's my point. To call something lying is requires knowledge neither
> you nor I possess. Also, calling it lying is irrelevant to the
> communications
> planning/skills or approach required to address it.
No, your point seems to be to try to call it something else. I want to
use the word that was used by the person who *was* there.
>
> This is a good breakdown, but I disagree that your first two points are
> 'basically the same'. Yes, they both derive from 'learning more', but
> learning more about 'business needs' is different from learning more about
> 'technical approach'.
I'm only currently discussing changes in the context of
requirements/User Stories. I am not in the habit of discussing technical
design details with non-technical customers.
> Before getting deeper into your rant about "100% completeness" let me
> explain the process of project initiation.
<snip>
Thanks for your list of steps in "project initiation". It sounds very
much like what I recollect from having done quite a number of
plan-driven projects in the past.
> Change management process is an
> integral part of a plan-driven process. Changes will occur,
> for all the reasons you describe and others not forseen. They
> *are* exceptions, and they must be evaluated for their effect
> on the scope, requirements, delivery, schedule etc.
They are only exceptions if you treat them that way. I don't (I used to
when I used a plan-driven approach). Again, you don't have to agree
here. We *do* define things differently, because we are taking different
approaches.
> Not every change needs to be accepted, not every change
> is worth its other effects on the project.
The change is only accepted if the customer indicates that a new User
Story is a higher priority than other stories for a particular
iteration. Who else would be indicating acceptance of these changes?
> My work on requirements gathering, requirements analysis, design
> and estimates *up front* has to be good enough to secure project
> funding and resources. If I don't do these things, then I'm not helping
> my customer. Going in with a half-assed set of requirements and estimates
> just because it's faster won't help my customer if it gets me turned down
> or sent back to the drawing board.
Again, rudeness objection. Please refrain from off-putting language.
Thank you. If you still can't understand, let me make it clear.
"Half-assed" is quite rude language. The general concept you are trying
to convey is also very down-putting and could easily be interpreted as
offensive.
Nobody is trying to do a less than adequate job just to deliver the end
results faster. That is called Cowboy Coding. That is not what XP is.
You do not have to understand an approach that is different from yours.
But, I'll kindly ask you not to use offensive remarks if you don't agree
with an XP approach in a forum intended for those interested in XP.
I try not to spend a lot of time discussing the offensiveness of these
types of remarks, and simply respond "rudeness objection". I sincerely
hope that my reasoning for doing this is now abundantly clear.
> Now, I've explained my process. If you would, please explain how
> change management is done in XP?
If you read Kent Beck's "XP Explained", the sub-title is called "Embrace
Change". We really do treat change as an expected occurance, rather than
as an exception. So there is not a specific "Change Management" process.
Basically, user requirements are represented as User Stories. New
requirements are new User Stories. Every new User Story is a change from
what is already implemented. New User Stories are allowed prior to the
start of any iteration. There's nothing all that special about it.
Did you have some questions? Is there something that's not clear here?
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Isaac Gouy 2004-04-27, 1:19 am |
| Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<cbpp80503la7h4dcdvkp1keoqcq98qb7jk@4ax.com>...
> On the contrary. The customers are being asked to imagine a thing
> which does not exist -- a software program. They are being asked to
> describe it in quite some detail, and they lack, at the beginning of
> this effort, any knowledge of the cost of the individual features.
Why are we asking customers to imagine what a software product could
be like? Shouldn't we be asking: What are the business goals? What are
the business tasks that need to be completed?
Task Descriptions as Functional Requirements
http://www.itu.dk/people/slauesen/Papers/IEEEtasks.pdf
> "Would you like to have a Ferrari?" "Yes!"
> "They cost $250,000." "Oh. Never mind."
>
> There's no disrespect or condesension in the observation that
> customers seldom know what they really want, merely observation.
We're offered a gift, and then it turns out that it's not a gift.
Does that show that we don't know what we really want, or merely that
we're capable of distinguishing between two quite different things:
the gift of a Ferrari versus purchasing a Ferrari.
> That's why we prefer to work closely with them, to give them cost
> estimates on all the features they imagine, and to show them the
> software as it grows.
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:3bc9b$408d1e23$cff54506$2726@dcanet
.allthenewsgroups.com...
>
<snip>[color=darkred]
>
> "Code" as it seems to be consistently used in this and other threads on
> the newsgroup means ; tested, working, delivered code.
> To my simple mind, that implies efforts to change design, change source
> code, test, correct and port to production. Unless labor is free, changing
> code costs more than changing design.
So, changes to a design document don't involve thinking about the design?
As I said in my post, if I'm going to change something *in addition to*
the code, the first thing I'm going to change is going to be tests, not
design documents.
In fact, if I am compelled to produce design documentation, I would
generally use something like doxygen. That way, the design documentation
is more likely to stay in sync.
You have still failed to indicate how changes to a design document are
cheaper than changes to code, as I've stated that both are simply text.
>
> Why does changing the design automatically trigger coding those changes?
If I'm not going to change the code, then why would I bother with those
changes to the design? My customers don't generally pay for a design
document. They are paying for a working product. Design is part of the
process that /I/ use to try to get there in the most effective way I can.
Now, if you are talking about the order, and timing, etc. Sure, I'm not
going to make a series of changes to the Acceptance Tests, the Unit
Tests, and the code all at the same time. I'm going to change the
Acceptance Tests first.
If you don't have Acceptance Tests, Unit Tests, etc. then maybe you
would be concerned that changing the code would potentially break
existing code. I would certainly agree with that.
>
> We have to demonstrate to the customer that what we've designed
> actually meets their requirements. A design walkthrough that
> demonstrates that the 'Acceptance Test' will be met does this
> pretty well, and certainly helps us distinguish between design problems
> and translation problems when the design is coded.
I would agree that Acceptance Tests indicate whether or not we are
meeting the customers requirements.
However, the technical design documentation does not seem to help a
non-technical customer in this regard at all. The technical design
documentation is purely for the technical members of a team. Am I
missing something?
>
> The fact that programming effort costs money. Do I need more evidence?
> Is labor free?
Are the technical design documents not written by programmers? Is their
time all of a sudden free when they are writing documentation instead of
code? Is there some reason that their cost would go down because they
are writing different types of text (text about the code rather than the
code itself)?
Yes, you do need more evidence to support your claim.
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Isaac Gouy 2004-04-27, 1:19 am |
| Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<408c9592$1@news.totallyobjects.com>...
> Scott Kinney wrote:
>
> The idea that people seldom know what they really want has been verified
> by experiment.
>
> In, The Paradox of Choice, Barry Schwartz describes an experiment where
> two groups of college students were asked to choose between a variety of
> snacks during the break of three seminars (one a w for three ws).
This is about "preferences".
What the students really want is not to be hungry.
| |
| Scott Kinney 2004-04-27, 1:19 am |
|
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:f0656$408d315e$cff54506$3193@dcanet
.allthenewsgroups.com...
> Scott Kinney wrote:
>
> <snip>
>
changing[color=darkred]
>
> So, changes to a design document don't involve thinking about the design?
>
> You have still failed to indicate how changes to a design document are
> cheaper than changes to code, as I've stated that both are simply text.
>
>
> Are the technical design documents not written by programmers? Is their
> time all of a sudden free when they are writing documentation instead of
> code? Is there some reason that their cost would go down because they
> are writing different types of text (text about the code rather than the
> code itself)?
>
> Yes, you do need more evidence to support your claim.
Only because you have not responded to my question.
So, I'll repeat in a different way....
*****Change to Design Only*****
expense: time spent thinking about design change
expense: time spent changing the design document
perhaps
expense: time spent testing design
*****Change to Code******
expense: time spent thinking about design change
expense: time spent changing the design document
expense: time spent testing design
expense: time spent translating design to source code
expense: time spent going from source code to executable code
expense: time spent testing
expense: time spent porting to production
Which of these entails more expense?
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Isaac Gouy wrote:
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<cbpp80503la7h4dcdvkp1keoqcq98qb7jk@4ax.com>...
>
>
> Why are we asking customers to imagine what a software product could
> be like? Shouldn't we be asking: What are the business goals? What are
> the business tasks that need to be completed?
My understanding was that we were talking about the *details* of the
requirements. Not just the User Story level, but what would be
incorporated into automated Acceptance Tests.
So, yes, we would be asking based on a given input what would be the
desired output. Much less ambiguous than requiring the customer to
imagine what they might get. The recommendation is to follow that up
with actual working, tested software in a short iteration and a short
release so the customer can acutally see what they are getting *instead
of* imagining.
> Task Descriptions as Functional Requirements
> http://www.itu.dk/people/slauesen/Papers/IEEEtasks.pdf
>
>
> We're offered a gift, and then it turns out that it's not a gift.
No, the customer wants a pony. See http://c2.com/cgi/wiki?IwantaPony
Customer: I want everything, and I want it now, no make that yesterday,
and I want it for free.
> Does that show that we don't know what we really want, or merely that
> we're capable of distinguishing between two quite different things:
> the gift of a Ferrari versus purchasing a Ferrari.
No, it shows that they really need and can afford things (Ford) that are
not what they *think* that they want (Ferrari).
The issue is that there is some software engine that excels in areas
desired (Ferrari performance), but does have the cost of the most
expensive software engine (the entire Ferrari). To carry the analogy
even further, the customer does not wish to buy a car based on concept
diagrams and models displayed at trade shows. They'd much prefer a test
drive.
[color=darkred]
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:f0656$408d315e$cff54506$3193@dcanet
.allthenewsgroups.com...
>
>
> changing
>
>
> Only because you have not responded to my question.
I apologize. Which question was that?
> So, I'll repeat in a different way....
>
> *****Change to Design Only*****
> expense: time spent thinking about design change
> expense: time spent changing the design document
> perhaps
> expense: time spent testing design
>
> *****Change to Code******
> expense: time spent thinking about design change
> expense: time spent changing the design document
> expense: time spent testing design
> expense: time spent translating design to source code
> expense: time spent going from source code to executable code
> expense: time spent testing
> expense: time spent porting to production
>
> Which of these entails more expense?
This is not the question that I was asking. I had asked, "Why should
changing text in one location (design document) be cheaper than changing
text in another (source code)?"
You have included many other activities. I'm not clear what criteria you
are using to get to your definitions. I certainly don't agree with your
definitions at all.
Based on your definitions, then yes you have redefined what "change to
code" means to include enough expenses to be clearly more expensive.
Is there some reference you can cite where all of these steps are
defined as the simplest way to make a "Change to Code"? Also, I am
curious why "Change to Design Only" does not also then include time
spent changing the Test Plan, time spent changing the Gantt Charts, time
spent adjusting the schedule, etc. Are these not also impacted?
You're definition of "change to code" is curiously lacking the actual
step of changing the source code. You have redefined "change to code" to
mean changing design documentation, plus some included model of the
system, generating the code, etc. Perhaps the tools and process you are
describing is not the most efficient approach. This is what I am
acutally asking you to consider.
So, when I asked "Why should changing text in one location (design
document) be cheaper than changing text in another (source code)", I am
not asking "Why should changing text in one location (design document)
be cheaper than changing text in many locations (design document plus
source code, plus ...)"? I can see why you might be puzzled based on
your definition of "Change to Code". Again, I'm not sure why you feel
that your definition of "Change to Code" is obvious. It is certainly not
the definition I would have chosen.
The closest I can come to your definition of "Change to Code" is to add
a User Story, then add or change an Acceptance Test, then add or change
a Unit/Programmer Test, then actually change the source code. However, I
will freely admit that this is not cheaper than just changing the source
code (nor am I proposing that one *just change the source code*). I do
all of these steps because the Unit/Programmer Tests seem to provide
more value than simply just changing the source code itself.
I would never state, however, that the steps I am listing are cheaper
than just changing the source code. This seemed to be what you were
stating (changing design documentation is cheaper than changing source
code). I've heard this before, and am more and more puzzled as to why
someone would believe this. I did not realize that changing source code
meant something other than changing source code, or have I missed something?
Have we cleared this up?
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
| |
| Scott Kinney 2004-04-27, 1:19 am |
| Xref: kermit comp.software.extreme-programming:29341
"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:de9ba$408d436c$cff54506$3740@dcanet
.allthenewsgroups.com...[color=darkred]
Yes, I've become convinced that you are constitutionally
incapable of answering the question.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 08:52:24 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>'Interviewing', to me, is a collection of skills to elicit information;
>skills like asking open-ended questions (even knowing which sorts
>of attributes to 'unravel'), testing understanding, being able to recreate
>key arguments and concerns,building rapport,
>mirroring, and many others. I may do this in words, I may use pictures,
>I may mimic processes on 3x5 cards, and so on.
Yes ...
>
>What I hear and read in XP literature, if I may paraphrase, is;
>"We don't need that level of skill/practice because we have the
>people in the room."
Please tell us just what you have read that says such a thing. It's
just not the case.
>
>Have I misinterpreted, are there other expectations of the XP
>practitioner (specific skills and attitudes) that are assumed, or left
>undescribed?
XP is described by a dozen practices which, if done, ensure that the
team has enough information to keep the project on track. It is
expected that the team will use all its skills, not just those dozen,
every day, as appropriate.
No one has ever said "do just these dozen".
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 08:55:07 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@
4ax.com...
>I meant to ask this earlier; when you use the term 'return on investment'
>do you mean it literally (an actual model of costs, returns, value over time
>return on separate features of the project, etc.) or more figuratively?
I mean it both literally and figuratively.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 11:07:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Code" as it seems to be consistently used in this and other threads on
>the newsgroup means ; tested, working, delivered code.
>
>To my simple mind, that implies efforts to change design, change source
>code, test, correct and port to production. Unless labor is free, changing
>code costs more than changing design.
What good is a change to the design if you don't change the code?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 11:07:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>The fact that programming effort costs money. Do I need more evidence?
>Is labor free?
Surely producing a document plus code costs more than producing just
code.
Surely producing only code produces a program, and producing only a
document does not.
Therefore a balance between when one documents (as late as possible)
and when one programs (as early as possible) often makes sense. It
depends on the relative cost of coding and documenting (where
documenting may be less costly), on the relative value of the two
(where coding is surely more valuable in the end), and on the
observation that even if we document, we cannot avoid the cost of
writing the code, but that we can sometimes avoid the cost of writing
the document.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 12:12:39 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Only because you have not responded to my question.
>
>So, I'll repeat in a different way....
>
>*****Change to Design Only*****
>expense: time spent thinking about design change
>expense: time spent changing the design document
>perhaps
>expense: time spent testing design
>
>*****Change to Code******
>expense: time spent thinking about design change
>expense: time spent changing the design document
>expense: time spent testing design
>expense: time spent translating design to source code
>expense: time spent going from source code to executable code
>expense: time spent testing
>expense: time spent porting to production
>
>
>Which of these entails more expense?
Which one produces a program?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 09:22:17 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>Aha! he said...we're still talking about 2 separate things.
>
>The customer is the expert in the business requirements:
>the information they need to have, decisions that need to be
>made, actions that need to be taken under what circumstances,
>when they need to take place, who else needs them, and so on.
>They absolutely know these things and I (as a project manager)
>need to learn them.
>
>Once I've got a fair grip on those business requirements, I may
>turn to the technical experts and ask for designs that satisfy
>those requirements.
>
>With a fair grip on that, I bring the business customer back in
>and walk through the design, showing why or how I think the design
>meets their business needs. They get to disagree, add detail, and so on.
>
>In other words, I let the business people be expert on the business
>questions, and the technical people be expert in the technical questions.
>
>Business requirements and system design are separate endeavors. Heck,
>I even hold back from assuming that a systems change is needed until
>it's shown that simpler process changes can satisfy the requirements.
The //Customer// in Extreme Programming is a //role// whose
responsibilities include knowing what is needed and breaking that down
into feature requests (stories), each of which can be implemented and
tested inside one iteration.
This //role// is often staffed with real end users, with inhouse
experts such as marketing people, with business analysts, and with
domain-experienced testers.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Laurent Bossavit 2004-04-27, 1:19 am |
| Paul:
> The idea that people seldom know what they really want has been verified
> by experiment.
I tend to doubt that philosophical questions can be verified by
experiment. A tip-off that the question you are describing is a
philosphical one is the appearance of the word "really".
I'm certain that many experiments have been done, and more are being
done, on how well people's expectations of their own behaviours match
the reality of these behaviours.
But think back to the sub-thread which concluded with Isaac and me
agreeing that "there's no point in being precise if we don't know what
we are talking about". The question "do customers know what they really
want" is one of these questions where we don't know what we are talking
about.
A while ago, I posted some thoughts toward getting clear on what we are
talking about :
http://bossavit.com/thoughts/archives/000687.html
Laurent
http://bossavit.com/thoughts/
| |
| Laurent Bossavit 2004-04-27, 1:19 am |
| Scott:
> In other words, I let the business people be expert on the business
> questions, and the technical people be expert in the technical questions.
Excellent advice.
Laurent
http://bossavit.com/thoughts/
| |
| Scott Kinney 2004-04-27, 1:19 am |
| Xref: kermit comp.software.extreme-programming:29353
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@
4ax.com...
time[color=darkred]
>
> I mean it both literally and figuratively.
Please tell me how you model this as a literal calculation; factors,
assumptions,
time horizons, costs, etc.
I set up two projects, 12 features to deliver, equal amounts of
effort to deliver, and delivering 1 per month doesn't seem to provide
(numerically anyway) a greater return on investment than delivering
3 per quarter, say, or 6 every 6 months.
What goes into your calculation?
| |
| Laurent Bossavit 2004-04-27, 1:19 am |
| Isaac:
> Why are we asking customers to imagine what a software product could
> be like? Shouldn't we be asking: What are the business goals? What are
> the business tasks that need to be completed?
Those are two *very* different questions - I'm concerned that asking
them in close succession, you might be suggesting that they are two
sides of one coin. Tasks support goals - there's a logical order there.
As to the "why" question, the problem is that while goals can often be
articulated in vague, general terms at the outset of a project, to reach
a goal requires restating it in precise (that word again) terms. A goal
must also be positive, achievable, observable, and somewhat flexible.
Very often, you can only meet these standards after doing one or more of
the following (and that's a partial list):
- breaking the goal down into sub-goals
- seeing a partial solution in action
- discovering unwanted side-effects of attaining the goal
- discarding the original goal for a revised version
Goal-setting often proceeds in parallel with solution-exploring. This is
why part of specifying what we want from a software product involves
imagining what the product will be like.
Laurent
http://bossavit.com/thoughts/
| |
| Isaac Gouy 2004-04-27, 1:19 am |
| Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<cb067$408d3bc7$cff54506$3521@dcanet.allthenewsgroups.com>...
>
> My understanding was that we were talking about the *details* of the
> requirements.
The OP was talking about business goals and tasks: "The customer
always knows exactly what they want from a business perspective."
>
> No, the customer wants a pony. See http://c2.com/cgi/wiki?IwantaPony
The customer was offered a Ferrari.
>
> No, it shows that they really need and can afford things (Ford) that are
> not what they *think* that they want (Ferrari).
What confusion!
The customer said they would like to have a Ferrari - there's no
reason to doubt that. They don't wish to pay you $250,000 for a
Ferrari. That says nothing about what they really need or what they
can afford.
| |
| Paul Sinnett 2004-04-27, 1:19 am |
| > Paul:
Laurent Bossavit wrote:[color=darkred]
> I tend to doubt that philosophical questions can be verified by
> experiment. A tip-off that the question you are describing is a
> philosphical one is the appearance of the word "really".
This phrasing was not mine - I was paraphrasing Scott. I took it to mean
what a customer might imagine they would want versus what they do want
when given the choice. That difference is what the experiments
demonstrate. It's not an attempt to answer any philosophical question as
far as I am aware.
> I'm certain that many experiments have been done, and more are being
> done, on how well people's expectations of their own behaviours match
> the reality of these behaviours.
They have. A dozen or more are described in the book. Which is, after
all, what the book is about.
Another example is the research that demonstrates patients commonly
prefer to have others make decisions for them. 65% of people surveyed
said that, if they had cancer, they would want to choose their own
treatment. But, in fact, only 12% of people who have cancer want to make
that choice.
> But think back to the sub-thread which concluded with Isaac and me
> agreeing that "there's no point in being precise if we don't know
> what we are talking about". The question "do customers know what they
> really want" is one of these questions where we don't know what we
> are talking about.
I don't understand the point you are making.
> A while ago, I posted some thoughts toward getting clear on what we
> are talking about : http://bossavit.com/thoughts/archives/000687.html
>
> Laurent http://bossavit.com/thoughts/
Yes, these experiences are similar to my own. I don't see that they
contradict any of the experimental evidence.
| |
| Robert C. Martin 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 08:52:24 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>What I hear and read in XP literature, if I may paraphrase, is;
>"We don't need that level of skill/practice because we have the
>people in the room."
There's no denying that it would be good if some of the people in the
room had those skills.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Paul Sinnett 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> If we are thinking of the same requirements gathering techniques,
> they do not come from a base of 'the customer doesn't know what they
> want', they come from a base of 'the project team doesn't know what
> the customer wants.'
These are not either / or positions. If all we had to do was ask the
customer to write the requirements, requirements gathering would be
trivial. But it is not that simple. That is why methods were designed to
address the problem.
> My objection to the attitude is:
>
> 1. I don't believe that it's true. The customer knows their business,
> they know it way better than I do, and they know their business
> needs better than I do (at least at the beginning.)
>
> 2. The attitude has no payoff in the requirements gathering process,
> it gives me no advantage, and it poisons my ability to build
> rapport with them.
This is a different issue. We are mixing need with want - they are
commonly  and a major contributor to the problem of requirements
misalignment. The standard distinction is as follows:
"Need and want. Need implies an objective judgement, want a subjective,
a distinction often blurred by loose use of want. A child may need
punishment but is unlikely to want it. 'Never was legislation more
needed; never was it less wanted,' said Lloyd George of his National
Health Insurance Act." -- Fowler's Modern English Usage
The customer is indeed the expert when it comes to their business needs.
No argument there from me, XP, or any requirements gathering method I
know of.
| |
| Paul Sinnett 2004-04-27, 1:19 am |
| > Laurent Bossavit wrote:
Paul Sinnett wrote:[color=darkred]
> Yes, these experiences are similar to my own. I don't see that they
> contradict any of the experimental evidence.
You do appear to confuse need with want here though:
... I believed in "customers don't know what they want". I knew better
than my customers what they needed.
As I pointed out to Scott, it's not my position that customer's are a
bad source for what they need, only that they are a bad source for what
they want.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@
4ax.com...
>time
>
>Please tell me how you model this as a literal calculation; factors,
>assumptions,
>time horizons, costs, etc.
>
>I set up two projects, 12 features to deliver, equal amounts of
>effort to deliver, and delivering 1 per month doesn't seem to provide
>(numerically anyway) a greater return on investment than delivering
>3 per quarter, say, or 6 every 6 months.
>
>What goes into your calculation?
Suppose we have 12 features, each worth $1000 per month in revenue
after deployment. If we deploy 6 every six months, our revenue looks
like this:
month revenue
1 0
2 0
3 0
4 0
5 0
6 0
7 6000
8 6000
9 6000
10 6000
11 6000
12 6000
13 12000
total 48000 in 13 months
If we deploy 1 feature every month, revenue looks like this:
1 0
2 1000
3 2000
4 3000
5 4000
6 5000
7 6000
8 7000
9 8000
10 9000
11 10000
12 11000
13 12000
total 78000 in 13 months
The same reasoning holds, less numerically, for any kind of value,
tangible or intangible, that the program may provide. Value sooner
increases ROI.
Questions?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-04-27, 1:19 am |
| On 26 Apr 2004 15:40:09 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<cb067$408d3bc7$cff54506$3521@dcanet.allthenewsgroups.com>...
>
>
>The OP was talking about business goals and tasks: "The customer
>always knows exactly what they want from a business perspective."
I'd not fully agree with this. What one wants is conditioned by what
it will cost to get it, and made less than certain by one's limited
ability to imagine things.
I think that the customer generally has a decent idea what they want,
and that guided by information about cost and by seeing what has been
wrought, they come to a better understanding of what should be done.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Robert C. Martin 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@
4ax.com...
>time
>
>Please tell me how you model this as a literal calculation; factors,
>assumptions,
>time horizons, costs, etc.
>
>I set up two projects, 12 features to deliver, equal amounts of
>effort to deliver, and delivering 1 per month doesn't seem to provide
>(numerically anyway) a greater return on investment than delivering
>3 per quarter, say, or 6 every 6 months.
Ron can answer this better than I can. However, I'll just say this.
You make more money by putting a dollar a day in the bank, than by
putting 365 dollars in the bank every January 1st. This is especially
true if the interest rate is very high, (which it better be if the
project is really worth doing).
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Robert C. Martin 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 09:09:01 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>If we are thinking of the same requirements gathering techniques, they do
>not
>come from a base of 'the customer doesn't know what they want', they come
>from
>a base of 'the project team doesn't know what the customer wants.'
>
>My objection to the attitude is:
>
>1. I don't believe that it's true. The customer knows their business, they
>know
>it way better than I do, and they know their business needs better than I do
>(at least at the beginning.)
They even know them better at the end. The problem is they don't know
what kind of system will best address those needs.
>2. The attitude has no payoff in the requirements gathering process, it
>gives
>me no advantage, and it poisons my ability to build rapport with them.
On the contrary, it give you a starting place. You can assess their
needs, and recommend a potential solution in terms of a few system
requirements. That recommendation is a hypothesis -- a guess that
those system behaviors will have value. Once you have a hypothesis,
the next thing to do is to test it. In this case, we test it by
building a simple system that has those behaviors and letting the
customer touch, feel, and (better yet) use it.
The result of this experiment will show that you were right about some
things and wrong about others. We make a new hypothesis and run the
experiment again. The more often we can run it, the faster we
converge on what the customer *really* wants.
>
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Robert C. Martin 2004-04-27, 1:19 am |
| On 26 Apr 2004 09:06:10 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<408c9592$1@news.totallyobjects.com>...
>
>
>This is about "preferences".
>What the students really want is not to be hungry.
That need could be adequately addressed with cans of Alpo. Cheap,
nutritious, and utterly unacceptable. Indeed, this is what many
customers get at the end of the day. A system that addresses the
need, and is unacceptable.
Larman's recent book: "Agile and Iterative Development: A managers
Guide" is loaded with data on this, and many other issues.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Robert C. Martin 2004-04-27, 1:19 am |
| On Mon, 26 Apr 2004 09:22:17 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>With a fair grip on that, I bring the business customer back in
>and walk through the design, showing why or how I think the design
>meets their business needs. They get to disagree, add detail, and so on.
Which is a nice way to get buy-in for a hypothesis. The next thing to
do is test that hypothesis by building a simple system that exhibits
the behaviors you described.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Jason Nocks 2004-04-27, 1:19 am |
| Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:de9ba$408d436c$cff54506$3740@dcanet
.allthenewsgroups.com...
<was snipped>
</was snipped>
[color=darkred]
>
> Yes, I've become convinced that you are constitutionally
> incapable of answering the question.
Let me repeat:
"I apologize. Which question was that?" -me
I can't answer the question if I don't know what the question is.
Cheers,
Jason Nocks
SourceXtreme, Inc.
| | |