In the final analysis, the critical success factor for any method—Agile or otherwise—remains whether or not it helps deliver customer value. Furthermore, we the technology developers don't get to determine value, our customers do. Whether an internal IT customer uses an application to cut costs or a retail customer buys a software package, ultimately customers buy our products—or they don't. It's just as simple, or as complex, as that. A group of the Agile Manifesto authors were concerned that this “satisfy the customer” principle was too obvious, that everyone espouses a similar principle, and therefore it didn't help differentiate Agile Software Development Ecosystems (ASDEs) from Rigorous Software Methodologies (RSMs). However, the overriding issue turned out to be that a customer value statement declares an external focus rather than an internal one. Without this explicit statement, even if it appears obvious, development teams tend to be overly introspective. The levels of the Software Engineering Institute's Capability Maturity Model (CMM), for example, are not based on results, but on the implementation of certain sets of practices (called key practice areas, or KPAs). The underlying assumption—good processes lead to good results—is both a questionable assumption and one that leads to too much introspection about process and too little focus on actual results.

This concern about customer satisfaction as a principle leads to another question: “What does separate Agile from rigorous approaches to delivering value?” I think the key issues are that the customers are in control and the relationship must be a collaborative partnership. The subtle, and sometimes not so subtle, message of RSMs is that once the requirements specifications and project plans are completed, the technical development team takes over control. Small changes are acceptable (after review by a change control board) but RSMs' primary objective is to conform to the plan—to deliver a succession of artifacts, not working software.

RSMs have often led to lack of accountability on the part of both customers and developers. Developers claim, “They signed off on the specifications,” and the customers counter, “Yes, but we didn't understand all that technical mumbo jumbo—the results aren't what we wanted.” Both parties fulfill the prescribed plan, process, and approvals but fail to be accountable for real results.

RSMs have also led to token relationships in which developers involve the customers but retain control. Development teams encourage customers to get involved (developing requirements or writing test cases, for example) but maintain control through the mechanism of “The Plan,” which the customers don't understand because it's laced with hundreds of tasks that sound to them like “develop a bumfizzle document” and “provide a gruelsniffle.”

Agile approaches present a different, and sometimes scary, scenario to customers. The process is such that the customer is in control throughout the project. Every iteration, the customer gets to change priorities based on features delivered, features wanted next, and changes requested from previous iterations. The development team's responsibility is to inform the customers what the impact on cost and schedule will be and to present alternatives that might be faster or lower cost, but in the end, the customers are in control.

Shifting control is scary—for both developers and customers. If I'm a customer and I know that I'm ultimately responsible for the results, I've got to stay closely involved. If I'm a developer and the customer keeps changing the features to be developed, I have a difficult time measuring progress (at least in the traditional manner) because the product is constantly changing. Scariest of all, developers and customers have to trust each other and trust in each other's competence.

Although the customers should be in control, this principle does not, and should not, relieve development teams of being proactive about recommending features (or user interfaces, integration schemes, design enhancements, and other possibilities). Agility has both reactive and proactive components. Customers want to buy two basic things from software providers—technology knowledge and domain knowledge. If a company were selecting a software firm to develop customer relationship management (CRM) software, and it had two bids from firms with equivalent technical knowledge but one had extensive CRM knowledge as well, which one should the company pick? If software development were a reactive activity only—the customer provides feature requirements and developers implement them—the selection should be a toss-up. But, of course, it is not a toss-up. Clearly the second firm, with the CRM experience, would be preferable.

In a recent workshop, a project manager was questioning the feature approach to iterative planning. “But aren't requirements specifications and architecture documents important?” he asked. “Yes,” I replied, “they are important, but what we have to understand is that customers don't care—about documents, UML diagrams, or legacy integration. What customers care about is whether or not you are delivering something useful to them every development cycle—some piece of business functionality that proves to them that the evolving software application serves their business needs.”

One last aspect of delivering customer value is time to market. While speed may not be the only component of value, it will certainly remain critical. RAD methods arose in the early 1990s as a way of increasing the speed of software development, which had often slowed to near reverse during the information engineering era. From a methodology perspective, ASDEs draw from both the heritage of effective software engineering techniques and what RAD projects taught us about short iterative cycles, working closely with customers, and effective teaming practices.

There are two assumptions about customers that lurk just beneath the surface for many technologists: that customers don't know what they want and that they are shortsighted. The extensions to these assumptions—“The customers don't know, but we do” and “The customers are shortsighted, so we'd better do the long-term planning for them”—turn out to be very dangerous, particularly in an exploratory project. Many RSMs are built on the assumption that the customers don't know what they want, so the developers want a detailed specification so they can absolve themselves of responsibility: “I built what you put in the specification” is a common excuse. Requirements processes are important, but how we view the customer is critical. Agile practices are based on the belief that neither the customers nor the developers have full knowledge in the beginning and that the important consideration is having practices that will allow both to learn and evolve as that knowledge is gained—without ongoing recrimination.

The second dangerous assumption is that the customers are shortsighted, and therefore we (the developers) must build in extra features and extra data so that when the customers finally get a clue, we're already ahead of them. This assumption leads to overdesigned databases, class structures, and cross-application integration schemes that attempt to solve future problems. Many of these “extras” are done in the spirit of future “flexibility.” Part of being change tolerant is having the conviction—and the development and design practices to back it up—that we are more capable of responding to future changes when they occur than we are of predicting those changes today.

This should not imply that there is anything wrong with designing a database for cross-application integration; however, it should be designated as a feature and prioritized by the customer. If we can't sell it to the customer, it shouldn't be done. There was a series of emails on a recent discussion group that addressed this issue. One particularly relevant response came from Ron Jeffries, responding to the need (or lack thereof) to build standard application programming interfaces (APIs).

How many millions of dollars have been wasted on projects because developers have patronized customers—putting in “stuff” because they thought the customers weren't smart enough to know they were going to need it in the future? These thoughts may not be expressed, but they lurk underneath the surface in development organizations. Read carefully what Ron says: He “tries” to get the customer to think about integration issues but doesn't make the decision. Many people might say that an integration decision is a technical decision, but integration is a feature, and it should be driven by customers' needs. If they want quick-and-dirty, and we've pointed out the negative long-term impact, and they insist on quick-and-dirty—give it to them. (“Dirty” here refers to lack of integration, not defects.)

Now, there may be a number of issues surrounding how customer decisions are generated—single on-site customer, consensus from a focus group, executive sponsor—but ultimately the customer needs to make decisions about features and functionality. It is a development team's professional responsibility to provide information about the advisability of the decision, but not to make the decision.

Sam tells the story about visiting with both the CEO/founder and the president of a small high-tech company (Bayer 2001). He was trying to convince the company to use focus groups to enhance its understanding of customer needs. In the first meeting, the founder (the technology guru) responded somewhat indignantly, “We've been doing this for five years. We know exactly what our customers want.” He went on to articulate a list of the product's technology features. Later, in a meeting with the president of the firm, Sam learned that the president didn't think the company knew either who its customers were or why they bought the company's product.

Listening to the voice of the customer is the most difficult task in product development. Building a partnership of shared responsibility, giving customers control over features and priorities, spending enough time in conversation to understand business processes and the customer's real problems—these are the linchpins of Agile development.

Satisfying the customer through continuous delivery of valuable software is not an easy task. At HAHT, implementing focus groups took the energy and drive of Sam Bayer. Finding the voice of the customer doesn't come easy. Getting the right users on a project can be difficult. Delivering something useful, delivering a product that creates value for customers of software products—whether commercial, PC, or internal IT software—begins with practices that create effective working relationships between development staffs and their customers.

Long ago and far away, in my heavy methodology days before enlightenment, I was delivering a seminar on structured analysis and design. The whiteboards were filled with data models, data flow diagrams, and process specifications from four long days. At this point I turned to the group—consisting of analysts and programmers—and asked, “Now, you know how to code from these diagrams, right?” The blank stares informed me that they didn't have a clue, so I then began writing code blocks on the board and drawing lines back to the locations where the information came from on the model diagrams. I could see the lights begin to go on in people's heads.

I took a profound lesson away from that experience: If software developers couldn't relate models to code, how in the world were nontechnical customers going to relate models to a finished application? The debates have raged for twenty-plus years about which form of system model—data flow diagrams, data models, object models, and so on—are most understandable to users. And the answer is: none of the above. Users relate to the real thing and the real thing only. Paper mock-ups and visual prototypes do serve as effective intermediate markers at times, but real progress is demonstrated only by working software.

The principle “working software is the primary measure of progress” caused intense discussion among the Agile Manifesto authors. Questions ranged from what the term “working software” meant and whether it included prototypes and models to whether working software was the only measure and who got to measure. If we can't show demonstrable, tangible progress to the customer, then we don't really know if we are making progress. Data models, UML diagrams, requirements documents, use cases, or test plans may be markers that indicate some degree of progress (or at least activity), but these markers are not primary measures. Features that implement a portion of a business process, features that demonstrate that a piece of flight avionics software actually drives the required actuators, features that allow a doctor to extract and view a digitized CT scan—these are primary measures. Nothing else qualifies.

The principle doesn't say “compiled binary executable,” it says “working software.” If working software can be generated completely from models, then the delay between artifacts (models) and working software approaches that encountered between compiler input and compiler output. If we develop a set of UML diagrams but converting those diagrams to tested code takes weeks, then the diagrams (models) do not constitute a primary measure of progress. Similarly, although DSDM uses prototypes, in practice this usage has gravitated toward the definition of a working portion of the application rather than a throwaway prototype. Time-driven projects don't have time for throwaway prototypes.

Good project managers have always strived to base milestones on verifiable deliverables—end products rather than intermediate markers of progress. Traditional software life cycles, however, have placed far too much emphasis on intermediate markers such as diagrams and documents. ASDEs are the third wave of software development practices. The first wave was the ad hoc wave, in which the software itself was in fact the measure of progress. Because software development was in its infancy and making major changes was costly, a panoply of intermediate markers—designed to reduce the cost of errors—arose. This second wave sought to reduce the cost of change by eliminating it. Unfortunately, the primary focus became these intermediate markers, not the working software. As the third wave unfolds, as tools and practices reduce the cost of change, we return to the principle of working software as the primary measure of success.

The fastest development cycle I've run across was in a project managed by a Philadelphia-based software firm. For an Internet project with a large customer base and a very short delivery schedule, this company delivered a new iteration of its product every day to more than 100 users. Given the extremely short time frame for the project and the degree of requirements change, getting daily feedback from the customers was absolutely critical to the company's success.

For many years now, process gurus have been recommending an incremental or iterative style of software development with ever-growing functionality. While this still seems to be less common in the wider world of software development, iterations are characteristic of all Agile projects.

However, “deliver” is not the same as “release.” Business people may have valid reasons for not putting code into production every couple of weeks. They may want longer cycles to allow time for training, or they may not want to spend time retraining for frequent releases. They may not find enough functionality in the early increments to be worth deploying. Projects may not reach a critical mass of functionality for a year. Still, that shouldn't stop a rapid cycle of internal deliveries that allows everyone to see what's happening and enables constant learning from a growing product.

Frequent delivery benefits both the customers and the development team. The “frequent delivery” and “working software” principles work in conjunction with each other. Neither frequent delivery of documents nor infrequent delivery of working software conforms to Agile principles. Developers may feel that frequent delivery, especially when it involves practices such as focus groups, is disruptive and involves needless overhead. Customers may resent the intrusion into their busy schedules. But volatile projects can careen off course quickly. Developers begin assuming too much, customers become complacent, and the results can be disastrous.

There is an old project management adage that “bad news gets worse with age.” A corollary to this adage might be that “poor features get worse with customer neglect.” By the time the members of a development team have worked on a feature set for two or three months or longer, they begin to take “ownership” of those features and form natural ego attachments. Customers, cut off from seeing results, lose track of development efforts and have a tendency toward excess criticism when they do see results. Monthly customer reviews build partnerships. Quarterly reviews are apt to contribute to adversarial relationships.

It's ironic that the more sheer joy and satisfaction we get from our technical work, the easier it is to get distracted from delivering what the customer wants. One of the marvelous attributes of the three extremoes—Ward, Kent, and Ron—is that they are consummate programmers dedicated to high-quality, nonsmelly code, while at the same time they are laser focused on delivering customer value. It's a rare combination.

The other key differentiator between Agile and rigorous approaches is the emphasis on collaborative partnerships. At a talk before a large financial institution, I discussed the principle of daily interaction between the development team and the customer. One project manager in the audience stood up and explained how that would be impossible in his company since they rarely saw customers and the customers wouldn't stand for such a time commitment. The response was simple: Don't do exploratory projects or use Agile practices with this client. All methodologies recommend customer involvement in projects, but Agile practices and principles insist on the customer's taking control and being constantly involved.

Agilists don't expect a detailed set of requirements to be signed off at the beginning of the project; rather, we anticipate a high-level view of requirements that is subject to frequent change. Clearly, this is not enough to design and code, so the gap is closed with frequent interaction between the business people and the developers. The frequency of this contact often surprises people. The word “daily” is in the principle to emphasize the software customer's continuing commitment to actively take part in, and indeed take joint responsibility for, the software product.

Years of research studies show that user involvement in projects ranks first or second in importance to project success. Gathering requirements continues to be one of the most difficult challenges of software development. The fact that there are books and conferences devoted to requirements analysis tells us that it's hard and, whatever techniques are used, it will still be very hard to write down everything customers want and expect before beginning work.

During the 1980s, I facilitated dozens of requirements gathering (JAD) sessions for companies. Although they were usually effective in gathering requirements, it wasn't until the early 1990s, when I began combining these sessions with frequent delivery of working software, that customers began showing real enthusiasm for working with development teams on an on going basis. Working together daily and frequent delivery of software work conjointly to build customer-developer partnerships. Without working closely, the wrong requirements get implemented, and without frequent delivery, customers lose the incentive to work with developers.

Finally, does “daily” really mean daily? There was debate among the Manifesto authors over whether to substitute “frequently” for “daily,” and I think we kept the right word. Of course absolute adherence to a daily schedule may not always work. Working together daily may mean for a couple of hours each morning rather than all day, and it may mean skipping days now and then. However, when daily begins slipping to every other day, and then to once a week, results will suffer accordingly, particularly if time to market is a driver.

In order to better understand the relationship between customers and developers, let's postulate the equivalent to an API—we could call it a customer-developer interface. Now, for a small (less than ten people), colocated team of developers, what would be the simplest interface that could possibly work? First, the role of customer would be played by a single on-site customer, per XP. Second, the “parameters” that would need to pass back and forth across the interface would be a product vision, a set of identified features, a prioritization of those features (which ones to work on in the next iteration), a set of conversations around those features and prioritization decisions, and acceptance tests. Developers need to know what features are required, and then they need to understand the features. Several conversations, and minimal documentation, may be required to accomplish that understanding. The customer needs to have information with which he or she can make tradeoff decisions—from user interface design to feature alternatives.

The above could be considered the simplest form of a customer-developer interface. Furthermore, no matter how many individuals are on the customer “team” or the development “team,” the requirements for the interface remain the same. Now let's ask the question, “What is the simplest thing that will possibly work if the customer side of the interface includes two different departments (sales and order processing), each with several different users?” In this case, the interface remains the same—vision, features, priorities, conversations, and acceptance—but the single on-site user becomes a group of users whose ideas must be gathered and massaged. Now, if we are dealing with a group rather than an idealized on-site user, then the task is to make the output of the group mirror the output of the single user, which is what practices such as facilitated workshops and customer focus groups are designed to accomplish.

XP recommends having an on-site customer. ASD recommends having a customer available for conversations each day. Crystal Clear discusses frequent user interaction. What happens, though, when the number of users (or user departments) grows to 3 or 4 or 50 or 75 million (as in the case of Microsoft consumer products)? Obviously, the XP-specific practice of an on-site customer doesn't scale, but what if we interpret the practice as a single instance (small, colocated team) of an interface? I would argue that no matter the number of customers or developers, the interface itself remains stable.

If we had four user departments and 50 users, we might use a requirements gathering group session (often referred to as a JAD) to create a product vision statement, identify the features on story cards (XP), develop low-precision use cases (Crystal), and develop a backlog (Scrum's prioritized feature list). Some prioritization process such as multi-voting among the user community would also be necessary. As each feature entered development, selected users would be asked to have “conversations” with developers to further articulate requirements. At the end of each iteration, the development team might conduct acceptance tests (XP) and a focus group (ASD) to get appropriate feedback from the original user group. As the number of users increasd, these additional practices would be brought into play, but only as absolutely needed—that is, after determining the simplest set of practices that will fulfill the needs of the interface.

Many people think that internal IT-based products and commercial products are different when it comes to working with customers. However, the fundamental problem is the same—at some point there are inevitably “proxy” users inserted between the developers and the actual users. For internal products, these people are often business analysts or systems analysts. Their job is to work with tens to hundreds of users (actual users, executive sponsors, business functional experts, and others) in order to create the information flow required by the developers. Unfortunately, the conversations—in which the most important information resides—suffer from the proxies' translations. Proxies don't have the depth of knowledge that actual users have, and the problem is compounded because the proxies are overly prone to substitute documentation for conversations.

Similarly, the “proxy” roles in commercial software firms have titles such as product manager, marketing analyst, and program manager. Regardless of the role, they are still proxy users. In some situations—with consumer products like Microsoft Office—there may be several layers of proxy users. Although proxy users are necessary in certain situations, they always cause information to be skewed. That's why consumer software product companies employ usability labs to occasionally get the pulse of the real customers. That's why companies like HAHT use periodic customer focus group sessions.

The biggest problem with proxies comes when they begin to believe that they actually are the customers, and in particular, when they use this belief to block direct contact between developers and real customers. Now, having 75 million customers visit a developer's office may not be feasible, but having the developers view a customer in a usability lab may be. Having 50 users working side by side with a development team may not be feasible, but having 10 to 12 of them in a focus group may be feasible—and very useful.

I've seen systems analysts intervene to stop users from directly talking with in-house developers, and I've been around product marketing managers who took the position that “they” knew what the customers wanted and development shouldn't worry. I've seen program managers (the specification gatherers often situated between marketing and development) who thought requirements should be a linear flow from customer to marketing to product management to development—with no feedback from development.

Having conversations is difficult enough; proxies tend to make the problem worse. They serve a valuable and necessary function, but they can't forget that their most important job is not feature identification or prioritization but the conversations that transfer key knowledge back and forth between the actual customers and the development team.

Ten or 15 years ago, a customer (again, either internal or external) could walk into an IT manager's office, spend 30 minutes outlining his or her problem, and expect results with minimal further interaction. Even though the lack of customer involvement was a recognized problem (and many projects failed because of it), a surprising number of projects succeeded with minimal involvement. Why? In many instances the IT analysts and developers or the external consultants had enough domain knowledge to enable them to fill in the gaps. In prior years, development teams asked for customer involvement, didn't get it, and got the job done anyway—at least often enough that we convinced customers that their involvement wasn't as important as we kept telling them.

With new business models, with eCommerce and eBusiness, IT professionals are less able to bridge the domain knowledge gap. This means that continuous customer involvement is no longer merely an option, it's mandatory. If we don't build effective collaborative relationships with customers, no amount of contract negotiation or change order processing will bring success. When no one has the answers in the beginning, the cost of learning has to be shared. If both parties fail to understand the nature of the turbulence, if they don't understand that constant change is the name of the game, if they don't understand that consistent joint decision making and tradeoffs are required, then the chances of ending up with a satisfied customer are Lilliputian.

The best developers have knowledge of the customer's domain. While, in theory, the customer-developer interface just described should work with customers who possess all the problem domain knowledge and developers who have all the technical knowledge, in reality, developers with domain knowledge reduce the level of conversation required and the rework from misinterpretations. In the past year, I've worked with software groups whose “customers” are income tax specialists, geophysicists, physicists, biologists, bank ing and financial specialists, eCommerce retailers, and cell-phone chip experts. If these groups had no knowledge of problem domains, their software development efforts would be noticeably poorer and markedly more time consuming. Having domain knowledge, they can understand the terminology used by the customers, recommend features based on their knowledge, and even use their own experience to fill in detail-level requirements gaps.

Although the best practice may be to have a user readily available to the development team, it is not always possible within large, multi-national corporations. Although the best practice may be to have customers make all feature and priority decisions, there are situations in which the development team may inject its own ideas. Business and systems analysts fulfill a vital role on development teams—they possess valuable domain knowledge. Development teams shouldn't take an arrogant, “we know best” attitude, but neither should they take a “customers know everything” one.

The critical point is that customers should

Customers should be heavily involved, as every product development process needs an external reviewer. However, this should not preclude development staffs from using their domain knowledge to make significant contributions to features and functionality.

An API operates between programs—it should be concrete and standardized. A customer-developer interface isn't the same—there should be room for fuzziness to fit the variations among individual customers and developers. We want to forge a collaborative bond between customers and developers, not a different kind of wall. If we attempt to wall development teams off from the reality and turbulence of the real world, Agile approaches will be no more successful than traditional ones. We need collaboration, accountability, and definition of roles defined by an interface, but we also need to be adaptable to actual conditions within companies.

In many organizations, manufacturing and sales departments still play the traditional sales forecasting game. Sales departments make product sales forecasts. Since sales people are traditionally optimistic, manufacturing personnel (having been burned with excess inventory in the past) then reduce the sales forecasts by some percentage. Obviously, the sales staff know this and therefore bump forecasts up by an offsetting percentage. So, everyone understands that everyone else is lying (well, fudging the truth) so the battle of phantom numbers escalates unabated until no one has a clue about reality—until earnings reports arrive. Early generations of manufacturing resource planning (MRP) systems floundered on this political reality.

There are two strategies for “fixing” this type of problem. Strategy number one is to constantly cajole everyone involved to “play nice.” This is a poor long-term strategy given human nature, although trying to get everyone to be honest does help. The second strategy, more radical to be sure, is to alter the entire game. Rather than forecast demand, respond to demand. That is, when someone orders a widget, build a widget. Of course there are limits to a completely demand-driven manufacturing operation, but the process of moving from being forecast driven to being demand driven has many additional benefits, such as lower inventory and less risk of overstocking.

Short-cycle, iterative software development has demand-driven characteristics. Rather than try to forecast feature delivery capability far into the future—a thankless task, as we all know—why not respond to demand rather than forecast it? Plan an iteration with a certain number of features, measure how many were actually delivered, tell the customer what the delivery capability will be on the next iteration, and have the customer prioritize the remaining backlog according to that demonstrated capability. If an auto manufacturing plant has the capacity to assemble 550 cars a day, then forecasting 750 cars for March 24 is a useless activity. Software development groups are similarly capacity limited.

Aggressive schedules, evolving technology, rapidly changing requirements, uncertain business models, fixed-priced contracts—pick out the term that seems incongruent with the others. “How do we write fixed-price contracts using Agile approaches?” is a question I hear frequently from clients and workshop participants. “Wrong question,” is my usual reply. But while “wrong” in some respects, it is a reasonable question, and the issue of writing “Agile” contracts needs to be addressed.

The fundamental problem is that the business world is increasingly unpredictable, and traditional fixed-price contracts imply predicable results. While we all acknowledge the constancy of change in today's world, we want vendors to bid as if they are better at predicting the future than we are. In many regards, today's contracting process is attempting to guard us against yesterday's problems.

There are really a series of questions involved in delivering projects, and what type of contract to use is last on the list.

When waterfall life cycle development prevailed, developers (internal or external) were asked for fixed-price estimates prior to definition of requirements. At best, one estimate or contract was issued for requirements work and a second for development. However, even with seemingly complete requirements, this approach was often fraught with problems and politics and often ended up with extensive changes near the end. And this was at a time when 10 to 15 percent scope “creep” was considered a problem.

Today the problem domain is different. Business models are evolving and morphing constantly, technology is changing rapidly, Internet time demands rapid response, and technical skill levels are suffering as development teams struggle up one technology learning curve after another. In such a turbulent problem domain, short, iterative, feature-driven (specify, build, review) exploratory development cycles are becoming “best practice” for accomplishing the work.

Building good working relationships with customers and users has always been important to building good software applications. However, in today's world of exploratory projects, good working relationships—true partnerships in which both parties understand their roles and responsibilities—are imperative. They are imperative because every change demands that a choice, a tradeoff, be made. Referring to a formal contract or processing a “change order” for each of these choices will slow projects to a crawl.

So if the problem domain is volatile, the best way to accomplish the work is through an evolutionary development process, and establishing a close working relationship with customers is imperative, then what type of contract matches this environment?

The answer, I think, is a contract based on periodic delivery of features—something the customer can determine has value. Some call these fixed-schedule, variable-scope contracts. I like the term delivered-feature contracts. They are sometimes, wrongly I think, considered time and material contracts. Time and material contracts don't—directly at least—tie in features delivered to the customer. With a delivered-feature contract, the development team demonstrates features to the customer at the end of each short delivery iteration. The customer evaluates value delivered, and if acceptable, the development team and customer proceed to replanning the next cycle based on current information. Commitments for the next iteration are based on delivered value and the next iteration's plan. There are, of course, overall targets for schedule, cost, and scope, but these are not contractual obligations on either party.

Delivered-feature contracts are the ones that make the most sense in this environment, because they best fit the problem domain, how the work should be accomplished, and the necessary working relationship with the client. But actually, if you have the first three, nearly any type of legal contract can be made to work. If you don't have the first three, no type of legal contract will work.

This delivered-feature contracting model fits exploratory development problems for which ASDEs excel. Another model that provides insight into these types of contracts is the model venture capitalists use for funding new companies. According to colleague and Harvard Business School professor Rob Austin, “VCs employ three basic principles to make venture investment success more likely. First, a venture investment must be staged; it must be structured so that dollars invested and risks endured are matched as well as possible over time. Second, incentives and contracts must be arranged so that all of the parties involved in a deal share in the high inherent degree of risk, so all are encouraged to take actions that are in the best interests of the overall project. Third, and most important, the venture must involve the right people to achieve success” (Austin 2001).^[1] The venture capital model provides appropriate incentives, and responsibilities, for both parties in an exploratory development situation.

However, although delivered-feature contracts may be the lowest cost and best fit with Agile development, the reality of corporate, government, and national practices may preclude them, at least in the short term.^[2] In these cases, companies have a couple of options: combining a dysfunctional contracting process with an equally dysfunctional delivery process (the current situation) or combining a dysfunctional contracting process with a viable, Agile delivery process. In the latter case, success may eventually help bring about future changes in the contracts. Fixed-price contracts can be written (this may require more up-front work than for a purely Agile project), then the delivery process can be Agile. It may not be the best scenario, but it is workable. I know of one software company in which the CEO says the company makes more money this way, because it understands, and can manage, the risks better than the clients can. This company writes fixed-price contracts, delivers iteratively, and makes more money!