BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Agile Contracts

Posted by Allan Kelly on Feb 08, 2011 |

One question frequent asked about Agile methods is: "How do you sign a contract based on Agile working?"

The traditional Waterfall model fits nicely with the way companies buy things: the requirements are drawn up, a supplier quotes a price (based on their interpretation of the requirements and estimates of cost) and everyone signs a legally binding agreement.

Once the contract is signed a development period follows where everyone argues about what is actually in scope, what is out of scope, and what constitutes a change request to the contract. But eventually the work is done, and after some heated debate, the customer formally accepts the software and payment is made. The customer gets 200kg of software, the supplier gets their money, and everyone is happy - or perhaps not quite everyone.

Of course there is nothing to stop you from signing a contract the traditional way and then working the project using Agile techniques but it does seem to defeat the whole point of Agile. A change request is not a big issue for an Agile team, not only do they expect them but lack of change requests would be considered a problem by some. In the extreme, Agile teams can start work without any requirements document. Conversely, since deliveries can occur in increments it would seem reasonable to expect early payment.

If both supplier and customer are to obtain the maximum benefit from Agile working then traditional style contracts for work need to be rethought. This is an evolving area and companies are constantly searching for new models for Agile contracts. Consequently there are opportunities for innovative thinkers to disrupt the status quo.

This article will look at four models available to suppliers and customers for establishing contracts for Agile work. In time new models are likely to appear but right now there are broadly four options.

Debunking fixed contract

The fixed price, fixed duration, fixed scope contract continues to be the standard benchmark for contracts in the IT industry. A contract of this type is based on the idea that an initial project can define the scope of work; from which a supplier can determine what is required - or rather how many people for how long - and thus, calculate a price. Once complete, the contract can be signed in blood and executed as such.

This model is based on the understanding that it is a "thing" that is being supplied, namely, some quantity of specialist software. Yet buying custom software is less like buying a tailor made suit and more like buying financial advice. What you are buying is more of a service than goods or merchandise.

While I have met many people and companies who bid for work on this basis I have yet to meet anyone who has successfully completed such a project without relaxing at least one of the "fixed" parameters (scope, cost, or schedule). The IT industry has been signing these types of contracts for years and for just as long has been failing to successfully deliver them.

The reasons for these failures are not hard to find - the scope of the project changes, new requirements emerge, existing requirements are overlooked, while still others are misinterpreted (the same words may mean different things to different people). Explaining all the ways the contact scope may change could fill an entire article itself. Whatever the reason, once requirements change in a "fixed" contract everything else must change too. First duration and/or staffing needs to change, then that price must change too.

If you step back and think about it, continued use of this type of contract is actually quite touching. It demonstrates the power of faith, positive thinking, and hope that somehow next time things will be different.

Perhaps the reason these type of contracts survive is because they can be defended in court. While one side claims the contract was not fulfilled the other side claims it was - leaving it up to a judge to decide. But given the inherent flaws in the fixed contract model, one could argue that this type of contract might actually increase the risk of going to court. Finally, it should be noted that signing a contract requires all parties involved to momentarily believe that the requirements are known and fixed, estimates are correct and quality will be acceptable - given the history of such contracts this is a little surprising.

Not for everyone

Before examining the options it is worth noting that this issue does not effect every company creating software or attempting Agile. Companies which create and sell software products - sometimes called ISVs, Independent Software Vendors, the likes of Adobe and Intuit - only experience this issue on the periphery. Most of their customers only buy products which are finished, and don't get very much direct say in what the product does.

Some corporate IT groups who create software avoid the contracting problem too. They buy ready made software (such as SQL Server) or they create custom software which will be used only by the company itself. Most corporate IT groups at some time contract out work and consequently need to create and agree upon contracts. In these cases the IT group is the customer to a third party software supplier.

The service companies which corporate IT groups sub-contract to - sometimes called External Service Providers, ESPs - are the ones who have the greatest need for contracts which provide for Agile working.

Agile fits easily into the ISV way of working, indeed, many of the Agile practices started life in this segment. Similarly, Agile can fit into the corporate IT world when corporate policies and procedures allow it.

But, ESPs and their customers have problems with the Agile way of working because they need to put a legal contract in place between the two parties. Yet in this problem lies opportunity.

Because customers (corporate IT groups and government departments) expect IT projects to encounter problems, contract terms have got stiffer and financial penalties higher. Only the biggest ESPs can consider bidding on large contracts. Smaller companies cannot afford the penalty clauses and therefore cannot compete with the large players with deep pockets who can afford big penalties.

Changing the contract structure potentially changes the way large IT consumers buy custom software and may provide the proverbial win-win scenario. Suppliers who can break away from the fixed price, fixed scope, fixed time contracts stand to gain a competitive advantage over the market leaders. Customers stand to benefit from innovative approaches that provide a better outcome.

Option 1: Hide it

The simplest, least disruptive, way of using Agile within a delivery contract is just to hide it. Don't tell the customer you are working any differently to normal. Estimate and plan the work as you would normally, sign a perfectly normal contract, then use Agile techniques to improve delivery.

Test driven development, continuous integration, refactoring regularly and re-planning will all help you be better at delivering anyway. To the degree possible ignore the original plan, since it was "wrong" anyway. If possible, throw the original plan away.

Trouble is, some customers want to see "progress against plan." You could fake it. I have heard stories of teams who update the plans to make it look like they were following the plan. However this approach isn't entirely truthful, indeed, how can we ever hope to build trust with a customer if we fake part of the process they believe in? Naturally, we don't want to lie to a customer, we want to build trust, and why would they trust us if we were faking following a plan?

Of course, one could argue that customers who wanted to monitor your progress against plan, rather than against actual delivery, are not demonstrating trust either. However it is our job, as contractors, to show them they can trust us.

So to make the "hide it" approach work there needs to be a "don't ask, don't tell" type policy. If you have a customer who is prepared to follow the "don’t ask, don’t tell" policy, and instead measure progress against actual deliveries rather than following the plan, then hiding Agile might work. But if you have such an understanding customer, then you probably don't need to hide Agile in the first place.

Option 2: No cure, No pay

Adopting a "No cure, No pay" approach requires a certain degree of confidence. The approach is simple: if the customer doesn't like what you deliver there is no fee. However, if they don't pay for what you produce they don't get to keep it either.

While such an approach looks scary it does provide the opportunity to increase the fee. Using this approach the clients reduce their risk exposure while the contractor increased theirs. The price for this rebalancing of risk is a higher price.

Such an approach may be intellectually (and perhaps morally) the superior position to adopt but it introduces a new risk. Since the client is less exposed they have less motivation to make the work a success. When decisions get hard to make, compromises are needed, time is scarce, or client involvement is required, the client has no incentive to do what is needed.

When clients have no skin in the game any failure is entirely the failure of the contractor, clients have nothing to loose.

This risk might be offset if suppliers choose to only work with customers who will maintain their commitment. This assumes that the contractor feels able to turn down work they judge risky and can correctly assess the commitment level of the client.

To date, I have only heard of solo and small suppliers offering this model. The companies with deep pockets are either wary of the risk or don't feel the need to offer this option.

Option 3: Rolling contracts

If we wish to keep customers involved, then we need a mechanism to involve them and continually ask them to recommit to the work. This is where rolling contracts have a part to play. Rather than agree to a large piece of "all-or-nothing" work, the customer and supplier put in place a framework agreement for a series of short development mini-projects, call them episodes or iterations if you prefer.

The contract probably has some overall goal but doesn't contain a shopping list of specific features and functions. The discovery of needs is part of the work itself. One ESP I know of keeps all requirements out of the legal contract. With each iteration something is delivered and, equally important, the understanding of what is still needed increases.

With each delivery the customer pays the supplier and has a choice: continue to the next iteration or halt here. The emphasis is put on the supplier to a) deliver something that adds value and works, b) demonstrate that there is more worth doing that will add value. If the client cannot see that the value created is greater than the cost they can walk away from the work with that which has been created so far. Equally, if the supplier finds that the client is not cooperating they can walk away too.

In some ways this isn't that different from the traditional practice of paying and recommitting after each distinct phase: requirements, design, development, testing and deployment. The difference is that, while in the traditional model a decision to walk away before the end would result in no delivered benefit, under this model something is delivered.

On the supplier side there is an clear incentive to demonstrate value through vertical slices of completed functionality - a common Agile practice.

Because the client can see something being created, value being added and a solution coming together they should be enthused to keep working. And because they know they have the option to walk away if they ever loose their commitment they can.

This option moves the legal framework away from the supply of a thing and towards the supply of a service. Clients are contracting for a service and some thought needs to be given to the amount of service they are buying. Four man months? 200 velocity points of work?

While this option might sound radical, many IT groups and suppliers are already using service contracts in adjacent areas. For example, IT support desks and software maintenance contracts are normally written as service contracts.

Option 4: Money for Nothing, Change for Free

The "Money for Nothing, Change for Free" contract has been documented in detail by Scrum originator Jeff Sutherland. Rather than construct the contract as a framework for mini-projects, this approach maintains the big contract - which implicitly suggests some large upfront requirements analysis. However two additional clauses are added to the contract.

The first change in the contract exists to facilitate working on the highest priority items first and accommodating new work. Customers agree to meet with suppliers regularly to reprioritise the remaining work. At this time they may add additional work to the backlog with the understanding that in doing so some other work might drop off the end and not get done at all. This increases the incentive to work with and help the supplier and maintain customer involvement.

Like a rolling contract, the customer pays in regular, say monthly, increments in response to delivered working software - which also keeps customers involved, leads to another implicit recommitment, and makes way for the second change.

The "money for nothing" provision allows the customer, at any stage, to cancel the remaining work and keep what has been created so far. For this privilege the client pays 20% of the outstanding work.

So if a client cancel’s a 12-month, $12m project half way through, they will pay an additional $1.2m in addition to the $6m paid to date. The client saves the $4.8m they would have spent to see the contract through.

At first sight the supplier might not view this option favourably since they stand to lose $4.8m they would have earned. However, the $1.2m they are paid for doing nothing goes a long way to offset this. Assuming they redeploy their staff onto other work quickly much of that $1.2m will be pure profit.

Thus, the mechanisms and incentives are provided for customers to get involved, get work done early and save money. Similarly, suppliers are incentivized to accept change, do good work, and collect free money.

At the moment examples of this type of contract are thin on the ground.

Combinations

Given these four options it is easy to see some more alternatives by combining them in different ways. For example, "Change for Free" could be combined with any of the other three options to create a more potent solution. Similarly "No cure, No pay" could be applied to individual deliveries in option three - "Rolling Contracts".

Finances not withstanding, options three and four are probably not really very different. Perhaps the main difference is that option three breaks the traditional model because it assumes little is known at the start and asks the customer to repeatedly commit in the positive.

Conversely, option four works within the existing model, keeping the assumption of upfront requirements. The "change for free" part provides a framework similar to the rolling contract: initial requirements serve as an estimating tool to decide time and budget. Once work starts they can be thrown away. The "money for nothing" part simulates the rolling contract by allowing work to stop at any point, albeit at a premium.

Whichever way contracts are written for Agile teams, there are two essential elements that need to be considered. Firstly, the contracts themselves should embody the iterative nature of Agile working: do a bit, show a bit, do a bit more. This is the theme which occurs again and again in Agile: time-boxed iterations, retrospectives, test driven development, etc. etc. It is the PDCA cycle in action.

Second: contracts should incentivise customers and their representatives to maintain involvement with the process for the full duration of the project. Study after study has shown continued customer involvement is a key factor in ensuring the success of IT projects. Whether you are working Agile or not, you want continued customer involvement.

Last, but not least

Customers who have not been exposed to the IT industry's traditional way of working may find any of these options completely logical. Those who have worked with IT suppliers in the past may find some of these options surprising. Our industry has done customers a disservice by propagating the myth that "if you can write it down, we can build it within a predetermined cost and time."

Inevitably some clients will continue to cling to the traditional contract model. Some suppliers will find good money in taking advantage of these customers, while others will lose money by clinging to a model which doesn't work. Neither outcome is particularly appealing.

One of my clients now regularly offers his clients two options: a traditional "fixed" contract and a rolling-Agile option. If the customer thinks everything can be fixed before work begins they can use the traditional approach. If they aren't so sure, they can exercise the iterative rolling-Agile approach.

In time, as customers better understand these new ways of approaching IT contracts and the wide range of possible options available, everyone stands to benefit. Right now there are opportunities for those who can make an early shift to new contract models. Yes, there are risks - but there are also rewards.

About the Author

Allan Kelly has held just about every job in the software world: system admin, tester, developer, architect, product manager and development manager. He is based in London and specializes in helping software companies adopt and deepen Agile and Lean practices through training, consulting and coaching.

In addition to numerous journal articles and conference presentation he is the author of "Changing Software Development: Learning to become Agile".

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

An option from the construction industry by Dean Schulze

In chapter 4 his book The Design of Design, Fred Brooks details how in construction projects there are normally two contracts. One is for design work, which is a contract for design services that produce final construction drawings and specifications along with other design artifacts like 3D models. This part involves iterative feedback from the client. The second contract is for actual construction and is based on the architecture and engineering work done under the first contact.

I'm surprised that this model hasn't been studied more for use in software projects. The first contract could be used to produce and refine requirements, use cases, design artifacts of various types, and prototypes or working code spikes. The result of this design contract could then be used as the basis for a fixed price contract if the client wanted to proceed this way. Or once having seen the short iteration feedback mechanism in action and having developed some trust the client may decide to base the actual development contract on the service model rather than the fixed price model.

The long history of the two contract approach in construction should help clients have confidence in this model.

Re: An option from the construction industry by allan kelly

Thanks for the suggestion Dean, I'll have a look into this.

allan

Re: An option from the construction industry by Ingolf Sander

It seems to me, that there is one big difference between construction and software projects. In construction projects you need real bricks to build something, which cannot be changed easily afterwards. So there is a benefit in designing upfront and building later on.

In software projects writing good specification (using a text editor) can be as time consuming as writing the code itself (using a text editor). So where is the benefit in doing it twice?

Fixed price contracts by Martin Aspeli

I work for a big consultancy, and most of our development project contracts are fixed price. The reason isn't really that it makes it easier for our clients to sue us (or vice-a-versa), but more that the people procuring the solution need to get budget pre-approved, and for that they need some perceived certainty around cost. Of course, savvier customers generally add 20% for change requests.

We don't really prefer working this way, and we're upfront with customers that we add a risk premium on fixed price contracts. That is, we believe they could get it cheaper on a time-and-materials contract, and if they want the faux certainty, they will pay for it. This is usually met with resignation ("we know, but this is the way it works here"), but we try to make sure the change request process is as lightweight and effective as possible. As a general rule, we're happy to change any requirement so long as there's no net increase in scope and we haven't already started work on the given requirement.

The way we normally describe it, there are four dimensions: Time, cost (which is usually a function of time in our case, since we charge by the day), scope and quality. We can give certainty on any three of those, but the fourth will always be variable. On a fixed price, fixed scope contract, we give certainty of time, cost and scope, but if push comes to shove, we have to compromise on quality - skipping tests, not performing code reviews, not architecting solutions for maintainability and longevity. Most of the cost over the lifetime of most solutions tends to come in support, and everyone knows how expensive and painful a poorly constructed solution can be, even if it passes some arbitrarily concocted set of tests.

Given this choice, we'd rather make quality constant, and scope variable. This is an easier sell once people realise that they don't really know what they want anyway, but it does come down to building a strong relationship with the client, so that they trust we have their best interests in mind and we only want to be paid fairly for our time.

We also point out that on fixed scope projects, people tend to hedge their bets by asking for things they aren't sure they need, since there's only one opportunity to define the scope. Also, they usually have poor visibility over the marginal cost of a given requirement. Something that is of limited value can still be hugely expensive, sometimes changing the nature of a solution significantly. Both can be addressed by making scope more variable.

Martin

Re: An option from the construction industry by Martin Aspeli

This implies a strictly waterfall model, with all the problems associated with that. Even if the same company does the analysis/design and the build, they are no more likely (perhaps less likely, given lack of proximity of the business) to get requirements and design 100% right, and having user feedback and scope steer limited to the start of the project is very limiting.

Re: An option from the construction industry by Martin Aspeli

You are right that software engineering is a very different discipline to construction, and I think the industry has not been well served by a reliance on that analogy.

To me the difference is more about the fact that software engineering is a creative process. There are many, many ways to achieve a similar outcome. Also, most people (clients) can relate to buildings easily. If you see floor plans and drawings, you can visualise the end result. The same is not at all true for software. It is a great fallacy of IT projects that we assume the users can visualise and describe what they want a system to do. This implies they are systems experts who know the state of the art in IT. Usually, nothing is further from the truth.

Instead, we need to let users focus on describing their business problems. That they should do better than anyone. Once the business problem is understood, the development team and client engage on a journey to build solutions for those problems. Here, close collaboration and feedback is vital.

So, in a sense you're right - writing the perfect spec is like writing the perfect solution, but I don't think writing one would give you the other. Software projects with no documentation usually fail too

Martin

Success with fixed price contracts by Edwin Dando

This is a timely article thanks Allan.

We have used Agile contracts twice now with great success. One was on a local government engagement in which there were three parties bidding. We were the most expensive and won it because of the approach we took (Scrum). The client didn’t know what they didn’t know, so the idea of being able to reduce risk by seeing working software delivered to them every Friday afternoon, shortly followed by another Sprint Planning session to plan the next round of work was something they were more than happy to pay for.

I believe as an industry we have held clients at arms length via traditional fixed price (/scope, /time) contracts and not been entirely honest about the implications of this approach. After all, didn’t the Agile Manifesto talk about customer collaboration over contract negotiation? I realise the commercial reality is sometimes different and challenging but I passionately believe that as professionals we owe it to the industry to grow and mature, after all – isn’t that part of our job and a moral responsibility? How else will it ever change?

We will continue to use agile contracts to our advantage as from the above we have earned the trust and respect of our clients - something that requires a long term view but in my mind is worth the time.

Re: An option from the construction industry by Chris Morris

In software, the code is the design. Construction is done by compilers and interpreters.

Re: An option from the construction industry by Dean Schulze

Ingolf,

While it may not be as easy as changing software, construction projects do get changed during construction. They sometimes run into problems that were unanticipated and threaten the entire project.

The problem with your second point is that the subject matter experts don't know how to design and code and software engineers normally don't understand the business well enough to write the requirements and use cases.

The design phase of construction projects is like software development. The architects use iterations with feedback to create 3D models and finally blueprints that are used as a starting point for fixed price bids and actual construction. The second phase of construction projects, the bricks and mortar phase, is not a good model for software development.

My point was that paying for service (thinking rather than producing the final product) during the design phase should be more widely studied and used in software projects.

Re: An option from the construction industry by Dean Schulze

Martin,

Please read chapter 4 in The Design of Design. You couldn't be more wrong that waterfall is implied.

My hope is that if software customers realize that paying for design services has been long established in construction projects it will encourage them to move away from the fixed price model, at least in part.

Re: Success with fixed price contracts by John Ryan

Edwin,

It is great to hear that a client is willing to bite on such a progressive approach (and indeed, prefer it).

There are a number of replies here that touch very nearly on what might just be the central issue: a trust-based relationship. While the letter of "Collaboration over Contract" seems to explicitly deal with this exact situation, perhaps it is even more useful to look to the spirit of this Core Value: that we value developing trust with the client so that we relate directly toward a common goal (i.e. collaboration) over relating indirectly through sticks and carrots (i.e. contract).

Concretely, to develop a high degree of trust, both sides need to demonstrate that:

  • they are capable of holding-up their end of the relationship -- that the vendor has the required competence (both in engineering and project management) and the client has the ability/willingness to help discover and translate their general sense of need into concrete software capability;

  • both sides follow through on ALL commitments; and the second that a commitment won't be met, they report that, quickly (just like you'd do with a partner in any situation);

  • they are real with each other -- there's a tendency for vendors to cop arrogance and client's to pretend they know exactly what they want. We need to get real. When you see each other as peers playing their important role in the effort, you're there;

  • finally, there needs to be a significant alignment of goals. Hitch your success together and share the risk. For the vendor, you can start the ball rolling on this one by making it clear that you're here to make them successful... first.


I know this can sound like a campfire scene, but if we can cut out the middle-school-giggles-about-sex attitude for just one second and see how human endeavors are more efficient and effective (and thus more productive) when the parties work closely together, we'd see that this just makes good business sense.

Of course there are other factors that thwart such efforts (e.g. internal political forces aim to kill the project). But this shouldn't stop us from trying.

Contracts, then, become more of a formality, a means of satisfying the respective business processes with emergency ejection clauses that keep each party intact should an outside force kill the effort. Pragmatically, the flavor of the relationship will influence and the shape the contract. When you sit down and sign, both sides have this feeling of excitement and anticipation rather than nervousness and fear.

Re: An option from the construction industry by Martin Aspeli

Perhaps, but asking people to buy and read a book to make your point is probably not optimal. Could you explain for those of us who don't own the book?

Re: An option from the construction industry by Dean Schulze

Martin,

Sure. The excerpt from Chapter 4 that explains how the construction industry does this is below.

Why would you dismiss this as waterfall if you hadn't read it?

======================

..it is essentially impossible to specify a complete and accurate set of requirements for any complex system except in iterative interaction with the design process. How have the centuries-old building design disciplines handled this perplexity? Fundamentally, by a quite different contracting model. Consider a normal building design process:

1. The client develops a program, not a specification, for the building.

2. He contracts with an architect, usually on an hourly or percentage basis, for services, not for a specified product.

3. The architect elicits from the client, the users, and other stakeholders a more complete program, which does not pretend to be a rigid contractable product specification.

4. The architect does a conceptual design that approximates the reconciliation of program and the constraints of budget, schedule, and code. This serves as a first prototype, to be conceptually tested by the stakeholders.

5. After iteration, the architect performs design development, often producing more detailed drawings, a 3-D scale model, mock-ups, and so on. After stakeholder iteration, the architect produces construction drawings and specifications.

6. The client uses these drawings and specifications to enter into a fixed-price contract for the product.

Notice how this long-evolved model separates the contract for design from the contract for construction. Even when both are performed by the same organization, this separation clarifies many things.

Re: An option from the construction industry by Rukshan Jayaratna

Well, isn't that the Big Up Front Design (which client approves) and the build?

For me that mechanism is heavily used in Tender based software projects, where the initial specification is also drawn up by a consultant (who dont get to bid for the tender). That is not agile.

Factor of the Trust and Relationship by Rukshan Jayaratna

We need to factor in the level of trust the two parties have.

My suggestion is to opt for fixed priced contract to build trust (developer absorb the extra time) (yes, small projects), then with the build up of the trust to go for more time and material billing.

Re: An option from the construction industry by Dean Schulze

Rukshan,

Iterations with feedback from the customer is the core of agile.

Are you saying that agile projects can't have a requirements gathering or design phase before writing code?

Reminds me of this old Kent Beck paper by Clint Modien

Re: An option from the construction industry by jojo reyes

I guess, you need to have the specification so you can test the code if the code meets the specifications

Re: An option from the construction industry by Manoj Vadakkan

Dean,

4. The architect does a conceptual design that approximates the reconciliation of program and the constraints of budget, schedule, and code. This serves as a first prototype, to be conceptually tested by the stakeholders.

5. After iteration, the architect performs design development, often producing more detailed drawings, a 3-D scale model, mock-ups, and so on. After stakeholder iteration, the architect produces construction drawings and specifications.

6. The client uses these drawings and specifications to enter into a fixed-price contract for the product.


Question for you: In construction projects, do they usually figure out all of it when they finish the design? Do they usually have to change design after they start constructing?

Re: An option from the construction industry by Essam Badawi

But this brings us back to the old (I don't wanna say traditional) way of SWD (i.e., the waterfall model), doesn't it?


Fred Brooks, published the article "No Silver Bullet: Essence and Accidents of Software Engineering".

Brooks identifies two categories of complexity in software development:
[1] The essential complexity of software development is related to the specification, design (mapping specification to software), and testing (that the design properly meets business needs).

[2] The accidental complexity refers to the difficulties related to implementation (languages, runtime, tools, and programming techniques).

In his article, Brooks explained how the various innovations that attempted to address accidental complexity (at the time) were not silver bullets, and concluded that the only things that may yield close to an order of magnitude productivity improvement are those that address essential complexity, such as improvements in requirements gathering, rapid prototyping, and cultivating good design skills.

Re: An option from the construction industry by Essam Badawi

True. In construction field, as other plan-driven type of business, Tries to predict what will happen with the entire project during planning. Scope change can cause delay.

Inevitably , the software development business is very different in nature, and for it, we rather need more "agile methods" whereby we embraces scope change. Believes scope is not 100% known until you get into development.

To conclude, about the suggested 2 contract-types in Dean's reply: Although the first type, include some sort of iterative development, but it still implies a lot of 'upfront' tasks. While, the second type, is more suitable for "plan-driven" nature of business like the construction; not SW.

Thanks,

Re: An option from the construction industry by Essam Badawi

The point is that, no matter how good the design (specs) would be, but because of many reasons (related to the nature of the software), everything is likely to change. (Actually, it should be welcomed to change). In other words, investing very much at the start in the specifying and designing the target system wouldn't solve the problem.

Reasons for changes:
- developers are getting to know the problem that keeps changing
- developers are getting to know the solution that keeps changing
- developers are getting to know the technology (to build the solution) that keeps changing
- even worth, the customer is getting what's he really need that keeps changing as well (e.g., market change, competitive opportunity, .. )
- ... [could you send of other reasons?:-)]

Re: An option from the construction industry by Essam Badawi

Dragging the fact, about the nature of the software, that "the client cannot set the mind, till he saw a working software afterwards he often ask for many changes", I think it would be clear that both 'iterative design contract' and 'fixed implementation contract are not working for the SWD business.

Dean, what do you think?

Re: An option from the construction industry by Essam Badawi

and it shows not very successful results over many years ..

Re: An option from the construction industry by Essam Badawi

Dean,
Look at it from the "value-driven" perspective. Doing that much of investments (and iterations) to produce something on paper, does not represents a real value to the customer. In SWD, the customer pays to have a software, not documentation.

Re: An option from the construction industry by Rukshan Jayaratna

Dean,

No. Agree an agile project could have a requirements gathering and a design phase. But I see it to be not the end of the requirements gathering or the final design (like in a building), but just the start.

Re: Reminds me of this old Kent Beck paper by Wes McClure

optional scope is time and materials billing, you don't need a contract for that.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

27 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT