Re: Are You Passing the Requirements Buck? -- April 4 Conversation

[Scott W. Ambler]

Note: The other conversation happened on the afternoon of April 3, not on
April 4. This conversation, however, happened on April 4. Some material
repeats from my previous posting because this is an ongoing conversation.

Scott: Reread what you wrote in the editorial. You said "Ambler says defining
requirements and prioritizing them are solely the responsibility of business
stakeholders and not the concern of developers" during the talk.*This implies
that I actually said that. I didn't. If you disagree, then please listen
to your recording and find the point where I actually said those words.*

LP: I didn't say that you said that during the talk. In that sentence I meant
for the reference to apply to your writings--to the page which I linked to
the statement. I can be more specific about that, if necessary.

Scott: Have you considered having someone else read the first paragraph of
your editorial and then asking them what you're implying? The paragraph
discusses that you attended my talk. It then discusses that I began to
espouse my beliefs about requirements. It then, and I quote once again "Ambler
says.....". Please reread what you've written.

LP: The first draft of my editorial actually had a long quote from your writings
in it, which I took out in favor of the link (due to its length but also
because I decided that it was more fair to you to drive the readers to your
essay rather than to excerpt part of it, which would have exacerbated our
current issue). The part that I was going to quote was this part:
" Your project stakeholders – direct or indirect users, managers, senior
managers, operations staff members, support (help desk) staff members, testers,
developers working on other systems that integrate or interact with your,
and maintenance professionals – are the ONLY official source of requirements.
In fact it is the responsibility of project stakeholders to provide, clarify,
specify, and prioritize requirements. Furthermore, it is the right of project
stakeholders that developers invest the time to identify and understand those
requirements. This is concept is critical to your success as an agile modeler
– it is the role of project stakeholders to provide requirements, it is the
role of developers to understand and implement them."

"Does that imply that you sit there in a stupor waiting for your project
stakeholders to tell you what they want? No, of course not. You can ask
questions to explore what they have already told you, arguably an analysis
activity, motivating them to specify in greater detail what they want and
perhaps even to rethink and modify their original requirement(s). You can
suggest new requirements to them, the key word being SUGGEST, that they should
consider and either accept (perhaps with modifications) or reject as an official
requirement. To identify potential requirements you may also, often with
the aid of your project stakeholders, work through existing documents such
as corporate policy manuals, existing legacy systems, or publicly available
resources such as information on the web, books, magazine articles, or the
products and services of your competitors. Once again, it is your project
stakeholders that are the ultimate source of requirements, it is their decision
and not yours. I cannot be more emphatic about this."

NOTE: The material above was the first two paragraphs of Agile Requirements,
a long essay that describes my philosophies on the subject.

LP: This is*the crux of the misunderstanding. I have read this over and over
again. I still disagree with it.

Scott: It's ok for you to disagree with it, but it's a completely other thing
to misrepresent it, which you've clearly done and which many people have
gone out of their way to point out to you.*

LP: In the next paragraph you write:
"The point to be made is that your project stakeholders should be formulating
requirements based on a wide range of inputs, something that you may want
to ensure is happening by asking questions."

LP: Phrases like "you may want to ensure" imply ambiguity. My point is that
there is no ambiguity to be had. I want the developer who is going to build
something that I have to think of to FEEL, to BELIEVE, to KNOW beyond all
doubt that it's his problem too.*I want us to design it together.*I don't
want him to think that he would be an awfully nice guy if he did but oh darn
lookit the time.

Scott: Yes, which is why people should work together closely, something that
AM definitely promotes. You would be very hard pressed to find anything
within AM that contracts this. I used the word "may" because it is an option.
Sometimes stakeholders are doing a very good job and I don't need to dig
in too deep, particularly when I've been working with them closely and their
past track records supports this assumption. Other times the situation is
different and I have to be more actively involved with exploring requirements.
The problem with your argument is that you're taking things out of context.
One of the underlying assumptions of AM, described very clearly in the book
(www.ambysoft.com/agileModeling.html) is that developers are responsible
and motivated. In other words, they'll do their best to do the right thing.
When this isn't the case you're likely setting yourself up for failure.

LP: You also write: "Because your project stakeholders are the requirements
experts. They are the ones that know what they want, ..."

LP: This, too, is contrary to what I believe. When you say that I'm the "requirements
expert" my blood goes cold. I HATE doing requirements. It makes me want to
cry. If you tell developers that I'm the "expert" what hope do we have in
the world? <g> I'm being over-dramatic on purpose, but when you say that
I "know what I want" I am here to tell you that I very frequently do not
know what I want.*You might argue that it's in my head somewhere and it just
has to be brought out. OK, it might be. <she says with doubt in her voice>*But
I am not going to be able to get it out by myself. That's just*not going
to happen. And we cannot be mealy-mouthed about the fact that it is the developer's*JOB,
RESPONSIBILITY,*to help me. If you agree with that statement, then this is
what I meant when I said that I perceive a contradiction.

Scott: Yes, which is why you need to work together. Hence the AM practice
of Active Stakeholder Participation. You might not be able to describe what
you want right now, but you might be able to get some of it. So I build
some software as best I can, show it to you, get you to use it, get better
input from you because now you have something concrete to work with, and
then iterate until we get it right. During the presentation I believe I
used the analogy of decorating a living room, one that I use a fair bit.
The point that I made is that if you can't figure out how to arrange the
furniture in your living room on the first cut then what makes you think
you can get your requirements defined properly on the first cut?

LP: You made a statement, which*if you'll allow me to paraphrase, is:*Requirements
are the responsiblility of project stakeholders. And the definition of project
stakeholders specifically excludes developers.*My position is that requirements
are a joint responsibility*of developers and business people.*More specifically,
without developers who are*wholeheartedly committed to thinking through the
problem with me from the outset, we may as well not try--the results are
likely to suck.*

Scott: Yes, this is much closer to what I say. I also, say, like you, that
the two groups should work together. In fact I have written several books
on this very topic. Unfortunately, you are taking things out of context.
The two paragraphs that you copied from the Agile Requirements essay even
go to this point. Had you just a bit further in that essay you would have
run into http://www.agilemodeling.com/essays/...s.html#Figure1 (sorry
about the hand writing) that clearly shows exactly what you're talking about.
The point is, if you're going to paraphrase one of my essays then at least
look at the entire thing. Nitpicking the use of the word "may" in a sentence
then going off on a tangent isn't appropriate.

LP: I am listening to everything that everybody's saying (even if I'm being
mostly quiet) and I hear you loud and clear. You don't disagree with what
I've written

Scott: To paraphrase Ron Jeffries, please listen harder. I completely and
utterly disagree with what you've written in the first section of your editorial.
Completely. Utterly.*

LP: and it seems unfair to be put in the enemy camp, so to speak.

Scott: I'm not saying that you're in the "enemy camp". But I am saying
that your actions very likely unknowingly are aiding and abetting them.

LP: I've got that. And I do want to do the right thing.

Scott: Great, please do so.

LP: But I'm still stuck here:*you've written things that *in my opinion*
are wrong things to say--or at the very least, the wrong way to say them.
I oppose any statement which seems to give developers an opportunity to say:
<hands in the air> Hey, that's your call. Don't ask me!

Scott: Great. Please write about these things. But don't attribute things
to me that I haven't said. If you want to paraphrase me, the please point
that out when you do so. Sentences starting with "Ambler says...." pretty
well imply that I said them. It's not rocket science.*

Scott: Have you considered rewording that sentence to something like "Although
Ambler doesn't believe in this at all, what I have chosen to misinterpret
him as saying is...". That would actually reflect what is going on in your
editorial.

LP: I want developers to give their opinions and not to feel that by doing
so they break some sort of rule. That they are crossing over some magic line
in the sand where they get their hands slapped for suggesting too much. That's
just playing the politics game. The game of protecting the engineering department
from criticism. Can you see where I think that certain specific aspects of
your writings play into that?

Scott: Great. Read the entire essay then. Yes, if you choose to only read
the first two paragraphs, and you choose to badly misinterpret them, then
I can see how you can make the incredibly huge mistake that you've made.
If you want to do so then that's fine, but at least have the integrity to
point out that what you are writing about is your misinterpretation of what
I said, and what I've written,*and does not actually reflect my beliefs.*

[Lori Piquet]

For those who are not subscribed to the weekly HotLinks newsletter or have
not yet seen it on the DevX home page, Scott Ambler's rebuttal to my
editorial of April 2 has been published. If you've been following this
conversation at all, I urge you to read it.

http://www.devx.com/DevX/Article/11801

There is another response as well, from one of our regular authors, Bryan
Dollery.
http://www.devx.com/DevX/Article/11799

Thanks to both, but particularly to Scott, for agreeing to stay with this
conversation.

Lori Piquet
Editor-in-chief
DevX


"Scott W. Ambler" <scott.ambler@ronin-intl.com> wrote in message
news:3e8f811b$1@tnews.web.devx.com...
>
> Note: The other conversation happened on the afternoon of April 3, not on
> April 4. This conversation, however, happened on April 4. Some material
> repeats from my previous posting because this is an ongoing conversation.
>
> Scott: Reread what you wrote in the editorial. You said "Ambler says
defining
> requirements and prioritizing them are solely the responsibility of
business
> stakeholders and not the concern of developers" during the talk. This
implies
> that I actually said that. I didn't. If you disagree, then please listen
> to your recording and find the point where I actually said those words.
>
> LP: I didn't say that you said that during the talk. In that sentence I
meant
> for the reference to apply to your writings--to the page which I linked to
> the statement. I can be more specific about that, if necessary.
>
> Scott: Have you considered having someone else read the first paragraph of
> your editorial and then asking them what you're implying? The paragraph
> discusses that you attended my talk. It then discusses that I began to
> espouse my beliefs about requirements. It then, and I quote once again
"Ambler
> says.....". Please reread what you've written.
>
> LP: The first draft of my editorial actually had a long quote from your
writings
> in it, which I took out in favor of the link (due to its length but also
> because I decided that it was more fair to you to drive the readers to
your
> essay rather than to excerpt part of it, which would have exacerbated our
> current issue). The part that I was going to quote was this part:
> " Your project stakeholders - direct or indirect users, managers, senior
> managers, operations staff members, support (help desk) staff members,
testers,
> developers working on other systems that integrate or interact with your,
> and maintenance professionals - are the ONLY official source of
requirements.
> In fact it is the responsibility of project stakeholders to provide,
clarify,
> specify, and prioritize requirements. Furthermore, it is the right of
project
> stakeholders that developers invest the time to identify and understand
those
> requirements. This is concept is critical to your success as an agile
modeler
> - it is the role of project stakeholders to provide requirements, it is
the
> role of developers to understand and implement them."
>
> "Does that imply that you sit there in a stupor waiting for your project
> stakeholders to tell you what they want? No, of course not. You can ask
> questions to explore what they have already told you, arguably an analysis
> activity, motivating them to specify in greater detail what they want and
> perhaps even to rethink and modify their original requirement(s). You can
> suggest new requirements to them, the key word being SUGGEST, that they
should
> consider and either accept (perhaps with modifications) or reject as an
official
> requirement. To identify potential requirements you may also, often with
> the aid of your project stakeholders, work through existing documents such
> as corporate policy manuals, existing legacy systems, or publicly
available
> resources such as information on the web, books, magazine articles, or the
> products and services of your competitors. Once again, it is your project
> stakeholders that are the ultimate source of requirements, it is their
decision
> and not yours. I cannot be more emphatic about this."
>
> NOTE: The material above was the first two paragraphs of Agile
Requirements,
> a long essay that describes my philosophies on the subject.
>
> LP: This is the crux of the misunderstanding. I have read this over and
over
> again. I still disagree with it.
>
> Scott: It's ok for you to disagree with it, but it's a completely other
thing
> to misrepresent it, which you've clearly done and which many people have
> gone out of their way to point out to you.
>
> LP: In the next paragraph you write:
> "The point to be made is that your project stakeholders should be
formulating
> requirements based on a wide range of inputs, something that you may want
> to ensure is happening by asking questions."
>
> LP: Phrases like "you may want to ensure" imply ambiguity. My point is
that
> there is no ambiguity to be had. I want the developer who is going to
build
> something that I have to think of to FEEL, to BELIEVE, to KNOW beyond all
> doubt that it's his problem too. I want us to design it together. I don't
> want him to think that he would be an awfully nice guy if he did but oh
darn
> lookit the time.
>
> Scott: Yes, which is why people should work together closely, something
that
> AM definitely promotes. You would be very hard pressed to find anything
> within AM that contracts this. I used the word "may" because it is an
option.
> Sometimes stakeholders are doing a very good job and I don't need to dig
> in too deep, particularly when I've been working with them closely and
their
> past track records supports this assumption. Other times the situation is
> different and I have to be more actively involved with exploring
requirements.
> The problem with your argument is that you're taking things out of
context.
> One of the underlying assumptions of AM, described very clearly in the
book
> (www.ambysoft.com/agileModeling.html) is that developers are responsible
> and motivated. In other words, they'll do their best to do the right
thing.
> When this isn't the case you're likely setting yourself up for failure.
>
> LP: You also write: "Because your project stakeholders are the
requirements
> experts. They are the ones that know what they want, ..."
>
> LP: This, too, is contrary to what I believe. When you say that I'm the
"requirements
> expert" my blood goes cold. I HATE doing requirements. It makes me want to
> cry. If you tell developers that I'm the "expert" what hope do we have in
> the world? <g> I'm being over-dramatic on purpose, but when you say that
> I "know what I want" I am here to tell you that I very frequently do not
> know what I want. You might argue that it's in my head somewhere and it
just
> has to be brought out. OK, it might be. <she says with doubt in her voice>
But
> I am not going to be able to get it out by myself. That's just not going
> to happen. And we cannot be mealy-mouthed about the fact that it is the
developer's JOB,
> RESPONSIBILITY, to help me. If you agree with that statement, then this is
> what I meant when I said that I perceive a contradiction.
>
> Scott: Yes, which is why you need to work together. Hence the AM practice
> of Active Stakeholder Participation. You might not be able to describe
what
> you want right now, but you might be able to get some of it. So I build
> some software as best I can, show it to you, get you to use it, get better
> input from you because now you have something concrete to work with, and
> then iterate until we get it right. During the presentation I believe I
> used the analogy of decorating a living room, one that I use a fair bit.
> The point that I made is that if you can't figure out how to arrange the
> furniture in your living room on the first cut then what makes you think
> you can get your requirements defined properly on the first cut?
>
> LP: You made a statement, which if you'll allow me to paraphrase, is:
Requirements
> are the responsiblility of project stakeholders. And the definition of
project
> stakeholders specifically excludes developers. My position is that
requirements
> are a joint responsibility of developers and business people. More
specifically,
> without developers who are wholeheartedly committed to thinking through
the
> problem with me from the outset, we may as well not try--the results are
> likely to suck.
>
> Scott: Yes, this is much closer to what I say. I also, say, like you,
that
> the two groups should work together. In fact I have written several books
> on this very topic. Unfortunately, you are taking things out of context.
> The two paragraphs that you copied from the Agile Requirements essay even
> go to this point. Had you just a bit further in that essay you would have
> run into http://www.agilemodeling.com/essays/...s.html#Figure1
(sorry
> about the hand writing) that clearly shows exactly what you're talking
about.
> The point is, if you're going to paraphrase one of my essays then at
least
> look at the entire thing. Nitpicking the use of the word "may" in a
sentence
> then going off on a tangent isn't appropriate.
>
> LP: I am listening to everything that everybody's saying (even if I'm
being
> mostly quiet) and I hear you loud and clear. You don't disagree with what
> I've written
>
> Scott: To paraphrase Ron Jeffries, please listen harder. I completely and
> utterly disagree with what you've written in the first section of your
editorial.
> Completely. Utterly.
>
> LP: and it seems unfair to be put in the enemy camp, so to speak.
>
> Scott: I'm not saying that you're in the "enemy camp". But I am saying
> that your actions very likely unknowingly are aiding and abetting them.
>
> LP: I've got that. And I do want to do the right thing.
>
> Scott: Great, please do so.
>
> LP: But I'm still stuck here: you've written things that *in my opinion*
> are wrong things to say--or at the very least, the wrong way to say them.
> I oppose any statement which seems to give developers an opportunity to
say:
> <hands in the air> Hey, that's your call. Don't ask me!
>
> Scott: Great. Please write about these things. But don't attribute
things
> to me that I haven't said. If you want to paraphrase me, the please point
> that out when you do so. Sentences starting with "Ambler says...." pretty
> well imply that I said them. It's not rocket science.
>
> Scott: Have you considered rewording that sentence to something like
"Although
> Ambler doesn't believe in this at all, what I have chosen to misinterpret
> him as saying is...". That would actually reflect what is going on in
your
> editorial.
>
> LP: I want developers to give their opinions and not to feel that by doing
> so they break some sort of rule. That they are crossing over some magic
line
> in the sand where they get their hands slapped for suggesting too much.
That's
> just playing the politics game. The game of protecting the engineering
department
> from criticism. Can you see where I think that certain specific aspects of
> your writings play into that?
>
> Scott: Great. Read the entire essay then. Yes, if you choose to only
read
> the first two paragraphs, and you choose to badly misinterpret them, then
> I can see how you can make the incredibly huge mistake that you've made.
> If you want to do so then that's fine, but at least have the integrity to
> point out that what you are writing about is your misinterpretation of
what
> I said, and what I've written, and does not actually reflect my beliefs.
>
>
>