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.]
posted by Hillel @ 20:36
3 Comments
Links to this post
3 Comments:
How about a T&M with Incentive Bonuses?
In the strawman, it was indicated the company already had a list of items that it wants to accomplish. Why not assume, say, a 20% increase in scope per year. The contract could then pay an Incentive Bonus for each 10% increment of project final scope (original scope + 20%).
I will note, however, that this really does not help much if the company does not have underlying trust of the contractor. With T&M, there is the risk that the contractor won't deliver anything, though one can always drop that contractor. By adding incentives, there is the chance that the contractor will cherry-pick and also deliver low quality as "done."
In the end, one cannot buy trustworthiness, though incentives may give some legal personnel comfort.
I have to say, the assumption that the customer "doesn't necessarily expect all the features to be delivered as long as a good value has been delivered" is invalid most of the time. As a consultant, I see customers that are naive in thinking that they must have all of the features. And they generally don't care about quality either, though they begin to once bugs start rolling in or features start taking longer and longer to implement. So, most of my time is spent educating them on this, but only after the initial agreement. While I love this technique, it can take time to establish a trust, as Wayne mentioned, as well as educating the customer. It also forces you, as a company or independent contractor, to be picky about your customers or else you see this problem far too often.
Good point, James. In the case I described, the developers have very good relationship with the clients which is why they can "get away with" not delivering all the features they "sold" in the first place.
For what it's worth, I personally have a hard time believing there are many client who would ever accept a "we'll deliver what we can deliver" attitude from a developer they don't already have some level of trust in.
Post a Comment
Links to this post:
Create a Link
<< Home