Fixed Price or Fixed Budget?

Last week I was on a panel about distributed agile development. There were a couple good takeaways I wanted to share:

Fixed-price or fixed-budget? We talked a bit about agile outsourcing, and if it's possible to do a fixed-price contract in an agile project. One of my colleagues on the panel brought up a great point - most times, in new product development, you're managing to a fixed budget, but that doesn't necessarily mean you should do a fixed-price contract.

What's the difference?

Everyone has budget contraints, whether dictated by Finance or by your investors. But fixed price means you know exactly what you want, you can describe it to your development partner, and it's not going to change. Very few new product development projects work this way - things will change as we test our assumptions with customers, and in a fixed-price contract, change means friction - namely change orders or renegotiating the contract. Often, a better solution is to manage to a budget, but set priorities - working first on the features that will deliver the highest value to the end-user. This gives you the flexibilty to adjust as you go along, when you discover that a feature you thought would have high-value really doesn't resonate with users, or that a particular feature you thought was low priority turns out to be a differentiator.

My caveats: managing to a fixed budget means: a) working with partner you trust and who is transparent, and b) working with a partner with the systems and processes in place to know their development velocity at any point in the project, so that you know how many features you can develop in a given time-box

Does Agile mean no planning, or just-enough planning? I'm always surprised by how few people are actually using agile in product development, and how much misunderstanding there is about agile and the level of planning or documentation that happens in an agile project. Agile means just-enough documentation, not no-documentation. It's not just the waterfall-advocats who think that Agile means jump-in-without-planning. I've heard Agile zealots rebel against the idea that you could do some design up-front. A member of the audience asked a great question at the session - what if you are developing a system that needs to scale to a million users? Are you going to figure this out as you go along? Jump in to code the highest-value features first and figure out the scalability thing when you get to 999,999 users? No. Just-enough design in this case means doing some system design up front. This is what being a master is all about - knowing when a situation warrants what tools and which process.