n April 2, 2003 Lori Piquet, DevX’s Editor-In-Chief, wrote an editorial titled “Are You Passing The Requirements Buck?.” The editorial discussed both a presentation that I had given for the Computer History Museum at Parc Research Center in Palo Alto California on Thursday, March 27 2003 and a portion of my writings regarding agile requirements at the Agile Modeling (AM) site. Several people concerned with what Lori had written brought the editorial to my attention. I read the piece, which in both my opinion and that of others, gravely misrepresented views which I have held and written about for years. Lori and I began communicating via email, the bulk of it is posted in the DevX discussion forum and at my page, during which she offered me the opportunity to clarify how requirements really work on an agile project. So here we are.

Project Stakeholders
Let’s start by discussing the concept of project stakeholders. My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, support (help desk) staff member, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.

From this definition you can see that business people, such as direct users and their managers, aren’t the only stakeholders of a project. As you know there is a wide range of people potentially affected by a new system, therefore to succeed you must understand and then synthesize their requirements into a cohesive vision. This is one of the things that make software development hardproject stakeholders will each have their own requirements, their own vision, and their own prioritiesbut it also makes software development fun.

In this definition I have chosen to exclude the developers who are working on the project. This may seem strange at first because developers clearly have an important stake in the projects that they work on. Yet, developers are definitely project stakeholders. Why do I continue to distinguish between developers and project stakeholders? Because I want convenient terms to distinguish them, I really don’t like the terms “developer stakeholder” and “non-developer stakeholder.” More importantly, developers and project stakeholders have different roles to play on a project.

My definition of project stakeholder and developer may be different than yours, or perhaps you prefer different terms. For example, the XP community discusses the concepts of customer and programmer, not project stakeholder and developer, and have slightly different definitions because they use the terms differently than AM does.

A Bill of Rights and Responsibilities
I used to talk about the rights and responsibilities of project stakeholders, a concept that I adopted from Karl Wiegers excellent book entitled Software Requirements. Unfortunately, I recently discovered as a result of writing this editorial that this explanations of rights and responsibilities weren’t as clear as I had originally thought, and were potentially even divisive. The frustrating thing was that the original version of the bill of rights and responsibilities had been online for over two years. Late feedback is still good feedback I guess.

So, I’ve decided to rework them more along the lines of eXtreme Programming (XP)’s concept of programmer (developer) and customer (stakeholder) rights. In fact I’ve combined Wieger’s advice with that of the XP community to identify the rights and responsibilities pertinent to making AM a success.

Everyone’s Rights:

1. To be treated with respect.
2. To produce and receive quality work at all times based on agreed to project standards and principles.
3. To estimate the time and cost of activities with which you are actively involved, and to have those estimates respected by others.
4. To receive adequate resources (time, money, etc.) to do the job that’s been asked of you.
5. To determine how resources will be invested. People funding the project have the right to determine how funds will be spent. People working on the project (e.g. investing time) have the right to determine which tasks they choose to work on.
6. To be given the opportunity to gain the knowledge pertinent to making the project a success. Business people will likely need to learn about the underlying technologies/techniques and technical staff to learn about the business.
7. To have decisions made in a timely manner.
8. To receive good-faith information in a timely manner. Sometimes this is just the “best guess” at the time, and that’s perfectly all right. This includes business and technical information.
9. To own your organization’s software processes, following and actively improving these processes when needed.

Everyone’s Responsibilities:

1. To produce a system that best meets your needs within the resources that you are willing to invest in it.
2. To be willing to work with others, particularly those outside your chosen specialties.
3. To share all information, including “work in progress”.
4. To actively expand your knowledge and skillset.

When you consider these rights and responsibilities out of context, it’s plausible that you can misinterpret their implication. This is why it is important to recognize the need for developers and project stakeholders need to work together effectively, ideally in an agile manner.

Working Together
When you are requirements modeling a critical practice is Active Stakeholder Participation. There are two issues that need to be addressed to enable this practice?availability of project stakeholders to provide requirements and everyone’s willingness to work together. What does it mean for a project stakeholder to actively participate? On an agile project both project stakeholders and developers are involved with identifying ideas or suggestions, discussing a potential requirement, and then modeling and potentially documenting it. Project stakeholders are solely responsible for prioritizing requirements?the system is being built for them therefore they are the ones that should set the priorities. Likewise, developers are primarily responsible for estimating the effort to implement a requirement because they are the ones that will be doing the actual work?it isn’t fair nor is it advisable to externally impose estimates.

On an agile software project developers are free to suggest as many requirements as they like. However, because stakeholders are responsible for prioritizing requirements the developers need to be able to justify their suggestions. If the developers do a poor job of this, or if the suggestions just aren’t deemed important to the stakeholders, then the suggestions will be given low priority and will be addressed late in the project, if at all. On the other hand, if developers make a good case for their suggested requirements then the project stakeholders are free to assign a very high priority to the idea.

Is this a recipe for disaster? In some cases, yes, the project team could in fact go astray. The reality is that no approach is perfect, projects that take a traditional “big requirements up front” approach can also fail. The important thing is that everyone strives to do their jobs effectively. Developers should make any suggestion they feel is appropriate, should provide sufficient information regarding the trade-offs, and then respect the decision of the project stakeholders. The stakeholders should consider the suggestion, including the supporting information, and then make the best decision that they can. Sometimes that will be the “wrong” decision; nobody is perfect.

Why does this make sense? Because it’s the money of the project stakeholders that is being invested in the project, therefore they should have a say in how it’s spent. Yes, things could go very wrong and they might decide against your one of your suggestions and it may take months or years to discover that they’ve made the wrong decision. It will also be their money that is spent to fix the resulting problems. Life can be very harsh that way.

On an agile software project developers are responsible for providing accurate estimates for the tasks that they’re to work on. If your stakeholders don’t like these estimates they are free to rework their requirements and then to ask you to re-estimate. “Oh, I didn’t realize this was going to cost $40,000. What can I get for $10,000” is a perfectly reasonable request.

This points to another important concept?agile software development is evolutionary in nature (it’s iterative and incremental). Although ideally project stakeholders should provide specific and precise requirements, the reality is that they very likely can’t do it at first. Lori wrote that it’s unreasonable to expect stakeholders to know what they want or to expect them to have the skills to define it. I completely agree, which is why developers and project stakeholders need to work closely together. I like to use the analogy of decorating a living room. You can never get it right the first time, you’ll always step back and realize that the couch needs to move a little to the left, that the television needs to be angled differently because of incoming sunlight, and so on. So you make some changes, evaluate, make a few more changes, and so on. Eventually you have a specific and precise idea of the way that you want your living room to be organized right now. Well, it’s pretty safe to say that software development is several orders of magnitude more complex that decorating a living room, so if you can’t get the living room right on the first try it’s spectacularly na?ve to think that you’ll get your software requirements defined right on the first attempt. It’s realistic, however, to expect you to take an evolutionary approach to exploring your requirements, and the principles and practices of AM can help you to do this.

Learning Agile Software Development Techniques
Why have I invested so much time to address Lori’s editorial? Because there is the real potential that many people could read it and get the wrong idea about agile software development. There is a significant amount of information available to you on the Web and it’s very hard to determine which you should pay attention to and which you should ignore. This is particularly difficult when you’re first learning about agility because you typically don’t have the background to distinguish the good from the bad. A great resource is the Agile Alliance site because it links to a wide array of good articles. You might find my thoughts posted in the article “Becoming Agile?” to be of help.

I’m going to leave you with the following words of advice:

1. Be skeptical. You should always question what you hear and read, including both the articles for agile software development and against it. Think for yourself.
2. Be realistic. Don’t expect one single answer. There are many voices within the agile community, and different people are addressing different situations. In short, one process size does not fit all.
3. Be skeptical. Question the people who criticize agile software development. There’s nothing wrong with criticism, but make sure it’s based on reality. I’ve noticed that whenever someone tells you about “the serious problem” with an agile technique that they often have never even tried it. Sometimes I discover that haven’t even looked into it sufficientlyI’ve lost track of the number of times I’ve met people that criticize XP only to discover they haven’t even read one of the many books written about it. Instead of blindly accepting the criticisms you are much better off if you go to the source and formulate your own opinion. For example, there is a difference of night and day between what Lori wrote in “Are You Passing The Buck?” and what I wrote in “Agile Requirements.” Unfortunately many people who are looking for an excuse to not adopt agile techniques will stop reading once they find Lori’s original editorial. The same could happen with someone who mistakenly equates agility with “code and fix” development?chances are pretty good that Lori’s characterization of my writings sound an awful lot like a bad experience they may have had in the past.
4. Be willing to try it for yourself. You won’t know if a technique will work for you unless you give it an honest try.
5. Be skeptical. As you learn about agile software development you will naturally have questions and concerns about it. That’s perfectly normal. The Agile Modeling (AM) mailing list is one very good forum for discussing your reservations. Open and honest communication is the name of the game.

I’d like to thank Lori Piquet for giving me the opportunity to tell my side of the story. Few people would have the integrity to do that. I’d also like to thank Chris Britton, Larry Brunelle, Ian Chamberlain, Tales Costa, Dale Emery, Del Hager, Ron Jeffries, Jon Kern, Colin McDowell, Ashley McNeile, Les Munday, Charlie Poole, C. Keith Ray, Pete C. Ruth, Mark Sumner, Paul Tiseo, and anyone that I may have missed for their feedback on the Agile Modeling mailing list which I have incorporated into this guest editorial.