There are two questions that I get more than any others as I travel around sharing on agile topics:
- How does agile work with distributed teams?
- How can agile deal with fixed price, fixed scope contracts?
And these questions are usually not simply questions. They’re thrown down as “gauntlets” that defy agilities promises. Often they are prefaced with – “Hey Bob, but in the real world…”
I’ve talked about and around them for years. I’ve written more about #1 in my blogging and I’ve never really addressed #2 formally.
I was listening to a discussion on the Disciplined Agile Deliver group on LinkedIn the other day and Cliff Berg had a nice reply in a thread started by Steven Ziselman. Here’s Steve’s question and Cliff’s reply.
Steven Ziselman, MBA, CSM, CSD, CSPO I am interested in finding out how to effectively handle/establish fixed price contracts for Agile delivery projects with external vendors.
Cliff Berg The core problem is that creating any kind of device in a contract that attempts to measure the supplier creates a conflict of interest between the customer and supplier: the customer has an incentive to squeeze the supplier, and the supplier has an incentive to get the most money for the least effort. Inevitably, the relationship will become mired in arguments over how much value a feature has, whether features could have or should have been completed in an iteration - and these discussions become acrimonious because they are frequent and they are about money. The solution is the treat the relationship as a partnership - one that can be disbanded at any time. Software is not like building a building: with software, it is hard to anticipate everything you want ahead of time, and you cannot design it all ahead of time. Software is built from abstract layers of code that you cannot see, and cannot anticipate all of the interactions that will be needed. Imagine designing a 1000 page spreadsheet packed with formulas, and being asked to predefine every sheet and every cell, and being asked to estimate exactly how long it will take to create it
I just fell in love with Cliff’s reply. I think he nailed it. We have got to begin moving from adversarial relationships over contract positions to true partnerships when we’re dealing with cross-organizational agile contracts.
It’s one of the reasons I like working for and representing Velocity Partners. We don’t think of ourselves as executing a contract for our customers OR as simply providing warm bodies to write code. Our name thoughtfully represents who we are. We look for partnerships and strive to become partners with our clients as we both deliver on the value and velocity of true agile delivery. Sometimes its nice when your principles are aligned…
Stay agile my friends,
Bob.