Using metrics to improve product quality

Metrics. Managers love them. Developers hate them; but why is that? In a word, "trust". If we don't make clear from the beginning the intention of these metrics, distrust and resentment of them will set in and they will have a counter productive influence as developers begin to look for ways to "beat the system". The funny thing is, whether you're a manager or a developer, we all have one thing in common. We all want to improve the quality of the product and metrics when applied correctly help us all to achieve that. So how do we make metrics work?

• Be transparent. Ensure you make clear the purpose of these metrics is to improve the quality of the product. Not to beat developers with a stick.
• Focus on product quality, not individual performance. We all share that common goal so establish and capitalise on that alignment of interest. Do measure cyclomatic complexity and afferent/efferent coupling. Don't measure "most check-ins a week" or "most lines of code".
• Create buy-in. Don't force these down. Identify meaningful metrics by utilising the experiences of those closest to the issues.

If we focus on the wrong metrics, we risk creating a culture where we write code that's purpose is simply to pass fool a rule. This is entirely different to writing clean, maintainable code which is where the real benefit is. Worst still, if metrics are used incorrectly as developer KPI's, no developer is ever going to undertake that much needed refactor of that difficult to maintain code for fear that it will hurt their "score" or "ranking". When we get to that point, it's the beginning of the end.

What other ways can you ensure metrics succeed within your team?  What metrics do you capture?

Is management training only for managers?

Think about some of the tools and concepts we use...

• Cultivating relationships 
• Task, time and workload management
• Management reporting

Are these really concepts that are only applicable to managers?

Developers, BA's, testers, they all have something in common.  They all need to interface with other areas of the organisation or perhaps even externally with clients.  They should all therefore be preparing for influence by cultivating relationships, ideally before they really need them.  It may seem like common sense, most management techniques are when you think about them, but why does this only become part of the curriculum for management when it's execution can have so much benefit earlier on in one's career?

We learn about visualising and managing our own workload.  Whether this be through maintaining simple task lists and calendar appointments in Outlook to more sophisticated mechanisms employing spreadsheets or personal kanban's, but why shouldn't these tools be applied at every level?  Managing your workload and identifying "what do I want to complete today?" ensures you don't face an endless list of tasks on a daily basis.  This reduces stress, creates a sense of achievement and therefore breeds a happier and in-turn more productive employee. 

What about management reporting?  We may use this to highlight to our own manager the issues impeding the effectiveness of the team we are responsible for but why do we need to be a manager of people before management reporting becomes an effective tool?  Perhaps you manage or are responsible for a particular process which is being impacted by external influences?  Perhaps you are a busy developer or product tester but can't deliver what's being asked of you because the hardware is under powered or the tools you were provided are not up to the task?  Everybody faces impediments to whatever it is they are responsible for and therefore I always encourage some form of reporting mechanism with every member of my team.  It doesn't have to be a comprehensive report with fancy formatting and pretty charts.  It could be as simple as a quick email at the end of each week listing the "Top 5 Impediments" they faced.  Of course, a lot of this should come out of other mechanisms such as Daily Scrums or weekly one-to-one's but you'll be amazed just how many great opportunities for improvement are highlighted by such a simple reporting mechanism which is complied as the issues occur, then forwarded to you at the end of the week.

As we can see, these are powerful tools which could help improve the productivity and personal progression of all members within your team.  Why not utilise your own coaching mechanism to share these and pay it forward?  In doing so, it will also assist you with the building of your own succession plan; ensuring you have great internal candidates to fill that vacancy you leave when your own career progresses.

What other tools do we learn through management training that could be applied earlier on in our careers?