Measuring progress is important, as is assessing how well you are performing. The two are distinctly different, however. I wrote about assessing – or diagnosing – to determine where your pain points are (and where there are noteworthy strengths) in my post, Don’t Measure. Diagnose!
While performing well improves the rate of progress, the goal of measuring progress should be about the contribution that is being made toward the success of a larger entity. Individuals must make meaningful contributions to their team, and teams must make meaningful contributions towards a larger business goal.
By doing so, any measurements will be both meaningful and will gravitate upward, evaluated on the basis of how delivery contributed to the success of the larger entity. Ultimately, these upward contributions translate directly to business performance.
For example, high-quality, well-designed code that has automated unit tests wrapped around it – enabling continuous refactoring – will not only make delivery of the current features faster because less time will be spent fixing problem now, it will provide a solid foundation to maintain a team’s velocity in the long term. This in turn will allow the business to deliver a constant and consistent value stream to the customer.
The key is to focus on what is meaningful to deliver to the larger unit. Developers are a part of a team where code is only a part of the total delivery. A new feature must be tested, documented, and packaged with other features for delivery. Software teams, in turn, deliver features that have value to the business – where customer satisfaction ultimately makes or breaks a company.
What should be of no concern are intermediate metrics based on functional specialties. Focus measurements on contributions that lead to business impact, and assess day-to-day performance through diagnostics, using active involvement to keep any overhead to a minimum.