Agile, Metrics, and T&M

An interesting conversation took place with a client today.

I suspect many development shops using agile methods may run into the same issues. Namely, agile development methods arguably run counter-current to fixed-price contracts and therefore agile shops are often found in relationships with their clients where they are compensated for Time and Materials (T&M). This works especially well with development approaches that re-scope the feature/functions to meet the schedule and/or the available budget rather than constraining the the developer to deliver all features/functions regardless of the exposure to themselves (a la, “Fixed Price”).

So consider the following scenario: a developer managing its development using Scrum has a client with a fixed budget to spend on the developers to deliver a set of features — but doesn’t necessarily expect all the features to be delivered as long as a good value has been delivered. The developers work to deliver as much as they can and burn off the hours — and their goal is to not leave any hours un-burnt.

In this scenario, the only business metric the developers’ CEO cares about is whether they’ve burnt all the hours. Assuming they delivered a quality product and the client is happy with the value, the metric here is pretty simple: profit. The client will pay the maximum budget and regardless of how efficiently the developers have worked, the company will make the same amount of money.

In comes the CMMI process area of Measurement and Analysis (MA)… which expects the company to be collecting metrics based on business objectives — presumably to help improve the process. However, in a T&M situation, what metrics are really any more important than whether or not the company spent all the hours? What’s the incentive to deliver more of the functions and burn less when they don’t get paid for what they don’t spend?

I hope to generate some discussion on this point and I’ll post what we ended up doing in the next day or so — I’m here to learn as much as anyone else.

[By the way, this was also my first test of emailing blog entries... I hope it didn't suck.]