10/27/2011
Agile contracts is an interesting thing. one of the main push back against going agile I get in places is that while agile is nice and all there is no way we can convince our customer to work like this. “they want a fixed price fixed scope deal”. In any case this post is not going to talk about why Agile contracts are a good idea, or how to get buy-in from your clients to sign an agile contracts. This post is going to talk about:
The forces against an agile contract
The power of Inertia
People don’t change easily. The fact that our industry has been using a “Fixed …” contract for several decades now goes against trying anything else. Especially if that something else is substantially different. An agile Contract is exactly that. Different.
Risk
An agile contract puts the risk on the paying side (the customer), he is going to pay for the work done, even if that work is of lesser value. Naturally if its value is low enough he can bail out. But still the risk is on him. While a “Fixed …” puts the risk on the development team. they need to fulfill their part before they get paid.
Trust
our industry has not been that great at delivering working software. (to say the least). Most software projects either fails completely or significantly does not meets expectation (either they miss the timeline, exceeds the budget or reduce scope)Potential Profit. An agile contract actually says exactly that. By going for a flexible scope (or time) we actually say we don’t know exactly what will happen, we don’t know what we can deliver (or when). That’s a hard message to tell the one who is paying.Potential Profit
This one is a little elusive. One of thing we do as a development team when we go for a “fixed …” is add buffers to mitigate our risks. At one place I used to work I saw a two days chunk of actual work being priced as 11 weeks for the client. And he was willing to pay (there is a cost for putting the risk on the developers). For us as a development team this represent a significant potential profit. If we could just estimate accurately and actually finish the work in the time we say we can. The buffers just become easy money. No matter how many times we under estimate work, every time when we do a new estimate we are always sure that this time it will be different. This time we have considered everything. After all we are smart people.As you can see there are strong forces affecting both side to resist going for an agile contract. Can you think of more?
Posted in: Agile practices
Posts
10 comments:
What a hot topic. A few more anti-agile-contract points:
- Misconception: Kind of related to the power of inertia. Something I hear often is "The customer will never agree to this", or "Discussion on scope are not an option"
- Not taking initiative: The sense of disempowerment to make a change. For example "They will never agree to this". Who'se they? The Others?
I am more concerned regarding what happends when agile contracts do not materialize. Committing to too much up front, compromising quality, overpricing projects, not committing to continuous improvement, ...
The traditional contracts are a source for stagnation throughout the organization.
Great post!
Another reason I was once facing is when there's a huge chain of customer-vendor that you are only in the beginning of. You can't sign an agile contract with your customers unless they sign agile contracts with all THEIR customers, and the combined power of inertia suddenly became too much to defeat.
Nice post!!
As you mentioned - the customer is the more powerful party in the contract. If the customer would require an agile contract - I wouldn't imagine much resistance. Are we requiring our suppliers to work by an agile contract or just our customers?!
Another interesting point is that this "agile contract" idea is focused on a custom project. When you deal with a product off the shelf, it is much more practical to work by an implicit agile contracts (as you don't have a single customer), and this often what happens in practice, even in organizations not working Agile by-definition.
In a fixed price contract there is always a loser. It is the service provider if the contract is underestimated and the customer if the contract is overestimated. How do you build trust if someone is always the winner and someone is always the loser? No one ever accurately estimates EXACTLY the time it takes for projects of over say 40 hours of time. It's always either too high or too low by some amount.
In a properly executed agile contract, in which all of the priorities are agreed upon, and the process is well educated between the customer and the provider, the Agile contract does the best job of distributing risk. The agile process involves informing the customer all along the way of what is happening as part of the process. In our case each task is estimated, and the customer has a web interface that gives them up to the minute information about progress on tasks. Any exceeding of estimates involves a customer meeting - because it may involve scope changes in the long run. But that doesn't mean it's fixed price - it means that it properly invokes a conversation about the cost of the feature.
It does not remove the risk for either side - it simply distributes the risk between parties.
While I do agree that it requires customer education on the process, I do not agree that it can't be done successfully, and with benefit to both sides of the relationship.
It generally works best once a level of trust has been established between parties, which may involve some short iterations to explore the degree of customer knowledge about their requirements, and the provider's knowledge about the technologies involved, and educate both on the level on interaction required to accomplish the tasks before them.
I do agree it's a hard sell from a "it's different" point of view, but I also know that my customers who we do agile contracts with are very satisified with the results.
I like to point out the Agile is the ONLY contract where there is NO risk of going over budget - just of not getting the least important features completed. Many times that is a game changer for IT managers or vendors that have been burned multiple times by projects going over budget.
A big part of the problem is that business has been allowed to hold a largely unchallenged (and un-educated) belief that software and IT projects are analogous to engineering projects, when in fact they are diametrically opposed.
In engineering, effort can be divided between design (10%) and construction (90%).
In software, all effort *IS* 100% design. There is no division of labour; construction is what the compiler and packaging tools do. This is why, when you try to apply the engineering metaphor you get projects with runaway schedules and budgets: It's very difficult to estimate and plan creative processes. This reality has been known for DECADES - Fred P. Brooks Jr. was probably the first systems engineer to point it out in The Mythical Man-Month in 1975.
More recently, in the September 2011 Harvard Business Review, two researchers who examined over 1,400 IT projects discovered that they now present a "singular new risk" to business leaders. The status quo ideas which they have applied successive generations of projects are now reaching a tipping point that can, does and will wipe out entire companies. Their advice on how to avoid debacles? Set up a contingency: Don't greenlight your largest IT projects unless the business can sustain a 400% cost overrun + 70% schedule overrun with 15%-25% delivered functionality.[1] What an indictment of "business as usual" !
Personally, I think business needs to get scared straight into acceptance of the fact that while they would like certainty on time, budget and delivered features, it doesn't work that way because software isn't built like widgets on an assembly line; it's a new product development process that has many intractable touch-points that resist linear planning. We've known this since Takeuchi & Nonaka pointed it out in 1986 - it's high-time business began to learn this as well. It's for their benefit.
Agile projects seek to balance the risk of software projects between customer and developer by demonstrating ROI every 2-4 weeks. That's your risk mitigation strategy. It requires an educated, actively participating customer and a skilled team.
All of this means that we need to step-up the evangelization and explanation, in clear, concise language, to challenge the prevailing mythology of IT project governance so business can begin to appreciate why they need to engage with their vendors and contractors in new partnerships.
[1] Bent Flyvbjerg, Alexander Budzier, Why Your IT Project May Be Riskier Than You Think. http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/pr
@kirschilan, I don't sure so much can be related to the contract.
i do think that "fix..." contracts, have a tendency to miss the mark (due to our inability to give accurate estimates)
This generally leads to pressure within, and that's leads too all kind of bad things.
@Lee I dont think Agile contracts are a bad thing that cant work. The post just describes reasons I've heard from people who think agile contracts are not good. none of these are GOOD enough reasons in my opinion.
However, I still think that an agile contract puts most of the risk on the paying side. after all the supplier gets paid as long as he is working.
what do you think are the risk on his side?
Also, there will always be a risk of going over budget (if you want to get the entire scope). the only thing an agile contract will enable you is to trade off money and scope in a very effective way.
if you want ALL the scope and the team has underestimated, there is no magic that will make ALL the scope being finished in the initial budget. the team will need more time and more money to complete the work.
Chris, thank you for the comment and references. I think you are totally right.
IT projects are a different beast and they need to be treated differently.
I think hat our industry is finally starting to realize that.
Post a Comment