Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Lean Tools: Contracts

08.13.2012
| 2917 views |
  • submit to reddit
Contracts are often a pain point of Agile transitions: how can you establish iterations where you deliver working software every two weeks, and collect feedback to steer the projectas as often? It's already difficult when a different process exists, but imagine when you have a contract that is directly in contrast with this model, such as "ship these N features in 6 months, and don't bother me before."

Trust

A principle that Toyota consistently applies is that a network of trusted suppliers is more beneficial than short-term gains coming from always looking for the best price, and aggressively selecting who should take the business. In other words, always trying to screw other companies to raise the margin isn't going to pay.

Let's contrast two models of company-company relationship.

In the sequential model, A asks B for a product, and B builds it. Then A makes change requests to get an improved product, and a new contract is signed. Lots of paperwork and negotiation goes on to establish who has the blame for making the change necessary:

  • is it an unexpressed requirements? No one said anything about having to work with Postgresql instead of MySQL due to already purchased licenses. A could have expressed this as a strong contraint.
  • Is it the developer's fault? A asked to use a database, why did you build this as a Sqlite prototype? Probably to creatively interpret the contract and make more money from change requests.

In sequential development the best price wins, and you either have to be content with a mediocre result, or spend more to include changes and accept an high lead time.

In a trust-based model, the uncertainty of development is recognized and written into the contract. For example, the contract may have fixed cost and variable scope. In this case:

  • the risk for the customer is lower as the budget for the iteration is written and it's not liable for more than two weeks of work.
  • The risk is also a bit lower for the team as features are planned at each iteration, and the team commits only to deliver them instead of having to estimate six months of work every time.

This is an example of Customer collaboration over contract negotiation: instead of spending energy to protect each other, collaborate to produce the best product possible. Even if it means to review changes every two weeks. See Alistair Cockburn's list of Agile contracts for an overview of contracts at different level of maturity; from fixed-everything (cost, time, scope, lawyers fees) to price-per-story-point.

Risk

In fixed-price contracts, risk is shifted to developers, since they cannot be paid more than the fixed-price even in case of disasters requiring additional weeks of work. However, the customer cannot do away with all the risk: if the developers produce something that doesn't work lots of time and resources from him will be lost.
Thus risk should stay with the party that is able to bear it:

  • technical risk is for developers. Have to try some new NoSQL databases? We'll make some spikes and see which is the best for our use cases, and if they get slow we will build a cache, and so on. It's our job and fun to manage technologies.
  • business risk is for the customer. If he isn't sure what he wants when asking you to build it, he should have responsibility for it, to provide incentives for figuring out what to do. This forces the customer asking for a new user interface to collaborate in finding out which data to show, as it's his work tool that is at stake.

Speaking concretely: when I was a freelancer I agreed to clone an existing system for some hundred Euros after being pressured in giving a quote and not wanting to lose a client. Can you imagine how it all went down? The work was impossible to perform with such a short budget and we walked away from the contract. Me and the customer lost much time, no one earned money, and they remained locked in in their old system.

What about your contract?

If you're working for an organization, what is your contract?

  • time and materials is usually the consultant's prerogative. Not much risk for you, but the company could take away your job any day. You can't slack off because of this, but you have a relatively high level of expertise so it's not a problem.
  • A fixed salary means that theoretically you have no incentive to be efficient, and you're paid even if it takes longer. You work with less pressure; while a group of us (if you're reading this article, probably including you) have a work ethic, I assure you that many people don't. That's why is important to hire better people: no contract can force people to work professionally.
  • In performance contracts, you're paid based on what you deliver. There is much more risk for you! But if you're good, the company is willing to pay premium for this.
  • Stock options mean you become very invested in the company as you have to make it succeed to become rich. It's a little unfavorable as you're paid with the options that at the moment worth next to nothing, bearing high risk.

All these models may be mixed to lower the risk for you and your company.

Conclusions

Sometimes the bottleneck isn't in overutilized resources, but in the right incentives written into contracts. Analyze the existing contract between employees and organization, or between you and your customer if you deliver a service.

A new contract may be a worth experiment to improve the business model of your organization or of your own person; or also a tool to stimulate the right kind of developer to apply for a job (if he's not clueless about money.)

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)