PMinFOCUS

I had a couple of “Twitter” discussions recently about agile vs. ‘traditional’ approach to project management. Traditional means Waterfall for most people (including me), at least in IT.

One of the discussion was about using Agile with Fixed Price contracts.

Usually Fixed Price contracts means that all requirements are known upfront and that a plan is carefully developed from day 1 to project closure in order to make sure all costs are understood, and that total project length is figured out (both to plan resources needs and to avoid late penalties).

Fixed Price contracts also usually operate under a tight Change Control mode, and Changes are not usually welcomed: they disturb the work currently being done by the teams, indeed, the current plan does not contain time to analyse change requests which therefore could be seen as a threat to the execution of the project. One the other hand the customer knows that changes usually means good margins for the supplier.

This tends to go against some of the agile principles about welcoming changes and iterative planning with re-assessment of the scope and priorities at each iteration (for Scrum anyway), also fixed price projects are ruled by the “Contract” and not the “Customer collaboration”.

However this is not impossible and I could find a number of positive experiences (or seemingly).
In this post it is argued that fixed price contracts have better outcome with Agile practices.

I won’t pretend to know the “Final answer”, I am only keen to contribute to the debate. My experience and my observation of the industry I am in: essentially Systems integration for Telecoms operators tells me that there are two hard facts that are HUGE blockers to using Agile for Fixed Price contracts in my industry:

Blocker 1: The project is driven by the contract and both parties are focusing on “what’s in their” for them in the contract. This is the hard reality, a requirement is a requirement, a date is a date.

Blocker 2: The buyer is NEVER organised to cope with Agile techniques of continuous integration, continuous testing. Go and ask a Telecom operator to put something live every say one month over a period of 6-9 months and ask them to validate the deliverables throughout the project. This will (almost) NEVER happen due to all live operational constraints, test environments availability, resources availability.

Blocker 2 is, in my industry, the key blocker for using Agile.

Thoughts?