Insomnia Consulting Still searching for an interesting slogan

There are two key points that should be made in regards to "Speeding Delivery". 1. Speed is a function of how much work a team can accomplish in a fixed period of time. 2. Delivery presumes that the ideas are already formulated.

Measuring individual performance, and even team performance, is likely counter productive. Rewarding behavior, or otherwise offering incentives based on metrics can cause a range of dysfunctions from gaming to emphasizing the measurable actions at the expense of other less-measurable actions. "There is a negative interaction because of the implicit message of distrust that a measurement system conveys by the fact of its existence. (Measuring and Managing Performance in Organizations; Austin, Robert http://bit.ly/9Pfq9)" The naive attraction of metrics is that we can set a bar, and simply direct our team to work until they reach that bar. With every team I've worked, however, there are a myriad of things to prevent developers from working effectively and most are out of their control in the near term.

An equally naive reaction is that we should assume that a developer's self-interest in doing the best work possible will always yield the best results. Any conscientious employee will try their best to be successful. It's a matter if knowing what "success" means for their particular role and knowing what axes their performance is ultimately measured against. The key is to make it clear what factors relate to the success of the team/employee and let them make judgments about how best to make progress towards that goal. Measurement reflects what happened, not what they should be doing.

Measurement is simply a historical record to allow them to see what effect their work has and not a yardstick against their effort in progress. Since a developer can't change what happened yesterday, a greater focus needs to be placed on retrospectives and learning how to reverse negative trends. Measurement then, should be informational, and should focus on problems that the development team have identified themselves.

For example, in this entry (http://bit.ly/1NwAD5) I mentioned a case where the development team had two features to implement (Word Process integration and multiple contact emails). Since the application in question was designed to collect information for individuals, it seemed clear that adding multiple emails should have been an easier change. Learning why it wasn't (dependency on concrete classes and lack of abstraction) highlights metrics that could be used in the short-term to improve the teams ability to increase speed.

A couple assumptions are being made. First, the "idea" being implemented has already been formulated and placed in the context of the product being developed. Second, the product has a clear strategy and features have a tactical "distance" from that strategy. Having software developers formulate ideas is fine, and many great solutions come from that, but they certainly can't be measure for "ideating" in the same way as they might be measured for building software. Also, they can't be expected to make all changes quickly. Tactical distance leaves open the possibility that the application can be designed to do specific things because it generally applies to the problem domain.

Engineering performance, distinct from formulating product ideas, is localized to specific problems. Doing retrospectives is effective in finding what problems cause a slow-down in delivery, making decisions about reversing those trends, and coming up with metrics for testing if there has been improvement. Once that particular metric has served its purpose it can be discarded and development can continue to focus on the true issue, speeding the delivery of relevant, valuable ideas through the software delivery process rather than dwelling on secondary, potentially dysfunctional measures of engineering performance.