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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

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

  1. #1
    Scott W. Ambler Guest

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


    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.*




  2. #2
    Lori Piquet Guest

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

    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.
    >
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center