Measured measuring
KPI's can destroy a teams morale and productivity if they are not carefully considered. Every organisation likes to measure the performance of their employees, some more formally than others. It's pretty easy to see what your metric is in a sales environment when deciding who is and who is not doing their best. Measure the value of their sales activity and you get a pretty good idea how well they are performing right?
In a development environment it can be tricky to know what to measure. There are plenty of potential performance metrics to choose from, everything is done on a computer so naturally you can track and measure it. The problem is one of choice. Whatever metrics you define as your criteria for success will become the focus for improvement. Hence the power of both measuring and rewarding salespeople on pure sales numbers.
For developers, measure lines of code (LOC) committed and they will duly write more LOC. LOC alone means nothing; it could be crappy code right? It's better to measure for the outcome you want. Find some way of measuring quality and that becomes the incentive. Measure it and the team will naturally seek to improve it.
In Scrum there is the team's sprint burndown, which shows how quickly they get through their story points and how likely they are to finish the sprint tasks. A longer trend you could measure is release planning, where you do a similar thing to a burndown but for the whole project/release.
This is all fine for estimating and project planning but in measuring quality it's not much help. Again, what you measure as 'quality' will depend on your situation but some possibilities include: unit test coverage, defect count, uptime, customer feedback, use statistics. Whatever it is you measure, make sure you can get the data reliably and at the right level of detail.
Posted in Coding, Agile, Scrum | no comments |
