Embracing Agile on a Fixed Price Project

Agile and Fixed Price

I’ll be honest, I was nervous. I’ve been developing in agile environments for several years now, and the thought of a fixed price project was frightening. It doesn’t seem like the principles of agile are conducive to a fixed price project. Customer collaboration? Continuous feedback? Responding to change? These concepts sound like they were designed to scuttle a fixed price project. But this is what the client wanted, and I was asked to lead the effort. Sure we had a change control process in place, but that was just going to break momentum in the long run.

Not only was it fixed price, but it was a new team, tackling a new-to-us codebase, and a new technology with a steep learning curve (WPF in this case). Did I mention that nobody on the team was involved in the time estimate? What we had was a list of stories to complete, and an incentive for finishing early. Likewise, there was a dis-incentive for finishing late.

The End Result

I take a lot of pride in the work I do, and I love delivering a product the customer loves just as much as I love a beautiful code solution. Delivering on time seemed impossible, much less delivering a product the customer loved.

It turns out we delivered a four month project three weeks early, and delivered a great solution that the customer loves. I was as surprised as everyone and have been reflecting on how we achieved it.

The Keys to Success

When it comes to agile, there are many principles to live by. The following items are what I tried to focus on.

  • The simplest thing that could possibly work. Our UX guy probably lost several years off his life after all the great ideas that had to be left behind. Build the simplest thing, minimum viable product, maximize the work not done, whatever you want to call it.
  • Continuous feedback from the customer is great. But you’ve got to realize you cannot deliver everything they want, or even everything you want. When you are under a fixed price, you must deliver what is spelled out. There is nothing wrong with telling the customer what is possible, and in fact we would do this all the time. But know that without change control you just can’t do it.
  • Be ruthless. Hopefully your contract has spelled out stories and not detailed specs. With stories, you have more latitude to deliver the simplest thing possible, and ever better, deliver the right solution to the problem. But you must be ruthless. Anything out of scope is out of scope. It’s best if you do this as nicely as possible.
  • We never had any change requests. To be honest I’m not sure if that is good or bad. Maybe we over-delivered. I think if we HAD gotten change requests, I would have liked to tackle them after the initial delivery. I think the momentum loss from the change request would outweigh tackling a change while things are fresh. That may seem a little backwards, but I feel that in a fixed price project you must stay focused on delivering.

Final Thoughts

I won’t lie. The key points above may have had nothing to do with our success. It may have had everything to do with having a great small team (3 devs and 1 UX) focused on a common goal. But if there is a take away, it’s that it is possible, and agile and fixed priced are not necessarily at odds.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s