Ideal Inflation

A recent ExtremeProgramming Customer expressed the concern that, in order to increase slack while appearing to improve ProjectVelocity, XP teams would steadily decrease the delivered functionality per Ideal day from iteration to iteration. He suggested this could happen not only with conscious malice, but as a subconscious artifact of their desire to please.

increase the size of Ideal days

What does this mean? Increase what aspect of an ideal day?

Sorry, badly put. He meant you'd increase the number of Ideal days per delivered functionality. In other words, in his mind our ideal days would have enough slack injected into them so our team of lazy programmers could sit around and smoke hashish for a living.

Obviously this was a communication problem; I've only ever seen one programmer attempt to exploit the ideals this way, and we had many more problems with him than just this. But I don't have a ready answer for the customer who frets about this, and I'd like to have one.

One possibility, naturally, is to use other metrics to check. Say, # of new tests / # new lines of code. If that number stays constant, there can be no IdealInflation ... unless the tests do nothing ... But explaining this to a customer is the challenge.

Does this customer spend much time around the development area? Do they see lazy developers slacking off? Or is this some hypothetical concern? If it's hypothetical (I'm guessing it is) then I'm not sure tinkering with metrics will help. An hypothesis like this one is belongs to Theory X, and that spells trouble. If the concern is hypothetical, then either spending some time watching the developers work--writing tests, doing integrations, making releases--will address the concern, or else it won't. Then there's a deeper problem with the customer not trusting the developers to give good value, and then that's the thing to fix.

Sounds to me like a control issue. The Customer wants the developers to be working hard for him, as opposed to solving his problems in an agreed-upon manner.

I don't understand. The ideal day is such an arbitrary concoction and it is used in such a dynamic way, I don't see how any form of inflation could have any impact whatsoever. The client should not be aware of the existence of ideal days in any case; it's a tool for developer estimates. An ideal day is simply an imaginary unit for normalizing estimates. They could be called jelly-beans or anything else. If one developer estimates something at 10 jelly-beans and another estimates it at 5, you write down 5, not 10. If anything, there would be deflation. Since programmers work in pairs, it will quickly become evident if any programmers are over-estimating their chosen tasks because the partner will get a boost in velocity everytime they work with the over-estimator. If you PairPromiscuously, you will easily see who's lazy and who's not. If the customer is ever unhappy with productivity, they can simply stop paying for development. Contrast this with the fixed estimate model where the urge to over-estimate is deeply ingrained in project management (who routinely multiply developer estimates by 2, 3, or more).