My co-worker made an interesting comment after seeing this excellent interview with Mary and Tom Poppendieck, titled “Using Lean for Competitive Advantage”. Straight to the quick: “They are right, Lean process won’t work in a contract-based environment”.
The problem is simple — customers expect you to deliver X software product, on Y date, for $Z cost, like any off-the-shelf manufactured product. However, as Mary states in the interview, software development cannot be treated this way.
What if software development was seen as a service first? Contracts would retain a team of software developers, for a fixed rate per month, for a few months. At the end of each month the team delivers working software. You can run the meter as long as you want, switch service providers at any time, or ever completely redefine the product you would like to receive. You, the customer, have complete control. Iterative development practices, such as SCRUM and Extreme Programming, make this possible.
My co-worker told me how engineering had dealt with the problem long ago by introducing “turnkey” and “cost-plus” contracts. The turnkey contract lays down a fixed cost and delivery date. A typical turnkey project would be a factory, bridge, or water treatment plant. These things have been built a thousand times before, and the challenges are well-understood.
The cost-plus contracts are the interesting part. The construction of the Shepard subway line in Toronto was done under such a contract. A team of one hundred engineers was placed at the city’s disposal, for $1 million per month, on an on-going monthly basis. The engineers would start, and later extend, a subway line under the city.
Performing any part of this project on either a fixed-cost or fixed-price basis would be crazy. Subway lines have been built before, but each one is unique. You never know what you will find while digging dozens of kilometers of tunnels under a city. You also do not know if the city will run out of money, or when the political sponsorship may change. But the subway was needed, so contracts were drawn up, financing was aquired, and the work went on until the city said “enough”.
Software projects, especially large ones, face many of the same problems and uncertainties. But customers, for whatever reasons, insist on a turnkey software solution! It is our job, as developers, to show them that there are better ways to build software. But we must also show the customer how ‘software engineering as a service’ is a better way to finance projects.
Engineers must be able to calculate per-month contract rates in order to write cost-plus contracts. And they must be able to show their clients when metered contract work is necessary. Lean software development could probably learn something by studying how engineering cost-plus contracts are drawn up and pitched.