No I'm not swearing!
This is a serious post about the difference between management by objectives (or conformance to plan commitments) versus management of process variation. The management scientists will recognize this as the Peter Drucker versus Edwards Deming debate [Drucker and Deming actually roomed together at one point in the early 50's where this argument started. Drucker is said by Deming to have capitulated eventually.] Yet others may see this as a Crosby versus Deming debate. And in many ways the Crosby idea of measuring quality by conformance to spec, isn't so far removed from the Drucker idea of set a target, get a commitment from an accountable person and then hold their feet to the fire until they deliver.
Back in 2001, Mac Felsing and Ken Ritchie [both of Process Exchange] were working with me at Sprintpcs.com. Whilst I was managing a dev team amongst other duties, they were working for the newly appointed Senior Director of Engineering in his process improvement group. They were tasked with building adoption for FDD across the business unit. One day they set up a meeting with me, and when they arrived, they were filled with frustration. The boss had asked them to start measuring individual performance on feature commitments and report conformance against commitment.
[A brief sidebar. I've written before about my dislike for the "planned date" in the feature milestones in FDD. It's a topic about which Jeff De Luca and I disagree. I see it as management by inch pebble objectives and I don't like it. I prefer to measure feature completion velocity. At most I only ever ask for chief programmer work package completion milestones and then its a feature team commitment against a batch of work.]
I'm on record as being very anti individual measurement. The likelihood, that measuring individual feature milestone commitments and using them in performance reviews would blow an FDD team apart and destroy productivity and morale, is very high. It's a fundamental tenet of FDD that you never, ever, measure individuals. Heck, FDD doesn't even monitor individual tasks - only features constructed by a team. I had to save the senior director from his own ineptitude. So I suggested that they flip this metric on its head and take it back to him as a report on our ability to estimate and a measure of the variation between planned and actual. Over time, we should as a team and an organization be able to show that we are learning and that this learning manifests itself as reduced variation. Under no circumstances should we use this data to evaluate individuals performance.
[I also promised myself that I had to get out from under this new boss. Five months later I quit Sprint altogether.]
The executive request was for management by objectives (MBO) and conformance to plan or individuals would pay the consequences. [Management knew that layoffs were coming the following year and they wanted to identify the weaker players with objective data.] The alternative to MBO is management of process variation.
Lesson Learned. In MSF for CMMI(R) Process Improvement, I am taking a management by reducing variation approach. Commitments are based on ranges derived from measured variation. The standard metrics and reports show the process variation in productivity, velocity and quality. It is through these mechanism that we undo the heavyweight, document centric, trustless, fear driven process designs out of CMMI.
[To close out this post, Deming firmly believed that individuals were almost never responsible for their own performance but rather victims of the variation in the tasks that they had to perform. Only if the organization could learn to understand and reduce its variation would performance improve. Now there is a radical idea - programmers are not individually responsible for their own performance!]
