Agile Fixed-Price

From time to time I am beeing asked if it is always possible to utilize Agile software development in offshore outsourcing. Here's a response I posted to such question:

"What happens if the customer is not familiar ith Agile methods, can you still utlize Agile development methodology in such a project?"


From our experience at Ignite, it is not mandatory that the customer will be educated with regards to Agile practices.

For example, we hade an incident where the customer's own in-house team worked in a traditional waterfall model. The customer's outsourcing experience was based on fixed-price engagements only, where, from his point of view, the outsourcing risk is manageable, and still we managed to bring a distributed outsourced onsite-offshore team that practiced agile in a fixed-price model, working collaboratively with the customer's in-house waterfall R&D team.

The customer heard about Agile and was willing to give it a shot as long as it will not take too much overheard, and as long as this would still be a fixed-price engagement. Once we requested, and he agreed, to allocate a product manager to work with us, our onsite project manager assumed the role of product owner (this was a Scrum team), working face to face with the customer's product manager on one hand and managing the offshore R&D team using Scrum internally.

Typically, the customer's product manager should have taken the product owner role, but due to lack of familiarity with Agile practices he preferred to stick with traditional methods. Our project manager "interviewed" him at the beginning of the project, created a set of high-level user stories and defined the priorities based on the objectives set by the product manager. Although all the guidance was coming from the product manager, from the offshore R&D team perspective, the product owner was our own project manager, they did not communicate with the customer's product manager directly.

We assigned the stories/features to 3 weeks iterations and kicked off the project. Towards the end of each iteration our project manager would sit down with the product manager, present the upcoming deliverables and then the two used to reprioritize the features of the upcoming iteration.

As in any other software development project, the deliverables of each iteration triggered some insights and new understandings of the final product and often – some change requests. On one hand, this was a fixed-price project and therefore change requests are billable and might break the budget and due date objectives, on the other hand – we are practicing Agile methods which welcome change requests as natural part of a software development process.

To solve this dilemma we utilize a process of exchange requests rather than the plain change request procedure. In an exchange request procedure our team will examine the requested change and try to identify a lower priority feature, with similar effort estimate, which was not developed yet, and can be exchanged with the change request at hand. This way, we still meet the customer's due date and budget objectives while responding to change.

Of course, this is not an accurate science. Sometimes it's not so easy to find the perfect candidate feature for this feature exchange. On average a fixed-price Agile project will have between 10%-20% budget overruns due to change requests. Having said that, it is still much better then the grim statistics of standard waterfall fixed-price projects where 60% of them are 200% over the agreed upon budget!