Tuesday, June 08, 2004

The is No “I” in FDD

Last Friday night, I was having a beer in a local pub with a former colleague who was relating a debate he’d been having with another friend and avid XPer about project estimation. His friend had been questioning “What do you mean you don’t make the developers responsible for their estimates?” and continuing that it was key to XP that developers accepted individual responsibility for their estimates. And indeed, I know this to be true because I have read it and heard from the great and good in the XP community. However, it occurred to me in response that there is no “I” in Feature Dryven Development - it’s a team sport and responsibility is held at the team level for everything. There is no such concept as doing something on your own in FDD. You don’t code features on your own, you don’t design on your own, you don’t review on your own and most of all you don’t analyze or plan on your own. Like everything else in FDD estimation is done by a team (not necessarily everyone on the project) on behalf of the project. There is a shared responsibility.

The second aspect of planning in FDD is that it isn’t done on a “How long do you think this Feature will take?” basis. It’s done by estimating the complexity of the Feature against a codification scheme. The combination of these two systemic approaches to estimation has the effect of moving the estimation into the top row of the Wheeler matrix. It makes it a problem of chance cause variation rather than assigned cause variation.

When Shewhart originally defined chance and assigned cause variation, he deliberately classified variance across individuals as assigned cause variation. For example, on an assembly line, if you could identify that defects came from a particular worker then that was an assigned cause - by definition - and the cure was to give the worker training to improve their quality. Hence, by asking individual developers to estimate stories, you are adopting assigned cause variation into your system. By definition, you must eliminate all assigned cause variation in order to move to the upper row of the Wheeler matrix. If you have a goal of achieving the Ideal State then you must eliminate assigned cause variation.

The argument from the XP community is that by forcing individuals to make and recognize mistakes - failure to estimate accurately being one such mistake - the individual will learn. Over time, the standard of knowledge in an XP team will normalize and assignable cause variation across the set of individuals will disappear. However, this assumes that the team remains stable. Any change of personnel is a change in the system. Any change in the system risks the (re-)introduction of assignable cause variation.

Agile methods avoid the problem of failing to achieve the Ideal State by relaxing their standards. The scope of the project is allowed to vary in order that dates and budgets can be met. In other words, scope is used as the buffer against assigned cause variation such as “Joe underestimated all his stories and we had to drop 3 of them in order to finish the iteration on time.”

Using quality as a competitive weapon, I could compete against such a system by offering the customer, a guaranteed delivery date, guaranteed scope and guaranteed price. In other words, re-define the meaning of conformant quality. All that I need to do is gain the customers agreement to use some non-essential scope as an insurance premium against assigned cause variation. In this case, I’ll be able to provide the guarantee because I’m buffering the chance cause variation within known control limits. My price will be more competitive because my buffers will be smaller, or my promise will be stronger, than a team that needs to buffer for assignable cause variation.

So in summary is it better to take the Mike Cohn approach and codify the method of estimating stories, or is it better to use the standard prescription and make developers individually responsible? Well I think the answer to this is going to vary by the learning and analysis ability of the individuals. There is an argument which says that the bee sting approach of individual responsibility and correction for error may work faster than trying to devise and teach a codification mechanism. On the other hand, you only need one or two people on a team to be good at codification to get results in the upper row of the Wheeler matrix - to eliminate the assigned cause variation. My personal preference is to go for codification and try to develop the skill as widely across the team as possible but rely on the best expertise to keep the estimate as a common cause system variable. If you do decide to stick with individual estimates and individually accepted responsibility then you are accepting the fact that your system operates at best in the Brink of Chaos State.

Agilists such as Ken Schwaber are on record as saying that agile methods manage at the “edge of chaos” (Wheeler’s “brink of chaos”) and in many cases that may be good enough. However, I know that if I can push a team to the Ideal State and turn the screws on the definition of conformant quality, I can always out perform a team operating at the edge of chaos. The last word on this belongs to Eli Goldratt…

“Don’t let inertia stop you from seeking out further improvement”.