Are You Passing the Requirements Buck?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 10 of 10

Thread: Are You Passing the Requirements Buck?

Hybrid View

  1. #1
    Scott Ambler Guest

    Are You Passing the Requirements Buck?


    Just wanted to let everyone know that I've posted a response to Lori's April
    2nd editorial at www.agilemodeling.com/essays/passingTheBuck.htm.

    - Scott

  2. #2
    Jon Kern Guest

    Re: Are You Passing the Requirements Buck?


    Lori's (<a href="http://www.devx.com/devx/editorial/11728">http://www.devx.com/devx/editorial/11728</a>)

    was the classic error in misunderstanding what agile methods preach.<p>

    In her quote:
    <hr>
    <blockquote>
    <p><cite>The process of creating software requirements simply cannot be
    decoupled
    from the technical knowledge base, and that technical knowledge base
    lies
    in the brains of developers. Ambler's faith in the business stakeholders
    borders
    on irrational. </cite></p>
    </blockquote>
    <hr>
    <p>She must not understand that we implore a dialog between business users
    and
    developers. Take some of the recent postings (Agile Modeling forum) regarding

    a company that is heading for disaster because the business users are ignoring

    some of the technical team's inputs regarding scalability and deployment
    realities.
    Indeed, it is the duty of the two sides to work together, to do what each
    does
    best. For business to solely run the game, disaster will happen -- as is
    likely
    to display itself on the project Ian describes. For technical folks to
    run the
    game themselves would be equally a challenge.</p>
    <hr>
    <p></p>
    <blockquote>
    <p><cite>However much development wants business stakeholders to be perfectly

    equipped to define and prioritize software tasks, it's simply wishful
    thinking.
    Sure, it would be great if you had interested, technically astute business

    people who could clearly formulate software requirements and help with
    design
    and who are given adequate time to devote to the process, but this circumstance

    is far too rare to expect.</cite> </p>
    </blockquote>
    <hr>
    <p></p>
    <p>And to think that anyone in the agile community expects -- or even wants
    --
    stakeholders as described above, is obviously missing the point. We want
    business
    users who can state what they need -- and they don't even have to be accurate

    at first, given that not all requirements can be known up front. We want
    them
    to work with us to arrive at the final state of the requirement, as we
    wrote
    in the Agile Manifesto (<a href="www.agilemanifesto.org">www.agilemanifesto.org</a>).

    </p>
    <hr>
    <p></p>
    <blockquote>
    <p><cite>But left on my own </cite>[to write s/w specs]<cite>, the right
    questions
    don't seem to occur to me, until far too late. <br>
    </cite> </p>
    </blockquote>
    <hr>
    <p></p>
    <p>This, of course, is exactly why common development methods that try to
    espouse
    gathering all requirements up front go astray (and help make the Standish
    report
    outlandish). Also applies to those organizations who have snotty IT groups
    who
    demand users/customers write requirements before they will even talk to
    them.
    I go to great lengths to make sure business people/customers speak their
    language.
    I do not try to get them to speak in geek terms -- if I hear technical
    issues
    creeping in prematurely, I try to steer back to &quot;just the requirements,

    please.&quot;</p>
    <hr>
    <p></p>
    <blockquote>
    <p><cite>Development teams once bore all the responsibility of building
    software
    and seldom had adequate input and feedback from the business side. Those
    days
    are <font color="#FF0000">thankfully over</font>.</cite></p>
    </blockquote>
    <hr>
    <p></p>
    <p>How can &quot;those days be over?&quot; Do we claim victory now or later?</p>
    <hr>
    <p></p>
    <blockquote>
    <p><cite>It's the job of the business people to know what customers need,
    to
    decide how a new software product should work to best meet those needs,
    and
    it's your job to make it work the way they say. That way, if the software

    works, but fails to meet expectations, the business side people have
    no one
    to blame but themselves. [...] It's no wonder this management philosophy
    is
    growing more popular.<br>
    </cite> </p>
    </blockquote>
    <hr>
    <p></p>
    <p align="left">This again is not what agile espouses! It is a team effort.
    If
    a development team does not work with the customer to iterate to the best
    solution
    to meet their needs, and merely &quot;takes dictation&quot; and doesn't
    think,
    that is not proper nor desirable. The business people do not decide the
    &quot;how&quot;
    of a software product. The developer is not responsible &quot;to make it
    work
    the way they say.&quot; This is rude at best...</p>
    <p align="center">&quot;Our highest priority is to satisfy the customer<br>
    through early and continuous delivery<br>
    of valuable software.&quot;<br>
    </p>
    <hr>
    <p></p>
    <p align="left"></p>
    <blockquote>
    <p><cite>But if you're participating in the groundswell that eschews responsibility

    for requirements planning, you're simply exchanging one set of problems
    for
    far uglier ones. <br>
    </cite> </p>
    </blockquote>
    <hr>
    <p></p>
    <p align="left"></p>
    <p>To describe &quot;agile methods&quot; in this light should be <font color="#FF0000"><i>retracted

    immediately</i></font>. It is a complete misrepresentation, to the point
    of
    being derisive and damaging.<br>
    <br>
    </p>
    <p><br>
    -- jon kern (one of the authors of the Agile Manifesto)</p>
    <p>&nbsp;</p>


  3. #3
    Bill Wohler Guest

    Re: Are You Passing the Requirements Buck?


    Lori,

    As you recall, the first credo in the Agile Software Development Manifesto
    was this:

    1. Individuals and interactions over process and tools.

    Interactions. That is not solely between developers, but also between developers
    and customer. Rather than a customer drafting a set of requirements and tossing
    it over the fence to the developers (which you somehow thought Scott was
    espousing), or vice-versa, the developers and customer together, in the same
    room, write requirements on index cards.

    Requirements shouldn't have implementation details in them so the customer
    is therefore qualified to write them. The developer is on hand to help the
    customer and provide suggestions of his own.

    As you correctly noted, the customer doesn't know if the task will take 10
    hours or 10 weeks. The developer is there to take note and suggest that the
    task be broken down into sub-tasks that fit into the iteration. The developer
    then makes a rough time estimate of each task so that the customer can do
    a cost-benefit analysis and prioritize the stack of tasks.

    Yes, the content and ordering of the stack of requirements *is* the sole
    responsibility of the customer, but as you see, this stack was created with
    *interactions* with the developer.

    The second half of your article does a pretty job of describing agile software
    development; I hope we can persuade you to rewrite the first half so that
    it does too.

  4. #4
    Lori Piquet Guest

    Re: Are You Passing the Requirements Buck?

    For those who are interested, here is the full text of my email dialog today
    with Scott Ambler (picking up where his post left off) regarding this week's
    editorial. The flow is top-down. Lori

    ******************
    [[Lori Piquet wrote:]]
    Scott,

    First let me thank you for taking the time to answer my editorial with facts
    and explanations that show clearly where you feel it is amiss. I'm very
    grateful and though I hate to think that something I've written is patently
    wrong, if it is, I want to address that.



    So am I wrong? Well, let's get the exposition out of the way first. There
    are two different topics for discussion here. First, the thrust of the
    editorial itself (outside of the fact that I have used your presentation
    specifically, and agile methodology in general, as support). That doesn't
    seem to be a matter of disagreement between us. I'm glad for that. We are in
    agreement, I guess, about certain basic problems in the requirements
    process.



    The second topic is the one that matters in this context and that is: Have I
    misrepresented the tenets of the Agile methodology? Have I completely skewed
    the position so as to turn your teachings against certain principles that it
    actually supports and addresses?



    One of my big concerns while writing this editorial was that it could not
    include the entire exposition of Agile programming. I am perhaps guilty of
    oversimplifying, but I believe in the validity of my points. I encourage
    anyone to read what you've written and draw their own conclusions. I was not
    in any way trying to hide the truth of what the Agile method really is, as
    evidenced by the links to the source material.



    I appreciate, in particular, the part in your note where you explained how
    elements of your presentation last week exemplified the ways that the Agile
    process supports the creation of better requirements. For example, in your
    presentation, when you said that you would write down the topic discussions
    requested by the audience but already had several suggested topics
    prepared . I will admit that I did not perceive that as a direct application
    of leading or guiding business people to more useful requirements. I regret
    that I missed the point of that but I'm glad you pointed it out to me now.
    It underscores that Agile processes can and do facilitate collaboration,
    which we will both agree is critical. I am well aware of and supportive of
    many principles of Agile development. And I also know that Agile development
    seeks to foster communication between the development team and the business
    community it serves. That much was absolutely clear from your presentation
    and from your writings. I still maintain, however, that placing the
    responsibility for requirements definition squarely on businesspeople is not
    efficient. Businesspeople should be responsible for defining the business
    need for the application, and for providing an initial vision, to some
    degree, but that's as far as their responsibility should go until
    development gets involved. At that point, the goal for both groups should be
    to create a shared vision, nurtured and molded by both businesspeople and
    developers. Only after that happens can a final set of requirements be
    written and agreed to by both groups, because they now both have a stake in
    the outcome. Therefore, it's simply not in either businesspeople's or
    developers' best interests to try to place the burden for requirements
    definition on one or the other.



    I think we're arguing the same side of the coin. You espouse, as emphasized
    in your reply, that requirements are the responsibility of project
    stakeholders; but the definition of project stakeholders (as stated in
    http://www.agilemodeling.com/essays/...ticipation.htm) does
    not include developers--in fact, it specifically excludes them. On the other
    hand, as the document goes on, the relationship of developers to
    stakeholders gets infinitely more complicated, so that the meaning of those
    early statements about responsibility and the definition of a stakeholder
    are gray.



    In contrast, I believe businesspeople need to document the business need and
    initiate the conversation that should lead to a shared vision, but should
    NOT be solely responsible for the requirements--not even initial
    requirements.



    Perhaps I misunderstood, but as a coworker just said to me: 'If you
    misunderstood it, then so do a lot of other people, and they have a problem
    with their message.'



    In any event, there is an excellent way to proceed. Would you care to write
    a rebuttal, one that clearly explains how the agile method results in better
    application requirements without requiring the responsibility of developers?
    If you decide to do so, please explain exactly how your method would
    actually solve the problems that I kvetched about. Also, please explain why
    the word "responsibility" in your methodology seems (to my ear, at least) to
    be a contradiction of what you actually mean to say.



    In the end, Scott, I think we are not in a particular state of disagreement.
    There is only the matter of ensuring that ALL of what I said is correct. My
    offer of a rebuttal is an opportunity to correct any mistatements of fact.



    My only concern is presenting the DevX reader with information that
    improves, not hampers, their job performance, productivity, and
    satisfaction.



    Cordially,

    Lori Piquet



    [[Scott Ambler's responses are inline, preceded by "Scott:"]]



    Scott,

    First let me thank you for taking the time to answer my editorial with facts
    and explanations that show clearly where you feel it is amiss. I'm very
    grateful and though I hate to think that something I've written is patently
    wrong, if it is, I want to address that.



    So am I wrong?



    Scott: Yes.



    Well, let's get the exposition out of the way first. There are two
    different topics for discussion here. First, the thrust of the editorial
    itself (outside of the fact that I have used your presentation specifically,
    and agile methodology in general, as support). That doesn't seem to be a
    matter of disagreement between us. I'm glad for that. We are in agreement, I
    guess, about certain basic problems in the requirements process.



    Scott: There are potentially some problems with the requirements process,
    and some of the issues you bring up are valid. I don't have a problem with
    some of these issues, but the context that you present them in is
    questionable at best.



    Scott: Unfortunately your characterization of my presentation was
    spectacularly off-track. I have no doubt that as word gets out about your
    article that other people who attended the talk will also point out the
    things that I have. Furthermore, as you may remember another person was in
    the audience writing the talk up for SD Forum. He actually sent me the
    rough draft so that I could provide feedback to him, something you didn't
    do, and I can safely say that what he reports is fairly accurate. It will
    soon be posted on the web and when that happens I will share the URL
    publicly. His version is significantly different than what you've reported.
    Also, the talk will eventually be digitized and made publicly available on
    the web so that everyone can see what I actually presented.



    The second topic is the one that matters in this context and that is: Have I
    misrepresented the tenets of the Agile methodology? Have I completely skewed
    the position so as to turn your teachings against certain principles that it
    actually supports and addresses?



    Scott: Yes.



    Scott: Although you linked to my agile requirements essay (which I missed on
    the first read of the article) I'd be surprised to discover that you
    actually read it. The first few paragraphs of that essay completely and
    utterly contradict what you reported in your editorial. Furthermore, IMHO,
    his essay describes in detail the requirements principles that I was trying
    t get across in my talk.





    One of my big concerns while writing this editorial was that it could not
    include the entire exposition of Agile programming. I am perhaps guilty of
    oversimplifying,



    Scott: Actually, you're guilty of getting it completely wrong. Had you read
    the articles that you referenced you would have noticed this. Had you
    contacted me with questions perhaps you wouldn't have gone so far astray.





    but I believe in the validity of my points. I encourage anyone to read what
    you've written and draw their own conclusions.



    Scott: This is the problem. People without a background in agile processes
    are reading things written by people who don't understand what
    they'rewriting about. You have caused significant damage with this
    editorial.



    I was not in any way trying to hide the truth of what the Agile method
    really is, as evidenced by the links to the source material.



    Scott: Yet you still completely and utterly misrepresented what I said. If
    you don't agree with me, please contact other people that you know attended
    the talk and show them your original editorial and what I posted at
    www.agilemodeling.com/essays/passingTheBuck.htm. Ask them to give their
    honest opinion.





    I appreciate, in particular, the part in your note where you explained
    howelements of your presentation last week exemplified the ways that the
    Agile process supports the creation of better requirements. For example, in
    your presentation, when you said that you would write down the topic
    discussions requested by the audience but already had several suggested
    topics prepared ... I will admit that I did not perceive that as a direct
    application of leading or guiding business people to more useful
    requirements. I regret that I missed the point of that but I'm glad you
    pointed it out to me now.



    Scott: So, then perhaps what you've written about what I said in the talk
    is... ummm.... how shall I put this... completely and utterly wrong?





    It underscores that Agile processes can and do facilitate collaboration,
    which we will both agree is critical. I am well aware of and supportive of
    many principles of Agile development. And I also know that Agile development
    seeks to foster communication between the development team and the business
    community it serves.



    Scott: Then why did you present what I said differently? To quote: "Ambler
    says defining requirements and prioritizing them are solely the

    responsibility of business stakeholders and not the concern of developers".
    Sort of goes against what you just said that "you know" about agile
    development, and CERTAINLY goes against everything that I've written on the
    topic. In fact, way back in 1994 when I wrote the first edition of The
    Object Primer (www.ambysoft.com/theObjectPrimer.html) I included several
    "radical" user-centered design techniques that enabled developers and
    business folks to work together effectively. To be blunt, I'm incredibly
    offended by how you characterized what I said because it goes completely
    against my beliefs, experiences, and writings.



    That much was absolutely clear from your presentation and from your
    writings.



    Scott: Thanks. Then why didn't you present my talk in that light?



    I still maintain, however, that placing the responsibility for requirements
    definition squarely on businesspeople is not efficient.



    Scott: Me too. Which is why I don't recommend it and certainly didn't in
    that talk. If you don't believe me, feel free to call up the SD Forum folks
    and have them send a copy of the tape to you so you can review it for
    yourself.



    Businesspeople should be responsible for defining the business need for the
    application, and for providing an initial vision, to some degree, but that's
    as far as their responsibility should go until development gets involved. At
    that point, the goal for both groups should be to create a shared vision,
    nurtured and molded by both businesspeople and developers. Only after that
    happens can a final set of requirements be written and agreed to by both
    groups, because they now both have a stake in the outcome. Therefore, it's
    simply not in either businesspeople's or developers' best interests to try
    to place the burden for requirements definition on one or the other.



    Scott: Agreed. If you pick up copies of some of my books, you'll see that
    I've been writing about this sort of stuff for years. Not only that, but I
    also describe a lot of really good techniques that work in the real world
    for doing exactly what you're talking about.



    I think we're arguing the same side of the coin. You espouse, as emphasized
    in your reply, that requirements are the responsibility of project
    stakeholders; but the definition of project stakeholders (as stated in
    http://www.agilemodeling.com/essays/...ticipation.htm) does
    not include developers--in fact, it specifically excludes them.



    Scott: Yes, so I can distinguish between the two concepts. Each group has
    different rights and responsibilities (actually a reflect of one another).



    On the other hand, as the document goes on, the relationship of developers
    to stakeholders gets infinitely more complicated, so that the meaning of
    those early statements about responsibility and the definition of a
    stakeholder are gray.



    Scott: Then perhaps you should have emailed me and asked me about this
    issue? Or read some more? Or called me?



    In contrast, I believe businesspeople need to document the business need and
    initiate the conversation that should lead to a shared vision, but should
    NOT be solely responsible for the requirements--not even initial
    requirements.



    Perhaps I misunderstood, but as a coworker just said to me: 'If you
    misunderstood it, then so do a lot of other people, and they have a problem
    with their message.'



    In any event, there is an excellent way to proceed. Would you care to write
    a rebuttal, one that clearly explains how the agile method results in better
    application requirements without requiring the responsibility of developers?
    If you decide to do so, please explain exactly how your method would
    actually solve the problems that I kvetched about. Also, please explain why
    the word "responsibility" in your methodology seems (to my ear, at least) to
    be a contradiction of what you actually mean to say.



    Scott: I could do that, but an even better approach would be for you to
    listen to the concerns that people have been emailing you, to do a little
    more research, and to rethink what you've written. What I would like to see
    is an update to your editorial, even if it's simply an addendum, describing
    your misunderstanding and pointing people to your talk back forum so that
    they can come up to speed on how this issue has progressed. As I posted in
    another email on the Agile Modeling List
    (www.agilemodeling.com/feedback.htm), and hinted at above, I have already
    run into at least one situation where someone is taking your editorial as
    "proof" that agility is a bad idea. You've caused the damage, you need to
    repair it.



    Scott: You might be interested to know that this sort of thing has happened
    before. Last Spring Barry Boehm published an article that had a few
    misunderstandings in it. He then acted accordingly and worked with members
    of the agile community, including myself, to rectify the situation. Granted,
    he published in print so he couldn't undo the original damage but at least
    his more recent writings actually represent agility fairly. I always invite
    people to be skeptical, I likely even advised people to be skeptical at the
    beginning of my talk, but I guess I shouldn't assume that they'll always be
    fair. Barry has done his utmost, in my opinion, to be fair and to further
    his own learning. If you read www.sdmagazine.com/documents/s=7224/sdm0207g/
    I summarize the experience -- please forgive the title, sigh, and I bet if
    you search around the web a bit you'll find other, more recent write ups.





    In the end, Scott, I think we are not in a particular state of disagreement.



    Scott: Actually, I have to disagree with you on that. We fundamentally
    disagree on how you have represented my talk. I would appreciate it if you
    were to think about what has happened, recognize the damage that you've
    caused to people's understanding of agility, and then act accordingly.



    There is only the matter of ensuring that ALL of what I said is correct. My
    offer of a rebuttal is an opportunity to correct any misstatements of fact.



    Scott: I think that www.agilemodeling.com/essays/passingTheBuck.htm is a
    good start at a rebuttal. I also think that you're the one that needs to
    fix this mistake, not me.



    My only concern is presenting the DevX reader with information that
    improves, not hampers, their job performance, productivity, and
    satisfaction.



    Scott: Really? Hard to tell from where I'm sitting.



    Cordially,

    Lori Piquet



    With you permission, I will post this to talk.devx.com. You have my
    permission to distribute this communication publicly.



    <snip>



    - Scott



    [[Lori Piquet wrote:]]

    Scott,

    My replies are now prefaced with LP:



    Scott: Unfortunately your characterization of my presentation was
    spectacularly off-track. I have no doubt that as word gets out about your
    article that other people who attended the talk will also point out the
    things that I have. Furthermore, as you may remember another person was in
    the audience writing the talk up for SD Forum. He actually sent me the
    rough draft so that I could provide feedback to him, something you didn't
    do, and I can safely say that what he reports is fairly accurate. It will
    soon be posted on the web and when that happens I will share the URL
    publicly. His version is significantly different than what you've reported.
    Also, the talk will eventually be digitized and made publicly available on
    the web so that everyone can see what I actually presented.



    LP: I'm glad that it will. You seem to be more and more under the impression
    that I'm at odds with everything you said and believe in, which is not true.
    I have no motive for the presentation to be suppressed. I have the entire
    thing recorded in digital audio format myself. Another person's news report
    is immaterial to the issue of my opinion piece.



    It underscores that Agile processes can and do facilitate collaboration,
    which we will both agree is critical. I am well aware of and supportive of
    many principles of Agile development. And I also know that Agile development
    seeks to foster communication between the development team and the business
    community it serves.



    Scott: Then why did you present what I said differently? To quote: "Ambler
    says defining requirements and prioritizing them are solely the

    responsibility of business stakeholders and not the concern of
    developers".Sort of goes against what you just said that "you know" about
    agile development, and CERTAINLY goes against everything that I've written
    on the topic. In fact, way back in 1994 when I wrote the first edition of
    The Object Primer (www.ambysoft.com/theObjectPrimer.html) I included several
    "radical" user-centered design techniques that enabled developers and
    business folks to work together effectively. To be blunt, I'm incredibly
    offended by how you characterized what I said because it goes completely
    against my beliefs, experiences, and writings.



    LP: The point of my editorial is not to attack Agile Modeling. Never was. My
    point was to say that I disagree that developers can be taken out of
    requirements planning at any level. Your would agree with that statement.
    Therefore I am guilty of oversimplifying your position and taking certain
    statements at face value when they should not have been.



    In the end, Scott, I think we are not in a particular state of disagreement.



    Scott: Actually, I have to disagree with you on that. We fundamentally
    disagree on how you have represented my talk. I would appreciate it if you
    were to think about what has happened, recognize the damage that you've
    caused to people's understanding of agility, and then act accordingly.



    LP: I said that your methods state that defining requirements are the
    responsibility of business-side people and not developers. Then I used this
    as a launching pad for my opinion on why developers need to be involved in
    planning at every step of the way. You feel that I should not have used AM
    as a brick in that path. I agree that I capitalized on a contradiction in
    your stated methods as a means of writing what is a legitimate viewpoint. I
    did not do it intentionally or maliciously. However, in the interests of
    making sure that I do not misguide people in a way that I had never intended
    (remember I never wanted to discredit AM in the first place), I will do the
    following:

    * I am happy to direct people to any and all debate that results from this
    editorial. I will add a prominent link from the story to this page:
    http://www.agilemodeling.com/essays/passingTheBuck.htm, and to the AM
    mailing list on Topica.

    * I will also add an addendum (in the form of an Editor's Note box) to say
    that while your methodology states that requirements are not the
    responsibility of developers, the particulars of the relationship you
    encourage between them cannot be so easily summed up and that readers should
    not take that statement at face value. I will say that the body of your work
    is clearly dedicated to improving collaboration rather than the opposite. I
    will emphasize that my issue is not with AM but rather with anyone who
    patently says that developers have no responsibility in initial requirement
    planning.

    * My offer to feature an editorial from you on how collaboration in AM is
    actually done stands. FWIW, I wish you would take me up on it. I know you're
    not interested in my opinions right now, but I think this situation
    highlights some contradictions that are in your interests to address.



    Cordially,

    Lori Piquet



    ***********8



    "Scott Ambler" <scott.ambler@ronin-intl.com> wrote in message
    news:3e8c4f85$1@tnews.web.devx.com...
    >
    > Just wanted to let everyone know that I've posted a response to Lori's

    April
    > 2nd editorial at www.agilemodeling.com/essays/passingTheBuck.htm.
    >
    > - Scott




  5. #5
    Scott Ambler Guest

    Re: Are You Passing the Requirements Buck?


    Here is the text from an email conversation betweeen Lori and I on the Agile
    Modeling Mailing List (www.agilemodeling.com/feedback.htm) on April 4.

    Scott: Unfortunately your characterization of my presentation was spectacularly
    off-track. I have no doubt that as word gets out about your article that
    other people who attended the talk will also point out the things that I
    have. Furthermore, as you may remember another person was in the audience
    writing the talk up for SD Forum. He actually sent me the rough draft so
    that I could provide feedback to him, something you didn't do, and I can
    safely say that what he reports is fairly accurate. It will soon be posted
    on the web and when that happens I will share the URL publicly. His version
    is significantly different than what you've reported. Also, the talk will
    eventually be digitized and made publicly available on the web so that everyone
    can see what I actually presented.

    LP: I'm glad that it will. You seem to be more and more under the impression
    that I'm at odds with everything you said and believe in, which is not true.
    I have no motive for the presentation to be suppressed. I have the entire
    thing recorded in digital audio format myself. Another person's news report
    is immaterial to the issue of my opinion piece.

    Scott: Lori, you have mischaracterized what I said. You need to separate
    out the first part of your editorial, which misreports what I said, with
    the second part which is an opinion piece. The first part you got terribly
    wrong. I'm saying that you got it wrong. Other people that were at the
    talk are saying that you got it wrong. It completely contradicts everything
    that I've ever written.*Therefore chances are pretty good that you got it
    wrong. Seeing as you have a digital recording of the talk, please go through
    it again and you will discover that I didn't say the things that you're claiming
    that I said. If you do that I highly suspect that you'll discover that what
    you've written is incredibly skewed. At a minimum, if you want to continue
    on the track that you're on you should at least rework the first part of
    your editorial to point out that this was how you perceived what I said,
    not actually what I said. Right now it reads as a statement of fact, which
    I think is incredibly inappropriate.

    LP: It underscores that Agile processes can and do facilitate collaboration,
    which we will both agree is critical. I am well aware of and supportive of
    many principles of Agile development. And I also know that Agile development
    seeks to foster communication between the development team and the business
    community it serves.

    Scott: Then why did you present what I said differently? To quote: "Ambler
    says defining requirements and prioritizing them are solely the responsibility
    of business stakeholders and not the concern of developers". Sort of goes
    against what you just said that "you know" about agile development, and CERTAINLY
    goes against everything that I've written on the topic. In fact, way back
    in 1994 when I wrote the first edition of The Object Primer (www.ambysoft.com/theObjectPrimer.html)
    I included several "radical" user-centered design techniques that enabled
    developers and business folks to work together effectively. To be blunt,
    I'm incredibly offended by how you characterized what I said because it goes
    completely against my beliefs, experiences, and writings.

    LP: The point of my editorial is not to attack Agile Modeling. Never was.
    My point was to say that I disagree that developers can be taken out of requirements
    planning at any level. Your would agree with that statement. Therefore I
    am guilty of oversimplifying your position and taking certain statements
    at face value when they should not have been.

    Scott: I'm not saying that you're attacking Agile Modeling. I'm saying that
    you have misrepresented what I said, that there was ample evidence to indicate
    that what you thought I said was opposite of what I've been espousing for
    years, and that you had ample opportunity to discuss any issues with me but
    chose not to. Please go back and reread what you've written. The reason
    why so many people have problems with your editorial is because the first
    part of it falsely represents what I said at the talk and what I believe
    in. Go back and reread the emails that you've gotten. I'd be surprised
    if many of the disagree with the second part of the editorial, and some very
    likely agree with what you've written. It's the first half of the editorial
    that is problematic.

    Scott: If you do in fact agree that you are guilty of oversimplifying what
    I said, and taking certain statements at face value, then you should point
    this out in your editorial. Right now a reader that didn't attend the talk
    would come away with a significantly warped idea of what happened and what
    Agile Modeling (AM) actually recommends. I've said it before and I'll say
    it again -- Your editorial has caused significant damage within the community.

    LP: In the end, Scott, I think we are not in a particular state of disagreement.

    Scott: Actually, I have to disagree with you on that. We fundamentally disagree
    on how you have represented my talk. I would appreciate it if you were to
    think about what has happened, recognize the damage that you've caused to
    people's understanding of agility, and then act accordingly.

    LP: I said that your methods state that defining requirements are the responsibility
    of business-side people and not developers.

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

    Scott: Then reread what I wrote in my essays.**They clearly*say that project
    stakeholders, which are far more than just business-side people, are responsible
    for requirements. But that doesn't mean they don't work with the developers
    to define them. I was very clear about that in the presentation (please
    listen to it again if you don't believe me). I even ran the presentation
    following this principle, as I pointed out in an earlier email.

    LP: *Then I used this as a launching pad for my opinion on why developers
    need to be involved in planning at every step of the way. You feel that I
    should not have used AM as a brick in that path. I agree that I capitalized
    on a contradiction in your stated methods as a means of writing what is a
    legitimate viewpoint.

    Scott: Contradiction? What contradiction? All I'm seeing so far is your
    misunderstanding and inability to admit that you've made a serious mistake.
    Please describe this contradiction.

    LP: I did not do it intentionally or maliciously. However, in the interests
    of making sure that I do not misguide people in a way that I had never intended
    (remember I never wanted to discredit AM in the first place), I will do the
    following:

    Scott: Whether or not you INTEND to misguide people you clearly have.

    LP: I am happy to direct people to any and all debate that results from this
    editorial. I will add a prominent link from the story to this page: http://www.agilemodeling.com/essays/passingTheBuck.htm,
    and to the AM mailing list on Topica.

    LP: I will also add an addendum (in the form of an Editor's Note box) to
    say that while your methodology states that requirements are not the responsibility
    of developers, the particulars of the relationship you encourage between
    them cannot be so easily summed up and that readers should not take that
    statement at face value. I will say that the body of your work is clearly
    dedicated to improving collaboration rather than the opposite. I will emphasize
    that my issue is not with AM but rather with anyone who patently says that
    developers have no responsibility in initial requirement planning.

    Scott: I've seen the update to the editorial. It's a good start. However,
    it doesn't address the fundamental issue that you have clearly misrepresented
    what I said during the talk. As I said earlier, you should at least point
    out that what you've written is your misperception of what I said as opposed
    to what I actually said. Right now you continue to misguide your readers.
    You are doing them a great disservice.

    LP: My offer to feature an editorial from you on how collaboration in AM
    is actually done stands. FWIW, I wish you would take me up on it. I know
    you're not interested in my opinions right now, but I think this situation
    highlights some contradictions that are in your interests to address.

    Scott: I'll definitely write something for you, we can discuss that offline,*but
    I want to see this issue resolved first. Too many people will take what
    you've written in the first part as fact when it is clearly not and will
    use that as the reason they need to remain ignorant of agile techniques or
    even worse to stop other people from trying agile methods. Had you written
    a coherent argument against agility I wouldn't have a problem with it, although
    I might be tempted to debate it. At the present moment this isn't the case.
    I seriously recommend that you take the time to listen to the talk again,
    to read the other things that I've written, and to talk with (and listen
    to)*other people.*


  6. #6
    Mike Mitchell Guest

    Re: Are You Passing the Requirements Buck?

    On 3 Apr 2003 12:54:17 -0800, "Jon Kern" <jonkern@comcast.net> wrote:

    [snipped all, because totally unreadable]

    MM

  7. #7
    Bill Wohler Guest

    Re: Are You Passing the Requirements Buck?


    Lori,

    You wrote:

    > You espouse, as emphasized
    > in your reply, that requirements are the responsibility of project
    > stakeholders; but the definition of project stakeholders (as stated in
    > http://www.agilemodeling.com/essays/...ticipation.htm)


    > does not include developers--in fact, it specifically excludes them.


    I think you might be confusing the exclusion of developers from the *definition*
    of a stakeholder (true, and written) with the exclusion of developers from
    the requirements process (not true, not written).

    Scott,

    Lori might have a point about the following line in http://www.agilemodeling.com/essays/...uirements.htm:

    >it is the role of project stakeholders to provide requirements


    This is too easily taken incorrectly. Statements like "provide requirements"
    or "sole responsibility for requirements" in of themselves imply that the
    stakeholders throw the requirements in over the fence, which isn't the case
    at all. As you noted, the rest of the article tries to clarify, but after
    reading this line, it might be too late for the reader's mindset. Unless
    I am wrong ;-), and please correct me if I am, agile programming techniques
    espouse development of requirements by both the developer and stakeholder,
    but the stakeholder gets the last word on which of these mutually-discovered
    requirements go into the product. I think this subtle distinction is lost
    in the black and white statement above.

    The first sentence of the first paragraph in this paper also says:

    > Your project stakeholders ... are the ONLY official source of
    > requirements.


    Perhaps the emphasis should be on OFFICIAL, rather than ONLY.


  8. #8
    Scott Ambler Guest

    Re: Are You Passing the Requirements Buck?


    "Bill Wohler" <wohler@newt.com> wrote:
    <snip>

    Scott,
    >
    >Lori might have a point about the following line in http://www.agilemodeling.com/essays/...uirements.htm:
    >
    >>it is the role of project stakeholders to provide requirements

    >
    >This is too easily taken incorrectly. Statements like "provide requirements"
    >or "sole responsibility for requirements" in of themselves imply that the
    >stakeholders throw the requirements in over the fence, which isn't the case
    >at all. As you noted, the rest of the article tries to clarify, but after
    >reading this line, it might be too late for the reader's mindset.


    Yes, after going through this "incident" I can see how you can get the wrong
    idea. I'll be updating that paper soon to make things clearer.

    I guess it goes to the point that Alistair Cockburn likes to make about communciation
    -- documentation is your worst option, face-to-face communication around
    a whiteboard is your best option. I have this idea summarized at www.agilemodeling.com/essays/communcation.htm.

    > Unless
    >I am wrong ;-), and please correct me if I am, agile programming techniques
    >espouse development of requirements by both the developer and stakeholder,
    >but the stakeholder gets the last word on which of these mutually-discovered
    >requirements go into the product. I think this subtle distinction is lost
    >in the black and white statement above.


    You're right.

    >
    >The first sentence of the first paragraph in this paper also says:
    >
    >> Your project stakeholders ... are the ONLY official source of
    >> requirements.

    >
    >Perhaps the emphasis should be on OFFICIAL, rather than ONLY.
    >


    That's a good idea. I also need a following sentence, perhaps, that points
    people to the rest of the essay so that they don't stop reading there.

    Also, Lori has been kind enough to invite me to write a guest editorial in
    response to this. It's likely on the DevX site now.

    - Scott


  9. #9
    T. Hoskins Guest

    Re: Are You Passing the Requirements Buck?


    The Agile Modeling methodology is simply one of many Agile methodologies (SCRUM,
    FDD, Extreme Programming, Crystal, etc.) being promoted nowadays. While I
    have to plead ignorance to the specifics of Scott's methodology (Agile Modeling),
    I believe all the Agile methodologies have some common aspects to them (is
    the Agile Software Development Manifesto the only article that touches on
    this topic?).

    Seems to me that Lori Piquet hasn't done enough reading about what Agile
    Modeling (and perhaps the Agile community) is actually promoting. IMO, before
    writing this editorial Lori should have contacted Scott and asked him to
    clarify points of concern she had with AM or Scott's recent presentation.

    While I believe this article brought up some very interesting points that
    deserve further discussion, I have to say that some parts simply shouldn't
    have been included in this article. IMO, the author of this article acted
    in a very unprofessional manner. What she did is similar to what many reporters
    do nowadays -- print or air a story without first checking out the validity
    of the information they are reporting on.


    --- Personal Comments ---
    It is very difficult (if not impossible) for a developer website to be all
    things to all people so please don't take the following comments as criticism
    of this NG.

    One of the reasons I rarely visit this NG is because IMO it has always been
    about discussing specific technologies and helping developers write better
    code. If I was a commercial software developer, I probably would spend more
    time here. Unfortunately, I am business programmer who sometimes works alone
    and sometimes works with other developers (i.e. no project manager, architect,
    analyst, etc.) who only know how to write code and design solutions.

    So what point I am trying to make?

    Maybe it is just me, but the topic Lori Piquet brought up in her latest editorial
    article somehow seems to conflict with recent editorial articles (i.e. The
    10 Technologies that Will Help You Stay Employed and How to Learn the 10
    Most Important Technologies). I guess what I am trying to say is -- What
    message is DevX's staff trying to send to it's readers?

    Is it "Being good at software design and writing source code is all you need
    to do very well to stay employed in this industry" or is it "Being good at
    software design and writing decent source code is simply not good enough"?

    IMO, most individuals cannot have a career or be considered a professional
    in an industry that doesn't have some bureaucracy (i.e. rules and regulations)
    associated with it. The IT business community went from being small, fairly
    well-ordered, and very bureaucratic to where it is today -- huge, diverse,
    and totally chaotic. In other words, ever since large corporations lost their
    strangle hold on business computing nobody (except individual employers)
    makes the rules for this particular segment of the IT industry anymore.

    So what is the solution for the apparent lack of software developers who
    have expertise across each phase of software development lifecycle? IMO,
    one solution is self directed work teams which seems to be something that
    all the Agile methodologies promote.

  10. #10
    Rob Abbe Guest

    Re: Are You Passing the Requirements Buck?


    The Agile Modeling community should thank Lori for getting so many people
    to discuss this subject

    You have to give credit to Lori and DevX for the way this was handled. By
    the time links to the articles have made it through the vast web of blogs
    and discussion groups, any wrongs that have been committed should have been
    corrected since Scott was given the chance to make his case. A lot more
    people including myself now know more about Agile Modeling then they ever
    cared to!

    "Scott Ambler" <scott.ambler@ronin-intl.com> wrote:
    >
    >Just wanted to let everyone know that I've posted a response to Lori's April
    >2nd editorial at www.agilemodeling.com/essays/passingTheBuck.htm.
    >
    >- Scott


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