This post is coming up from a recent discussion I had with Rusty Zarse, these thoughts have crossed my mind before but the discussion put them back on the top of the stack in my brain. I have also been writing a lot lately about low level CLR type stuff and I don’t want to get shoehorned as a CLR nerd so I also figured it was time for a non-low level post.
I had my first agile experience way back in 1999 (well XP but close enough) I have always leaned towards agile methods in corporate environments. There is however one hurdle we must overcome before agile methodologies can gain a wider acceptance. This hurdle is not getting people to accept pair programming, recognizing that writing unit tests and refactoring does in fact lead to better code, or the acceptance of documents having prices associated with them. This idea is not a new idea but a dredging up of an old one (with a bit of a twist) that has never really had a good answer.
Agile methodologies happen to have a fairly large impedance mismatch with the legal contracts associated with a project. Agile methodologies are all about trust, contracts are all about protection. The very concept of a contract requires heavy documentation as to what each side’s responsibilities are in order to fulfill their end of the contract. Can you imagine for a minute going to a builder in a new development around the corner from your house and signing a $300,000 contract for them build you a house without a floor plan or other specifications being included in the contract?
Not surprisingly when a project is being outsourced companies also like to know up front how much the project will cost so they can accurately detail the financial risk of the project. Since the contracting firm is forced to put forward a fixed price bid the company needs to get a detailed specification in order to put a fixed scope of work into the contract for their own protection.
The problem in dealing with agile methodologies in these situations is not when things go great with beautiful customer relations and a successful product. The issues raise their ugly heads when the project fails, since the contracting company is contracted to work on a moving target when have they legally met their obligations of the contract? The hiring company could feasibly continue to add functionality way beyond the initial scope of the project.
Martin Fowler has written a bit on this issue which suggests that you should instead be setting goals based upon money and time lines when dealing with fixed bid contracts.
To handle this with a fixed price contract you essentially come up with a plan that says “we have $x to spend and we need a release on 1 Dec. We’ll collaborate together to come up with the best set of features to go live with on that date.”
There can be no teeth in the contract to insure the hiring company that they will in fact receive a product that works to their specifications; the contracting company cannot in their own best interest allow such teeth to be put in since they are approaching a moving target. Continuing with the house metaphor, can you imagine going to the building company and signing a contract saying they will work on the house for 75 days, they estimate it will take 75 days but they may be off by up to 40-50%. If they happen to not finish your house in the 75 days then you can feel free to pay them more until the house is finished unless of course the builder has someone who will pay them more in which case they will be unavailable due to scheduling conflict. If we take a closer look at Martin’s suggestion what the hiring company has done is actually bought a block of time at a fixed price, there is no teeth in the contract stating that the software will be complete (or that the plumbing will be installed).
This can open the contracting company up to lawsuits that are nearly impossible to fight and will likely end up in arbitration. The contract says that company x will provide company y a payroll system by December 1st on a 500,000 budget. What is the exact definition of a payroll system? The functional requirements of the system have simply been collaborated on since the inception of the project. Since there are no detailed requirement documents being brought together and signed off on the hiring company could easily gain a good legal standing in a claim against the contracting company.
This issue is best shown when dealing with government based RFP’s. Can you imagine the political turmoil if a 3 million dollar system was contracted in such a way and at the end of the contract the contracting company refused to continue work because they had received a higher paying contract? A politician can, which is why it will be very hard to sell anything to them without them being able to put real teeth into the contract to protect their and their constituents’ (I guess I should have just said their :)) best interest.
Even if you can get a customer to understand why you are not offering a fixed cost, there will always be some less than admirable salesman who convinces them that their company can. A person without alot of experience in software development will assume it is a better price as your price comes with an obvious unknown amount of risk, they will more often than not choose the contract from the less than admirable salesman. You don’t generally get fired for providing a mediocre solution at cost with a vendor on the line contractually (it is the vendors problem). You do get fired when you are 100,000 over budget in consulting bills with an incomplete project as it becomes your own mismanagement that is the problem.
I am not a lawyer but I would love to hear some legal thoughts on just how to put teeth into these contracts without providing explicit criteria for completion of the contract. Until I see successfully litigated cases (which there may already be) I am reluctant to even attempt being agile on a fixed price bid.
1) What are your thoughts on the subject?
2) Have you ever been in a fixed price project gone badly where your saving grace was the fact that you did have a full specification document up front that you could reference to show completion and to help side step feature creep?
3) How do we change corporate culture to move away from fixed price contracts?