Statement 2: Agile's emphasis is on designing for current needs, not for future ones. Therefore agile methods work best when the future is unknown, and are less than optimal for projects in which future requirements are known.

a. Do you have experiences or data that confirm or refute this statement? (Briefly explain)

Partly confirms: Agile handles emerging requirements well

Ken Schwaber:

Agile is superb at handling complex requirements that need to emerge and that haven't been agreed on. Since the last system where the requirements could be stabilized at the start of the project was in 1969, this is pretty powerful. Agile gets rid of the need for bulky change management procedures and the tension between customer and developer as requirements emerge. BTW, I'm not sure if even simple systems have stable requirements since everyone changes their mind as they see a system emerge.

Refutes

Tim Mackinnon: Evidence that agile methodologies handle many aspects of the unknown.

All the projects I have worked on when the future "was known", have proved to incorrectly guess that future and things were built that in hindsight were not necessary. While you may think that rewriting an existing system is an example of a known future - I have always found that rewrites take advantage of newer application development tools, languages and best practice which all change the way that the software is written. In my experience when we have incrementally implemented something we have experience in (using XP), the result has been that the increments were completed more quickly but still required refactoring and rework. We also found that our estimates for these items were lower in the first place. It is also worth noting that there are other aspects of the unknown that are worth considering. In our team we had 3 people leave, 2 were made redundant and our CTO was in hospital for 2 months. By following XP practices none of these incidents caused the development team any problems. I could see that these are unknowns that would affect any project.

Don Wells: Agile methodologies facilitate future needs, whether known or not.

The premise is false. It is XP's stance that the best way to meet future needs is to keep the system as simple as possible for as long as possible. The best way to address future needs is to make them as cost effective to add as possible and that is addressed by not adding worthless design elements that are intended to address future needs yet don't. With the premise in dispute the conclusion is unfounded. I would say agile methods work well the future is either known or unknown. The real issue is that conventional methods fail in an environment of changing requirements; agile methods fail in an environment of disconnected team members or customer indecision.

Bill Wood: Evidence for use on stable-requirement systems.

My limited experience refutes this claim. Our initial forays into XP were to repeat a previously completed exercise, in terms of functionality, using a new process (XP) with a new programming language and a first-try at object-oriented technologies. For this project, the requirements were known entirely at the start and did not change. We found XP to be a faster, more reliable, and more enjoyable approach that resulted in more robust, more accurate, more readable, and more extendable software.

Further, my extended experience (15 years) is that very often program lifetimes are more variable than requirements change. That is, with extensive planning you are very likely to have the project canceled before any functionality is implemented.

Finally, even when future functionality is known, it is likely that the implementation of that functionality is not known, and will not be known until you get close to the actual implementation time.

The statement is flawed

Scott Ambler: Can't make a general statement about all agile methodologies.

Sounds like you've been doing a lot of XP reading lately. XP tells you not to overbuild, to have courage that you can solve tomorrow's problems tomorrow. Agile Modeling talks about the application of change cases to explore future requirements if you so desire. In short, not all the agile methods are identical, each takes a different approach.

Gary Pollice: Agility is not the defining characteristic concerning meeting future needs.

In speaking with some of the agile community, and looking at many of the success stories of XP, I’m not convinced this is true. Since requirement changes are inherent in almost all software projects, it is not just an agile issue. My experience has been that iterative development is the practice which most effectively addresses the unknown future. Most modern software methods are based upon an iterative model.

Solving today's problems is part of Agile's risk management strategy

Peter Hantos

I believe the issue is not whether the future is known or not. The difference is in the way agile methodologists define risk management. Agile teams chose to work on current needs for the sake of the time-to-market of the particular product or release they are working on. Traditional risk-based management is placing a high value on risk avoidance, although many times they fell short on developing efficient mitigation plans and contingencies. Agile teams simply feel that the effort what it would take to making those plans is redundant, because it is not serving the success of the current release.

Erdogmus & Martin:

The options theory says that if the future is known with certainty, you don't need to hedge your bets. There is a cutoff point of x% change where the 'overhead' of creating an option is equal to the benefit of having the option. XP practices seem to be designed to keep this overhead low so you get the option for free, but may incur an exercise cost when you exercise the option at some point in the future. In fact, an analysis of the YAGNI principle based on options theory (slightly deeper than the analysis in XP Explained) suggests that designing for current needs is likely to pays off only if uncertainty is high or is expected to be resolved in the long term, and the cost of change, the so-called exercise cost, is low. The assumption of low cost of change is as vital as the level of uncertainty. If requirements and technical solutions are both certain, then cost of change is irrelevant.

Moreover, in the face of technical uncertainty, making small investments is akin to a learning option, in which you can minimize your sunk cost by making small steps and conditioning the subsequent step on the outcome of the previous step.

Agile entails practices such as test-first, PP, team dynamics & communication, etc., which indeed support responding to change, but also deserve merit on their own. So agile may give you the biggest bang for the buck when the future is unknown, but could still work as good or better than a heavy-weight strategy when the future is known just because it entails practices that make sense without a great deal of overhead (PP is probably the most controversial practice from the perspective of overhead, but there is anecdotal and empirical evidence that it pays off, agile or not!).

There are many factors that might help define the problem better. These include
- degree of uncertainty, rate of change in the environment, ability to predict future
- number of agents communicating to solve the problem
- complexity of the problem (e.g., coupling between classes)
- size of the problem (e.g., number of classes)
- tolerance of solution (does a wide range of solutions tend to work?)
- balance between rate of change in the world and team velocity
- what else?

Also, that you 'know the future' may be an illusion or a habit. If you always plan using means-end analysis or decomposition and recomposition, you must know the goal. So that's your first step, create a view of the final state. How often that end state is certain and how certain is it? This is an empirical question.

b. Can you refine the statement based on your experience (e.g., does work well when the future is unknown and requirements churn is high and focus is on delivering on a time, but not when focus is on safety, works just as well for projects with clear future requirements as long as the team has significant experience with agile methods)?

Scott Ambler:

I'm not sure how not focusing on future requirements and safety are connected. If you have clear future requirements you would simply identify them, prioritize them, and implement them when needed.

Peter Hantos:

I would just leave out the second sentence, beginning with "Therefore". The whole issue of safety criticality or reliability just muddles the subject. Agile methods do not really address the problem of the majority of non-functional requirements. Many of those requirements cannot be implemented and demonstrated in a piece-meal fashion, particularly not to a customer. Ignoring them at the earlier stages for the sake of delivering frequently "working" software is an old mistake people still make many times in conventional project settings. In a nutshell, if performance, reliability, safety, exception handling, error recovery, etc. are not planned at the beginning of the project, then most likely at the end their implementation will drag out, and in many instances fail.

Randy Miller:

I believe that different agile processes have different degrees of emphasis on the future. You can always customize/adapt an agile process to deal with this continuum. Certainly, XP right out of the box is ideally suited for an environment with change. This is not to say that it cannot be used in environments with certainty.

Common sense should always dictate ones use of planning vs reacting strategies. Experience with agile processes leads to a feeling of when up-front planning is cost effective.

Gary Pollice:

I would change it to  “Agile methods are based on developing in an iterative, incremental manner. This has been shown to be effective when delivering value to the customer in a timely fashion is a primary concern.” I do not believe that all agile methods necessarily agree that designing solely for current needs is appropriate, nor a characteristic of agility.

c. Can you cite any publications that directly address this statement? (Give citations)

I believe Beck's Extreme Programming Explained addresses this issue. (Contributed by Don Wells)

Erdogmus & Martin:

A chapter in the upcoming book "XP Perspectives" by Erdogmus and Favaro addresses the options view of XP and provides an analysis of the YAGNI principle under different cost functions.

The question could be approached from the point of view of problem-solving heuristics in addition to CAS view advocated by Jim Highsmith in "Adaptive Software Development" and the options view advocated by Kent Beck in "XP Explained". There is work in AI planning on opportunistic, situated planning versus top down planning. In "How to Solve It", Princeton U. Press, mathematician George Polya lists a bunch of problem solving heuristics including specialization (make it work end-to-end for a simple version of the problem) as well as working backwards and decomposition. Usually for mathematical problems, the target theorem is known, and you are less opportunistic.

Bill Wood:

Laurie Williams' book `Pair Programming Illuminated' has some of our data. Our proposed paper, `Programming at a Research Lab: XP for Missile Nosecones?' to XP/Agile Universe will contain more data.

d. What are the implications if this statement is true? How should we change development practices to address this problem?

Scott Ambler:

Pick the right process for the job.

Erdogmus & Martin:

If the customer cannot specify the result, then upfront planning is clearly wasteful. Then go agile all the way.

If the customer can specify the result, then mix agile with plan-oriented practices to the extent that requirements are solid, technical uncertainty is low, and cost of change is high.
· The customer could judge the likelihood of changing requirements for each story. This can be driven by developers who probe the customer during iteration planning: "What if you decide to make the forms more than one page long? How likely is that?" "What if there are more than four forms? How likely is that?"
· Once the predictable parts of the system are identified, some upfront planning/design can be applied at the subsystem level.
· Another situation in which planning/design may be pay off is one of low uncertainty, but high cost of change. Then it could be best to make and freeze certain design decisions early rather than late.
· If requirements has stayed the same for a long time, all technical uncertainty has resolved, and the customer agrees requirements will not change over the life of the development, introducing planning into the process will be low risk. Also agile practices that incur overhead in order to cope with changing requirements can be scrapped.
· Once it's been decided that requirements won't change, make sure not to design for flexibility, for flexibility will no longer be needed.

Peter Hantos:

Implication: Future needs are not considered, and eventually addressed as current needs when and if the customer explicitly requests it. In my opinion it is not a viable operational mode for any company however small they are, unless they are "software mercenaries for hire". But even those companies would try to leverage their past projects, by kind of "refactoring"the process and developing core, reusable components and frameworks to accommodate a larger clientele. For example in web-business, even if the task is to develop a portal for a particular client, usually a substantial effort is made to develop and internal, standard set of tools and processes to make future projects "more agile".

Tim Mackinnon:

I am skeptical that future requirements are ever known and so would opt for agile methods.

Don Wells:

If this statement were true then agile methods would be relegated to a very narrow class of development projects.

Bill Wood:

If the statement were true, the planning game can be altered to include architectural spikes proposed by the developers. Alternatively, the developers could assign very high costs, perhaps based upon the Risk Exposure discussed in Boehm's paper, to deferring basic architectural stories. In other words, I think Agile methods can be weighted to compensate for more design if necessary.