Are You Passing the Requirements Buck?

[Scott Ambler]

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

[Jon Kern]

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>

[Bill Wohler]

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.

[Lori Piquet]

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

[Scott Ambler]

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.

[Mike Mitchell]

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

[snipped all, because totally unreadable]

MM

[Bill Wohler]

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.

[Scott Ambler]

"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

[T. Hoskins]

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.

[Rob Abbe]

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