comments and posts from http://www.infoq.com/articles/agile-contracts

An option from the construction industry
The analogy that software creation is more like gardening then engineering has been around for a while.
In simple terms, here is the difference:
- "In engineering, the final product is defined up front."
- "In software development the final product is rarely known up front, and almost never does it end up like the initial plans and specifications, have defined it. It is simply not possible or even desirable in most software projects in industry."

In SE-Radio Episode 149: Difference between Software Engineering and Computer Science with Chuck Connell, the most insightful perspective was that historically we put too much loosely related things into the same bucket:

Computer Science vs. Software Engineering
- Algorithms, Cryptography, Compilers vs. Business Applications, Consumer Applications
- Complexity Analysis, Correctness Proofs vs. Maintainability, Testability
- Formal Specifications vs. Estimation
- Language Syntax/Semantics vs. Design Patterns
-----------------------------------------------------------------------------------------
An option from the construction industry Feb 08, 2011 06:24 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 Feb 08, 2011 09:07 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 in a text editor, can be as time consuming as writing the code itself, using the same a text editor.
So, same would ask -- where is the benefit in doing it twice?
-----------------------------------------------------------------------------------------
Fixed price contracts Feb 08, 2011 10:04 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

-----------------------------------------------------------------------------------------
Success with fixed price contracts Feb 09, 2011 11:02 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 Feb 09, 2011 04:40 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: Success with fixed price contracts Feb 09, 2011 05:17 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 Feb 10, 2011 06:26 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 Feb 16, 2011 08:21 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 Mar 13, 2011 12:37 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 Mar 13, 2011 12:52 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,
------------------------------------------------------------------------------------------