On April 2 2003 Lori Piquet, Editor-in-chief of DevX posted an editorial entitled "Are You Passing The Requirements Buck" which gravely misrepresented a talk that I had given to the Computer History Museum at Parc Research Center in Palo Alto California on Thursday, March 27 2003.  Below are my emails in response to Lori.   Email #1 (April 3 2003) Email #2 (Afternoon, April 3 2003) Email #3 (April 4 2003)

Interesting events throughout the conversation:

• April 4: Lori adds an "Editor's Note" box to the editorial linking back to this page as she indicates in Email #2. It continues to misrepresent what AM actually says about requirements gathering.
• April 5: Lori changes the last sentence of the first paragraph to to claim that I'm now saying that requirements are solely the responsibility of business side stakeholders in the Agile Requirements essay posted at this site.  Lori finally seems to agree that I didn't say that nonsense in the presentation (apparently she had an audio recording of it, so perhaps she listened to it again).  Unfortunately her interpretation of the essay is spectacularly off track.  Please read it for yourself and make your own decision.  
• April 6: I updated this page to include emails 2 & 3 as well as this section.  I clearly had underestimated the effort of convincing Lori that she needs to rectify this situation.  I also make the decision to submit the editorial to explain to the readers of DevX what Agile Modeling (AM) is really trying to say about requirements.
• April 8.  Bryan Dollery's column, The Buck Stops Here, is published on DevX.  Bryan is a regular contributor to DevX and is basically their expert regarding agile software development.
• April 8.  My guest editorial, Agile Requirements: The Real Message, is published on DevX.
• April 17.  Bill Wohler's article, Scott Ambler: Are You Agile or are You Fragile?, is published to the SD Forum site.

As you can see from what's happened it's pretty easy to get the wrong idea regarding agile software development.  Is your organization struggling to understand or adopt agile techniques and philosophies?   If so, let us help.

Email #1:

I never said that requirements are the sole domain of business stakeholders.  Not once.  What I said was that requirements are the RESPONSIBILITY of PROJECT STAKEHOLDERS.  I went into significant detail about how developers can suggest requirements to their stakeholders if they feel the need to, in fact it's the responsibility of developers to do so and to fairly describe the issues surrounding their suggestion, and that it's the responsibility of the stakeholders to prioritize the requirement.  Yes, they may not like your suggested requirement at all, there is that risk.  Also, notice how I used the term project stakeholder, not business stakeholder.  There is more to it than just the business folks, something I also discussed in the presentation and something that I go into at the URL, www.agilemodeling.com/essays/activeStakeholderParticipation.htm, that you referenced.  Project stakeholders include business people, operations staff, support staff, IT management, senior business management, and a whole raft of others.  I also discussed in the presentation, briefly mind you, that it is reasonable to expect to have to facilitate modeling sessions.  Had you taken the time to contact me with your concerns I would have pointed you towards www.agilemodeling.com/essays/agileRequirements.htm -- its first section covers in detail the points that I've briefly touched on in this paragraph.

The frustrating thing is that I went out of my way to explain these concepts to the audience.  Remember the process that I went through for the presentation?  The approach that I took was that I tried to simulate an agile project, so I stated that I was the developer and the audience was my project stakeholders.  I started with a brief overview, about 15 minutes, describing the basics of agile software development.  I then decided to take the group through the process of identifying requirements for the project, in this case a list of "required topics" that people wanted to hear me speak about.  Remember how I started that list with 5 or 6 suggested topics that I thought were important?  In other words, the developer was suggesting requirements to the stakeholders (completely opposite of what you wrote).  We then brainstormed "required topics" for a minute or two until the flipchart page was full.  I then asked my stakeholders to prioritize the requirements by voting -- each person had three votes, and we went down the list one at a time to get a feel for the number of people that were interested in each topic.  Some of my suggestions got good voting scores, a couple didn't.  Woe is me.  It's interesting to observe that the stakeholders didn't go off on their own to define requirements, that instead I facilitated the effort (once again, completely different from what you've written).  I then went down the list, in priority order (the more votes something got, the greater the priority), "implementing the requirements" of my stakeholders by discussing the topic with the group.  The point is that what I said, and then how I acted, is completely opposite of what you've written.  Were you even in the room?

Later in your editorial you present the idea that business stakeholders are solely responsible for planning (among other things).  I'm glad that you didn't attribute this nonsense to me -- it clearly isn't an agile concept and frankly I think you'd be hard pressed to find even the most non-agile person to agree with you.  For example, the planning of my presentation was clearly a joint effort.  Both the developer (me) and the stakeholders (everyone else) suggested topics, the stakeholders prioritized them, and then we went down the list appropriately.  I even discussed, because that was one of the required topics, how new requirements would be added to the stack -- they're identified, prioritized by the stakeholders, and then put into the stack according to their priority.  The end result is that the developers are always working on the highest priority requirements.

Your editorial did make a few good points.  I do agree that it's important that developers and stakeholders work closely together, as you write about, and even seem to remember discussing that in the presentation.

I guess your editiorial is a perfect example of how communication can break down -- sitting and listening to someone talk is nowhere near as effective as talking with them face-to-face.  Had you only chosen to stick up your hand and ask a question or two during the two-hour presentation we could have avoided these misunderstandings.  Or perhaps you could have chosen to email me with your concerns, I suggested several times during the presentation that people are welcome to email me or post messages on the AM mailing list (visit www.agilemodeling.com/feedback.htm for details).  A discussion of communication is posted at www.agilemodeling.com/essays/communication.htm although I highly suggest Alistair Cockburn's book Agile Software Development (Addison Wesley 2002), a book which I pointed out during the presentation.

In short, you got it completely and utterly wrong.  Business stakeholders are not the sole source of requirements.  Business stakeholders should not go off on their own.  Business stakeholders are not solely responsible for planning.  I highly suggest you obtain the tape of the presentation that was made by the SDForum folks and have a second look at the presentation.  I was talking with the SDForum folks and they do want to digitize and put the presentation on the web, although they're currently dealing with a few technical issues.  It'll happen but may take some time.

You have gravely misrepresented what I've said and have done your readers a significant disservice.  My hope is that you recognize your responsibility to set things right.  I'll also be posting this response at www.agilemodeling.com/essays/passingTheBuck.htm. 

- Scott

Email #2:

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. 

Email #3:

NOTE: This is a continuing conversation, so some information is repeated from email #2.

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

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

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

LP: The first draft of my editorial actually had a long quote from your writings in it, which I took out in favor of the link (due to its length but also because I decided that it was more fair to you to drive the readers to your essay rather than to excerpt part of it, which would have exacerbated our current issue). The part that I was going to quote was this part:

" Your project stakeholders – direct or indirect users, managers, senior managers, operations staff members, support (help desk) staff members, testers, developers working on other systems that integrate or interact with your, and maintenance professionals – are the ONLY official source of requirements.  In fact it is the responsibility of project stakeholders to provide, clarify, specify, and prioritize requirements.  Furthermore, it is the right of project stakeholders that developers invest the time to identify and understand those requirements.  This is concept is critical to your success as an agile modeler – it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them."

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

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

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

 LP: In the next paragraph you write:

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

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

LP: You also write:

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

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

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

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

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

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

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

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

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

Scott: Great, please do so.

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

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

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

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

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