Agile... Again
Agilemodeling.com (http://www.agilemodeling.com/essays/agileRequirements.htm) has a pretty well written set of techniques for requirements gathering that I really like, however the author starts out by stating
I disagree pretty strongly with the comments.Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant). Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information. They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change. Agilists choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work.
Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains.
I simply don't think it is misguided to ask developers to understand what needs to be built and to build it to a specification. The developers we work with are professionals. They take part in the requirements definition and absolutely develop what is agreed upon.
The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it,
A requirements document can never completely specify a system. However for the highest risk areas, getting all parties to agree on the way the system should work is crucial. The easiest way to ensure that all items are reviewed is by using a list in the form of requirements. If you have a small project maybe you don't need this, but for the projects we work on with many stakeholders it is absolutely critical.
the requirements change anyway,
We have found that true requirements don't change often at all, in the same way that true business needs don't change that often. If you find that your requirements are changing a lot, then you probably did not define the right requirements originally or maybe you incorporated too much design.
and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant).
When the stakeholder/user population is large, I think we would all agree that this method does not work. It can take a significant amount of time to distill what actually needs to be done on large projects. Most developers lack the facilitation skills to drive these conversations.
Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information.
This comment simply doesn't make sense. The key question is when do you actually need the information? Well if you have multiple business stakeholders who have to come to agreement on how something should work, you would want the information as early as possible because you simply don't know how long it may take to get agreement. Simply put, why wouldn't you plan up front?
This wait until the last minute philosophy of Agile fits right into the personality of many developers. It is the same philosophy that drives most people to procrastinate. Planning is hard work, but there is no doubt in my mind that using detailed planning is the right method to run a software project.
posted by Anthony C. at 7/26/2006 10:20:00 PM
2 Comments:
I've heard (well, read, actually) some people refer to JEDI - Just Enough Design Initially - as a shorthand way to state the goal of defining enough requirements up front to understand the goal of the project, without going beyond the point of diminishing returns in attempting to predict the final end state of the product in great detail. I think that's basically what most of us are interested in doing.
Unfortunately, many debates or arguments about requirements and agile methods seem to consist of taking someone's comments to an absurd extreme and then denouncing the extreme, rather than what the person actually said. This approach doesn't strike me as particularly useful.
For example, you take issue with the statement,
>Many traditional project teams run into trouble when they try to define all of the requirements up front...
by saying
>I simply don't think it is misguided to ask developers to understand what needs to be built and to build it to a specification.
Obviously, the original author expressed nothing at all resembling the point of view you dispute in your comment. As far as I can see, you're both right. It's definitely not misguided to ask developers to understand what needs to be built. It's also perfectly true that when people try to define all the requirements up front (that is, in full detail), they will miss the mark.
You go on to say,
>They take part in the requirements definition and absolutely develop what is agreed upon.
If you mean to say this process occurs once at the start of a project, with the goal of creating definitive requirements for the entire project, then it sounds like the traditional approach to software development in which we build to satisfy a contract and then expect the customer to be "happy" with (or at least, pay for) a solution that matches the terms of the contract, no matter what their true needs turn out to be. In the context of agile development, it is a process that is repeated at the start of every iteration, with the goal of finalizing requirements for the particular iteration, so that we keep development on course with the customer's changing understanding of their needs.
The agile approach does not call for building solutions without any specifications, as you seem to imply, but simply acknowledges the fact that customers don't know everything about the problem space or the optimal solution in advance. They have a vision of where they want to go, but many of the details must be discovered along the way. That's where iterative development and incremental delivery come in. At no time has anyone suggested that development not be based on any sort of requirements elaboration.
>However for the highest risk areas, getting all parties to agree on the way the system should work is crucial.
Right. And who has said otherwise? Who are you arguing against, here? An adaptive approach tends to help keep things on track better than a predictive approach, thus addressing the highest risk areas in the lowest risk manner.
>We have found that true requirements don't change often at all...
The "big picture" vision of where the organization needs to go doesn't change (much). The detailed requirements change radically in the course of any project. The larger, more complex, and more lengthy the project, the more the details are subject to change.
>...or maybe you incorporated too much design.
Yeah, maybe. JEDI?
>When the stakeholder/user population is large, I think we would all agree that this method [approaching stakeholders directly] does not work.
I wonder. Even in a large, complex project undertaken for a sizeable enterprise, the number of key stakeholders rarely exceeds a handful. When you approach "any" stakeholder directly to ask for clarification of a requirement, the typical answer is something along these lines: "Well, I think it's supposed to be X, but I have to verify that with Mary." Before long you discover that all roads lead to Mary. Hmm. How many stakeholders are there who matter with respect to clarifying requirements?
It's true on one level to say that everyone who will use the new system and everyone connected with systems that take data from the new system is a "stakeholder." For purposes of clarifying requirements, it's not true that every one of those people is really a "stakeholder" because only a few of them have any decision-making power. The rest are stakeholders only in the sense that a leaf is a stakeholder of the wind.
Hence, you have not achieved universal agreement that this method does not work. It all comes down to people, in the end. When the documented requirements are unclear or incomplete, you must have a definitive answer. The most expedient way to get one is to ask the right person directly.
>This comment simply doesn't make sense. The key question is when do you actually need the information? ...you would want the information as early as possible because you simply don't know how long it may take to get agreement.
The concrete answer to this question depends on the circumstances in each case. The general answer is that you actually need the information at the closest possible point in time that a decision is required. You don't need the information as early as possible, because by the time you need to use the information it will be stale. Even if, as you say, the true requirements don't change all that much, it is certain that the stakeholder's understanding of the problem and the way they express their needs will change. If they have seen partial results (thanks to incremental delivery) and they have been participating actively throughout the process (thanks to iterative development), then when a decision point is imminent they will be in a good position to provide accurate information to inform that decision. Two years prior, can they really tell you what the detailed requirement should be?
If the primary reason you want to get those answers early is that you're having trouble reaching agreement among stakeholders, your problem is something other than requirements elaboration as such. It sounds like a political issue.
>Simply put, why wouldn't you plan up front?
Who are you asking? I have never heard of anyone who believes you wouldn't plan up front. You are arguing with a strawman.
>This wait until the last minute philosophy of Agile fits right into the personality of many developers. It is the same philosophy that drives most people to procrastinate.
Tell that to Toyota. They seem to be doing well with their system of deferring decisions until the last minute.
I think Dave's comments are right on target.
My comments on the role of product management in an agile environment are in today's blog entry.
Post a Comment
<< Home