In the modern day of agile and dev-ops, or pretending to do agile and dev-ops, many of us are still pretending when it comes to performance metrics. We recite the make believe slogan of team: ‘it is a team success, a team fail’, but if we truly believe this, why are many organizations still measuring performance metrics from the old world. Old world, aka waterfall, and also most pre-agile type of management philosophies, was handled with individual output performance metrics. Habit is hard to break, true change is harder, it is one thing to get developers on board with scrum ceremonies, it is another thing to truly change management approach to performance metrics. Daily lines of code output per team, daily lines of code output per developer, individual velocity of a stories output of a developer per sprint, velocity of story output of one team to another team per sprint, see the pattern here? The old ways, the waterfall ways, the silo management ways, it focused on performance of the individual and departments, often to promote, fire, give raises, or point the fingers at when the project almost always goes over time and over budget. So when your left scratching your head 6 months in to the project when you promoted and fired by the rules of individual performance metrics, meaning you created your teams and managed them using waterfall style metrics, hence individual performance metrics, while stuffing waterfall style metrics and management in a agile framework, you wonder why your pretending to be agile in team-driven culture failed you.
Lines of code, in of itself it seems like a rational way to measure a programmer’s performance. If you were a brick layer, wouldn’t your PM pride themselve’s on how many bricks each of their team members could set in a day? Maybe, but both in a vacuum are highly flawed, they are measuring output, not outcomes. Bricks must be laid yes, more bricks laid is better than less bricks laid in general, but do not tell the story of outcomes. Bricks not set well, costs much more repairing or replacing that brick, a brick laid with atomic accuracy that takes 100 times as long to set and costs just as more, is not useful or profitable to the company or the client. The client just wants a brick wall for their house, and you are not NASA. They don’t need atomic accuracy, they just need a good old fashioned, straight, and level brick wall.
Rewarding for lines of codes written, creates oversized and cumbersome code. Making code as little as possible, makes it very hard for others to maintain, so a good coding standard should be adopted. This way the team, yes the team, can write, review, maintain, update, efficiently write; straight forward coding. So that throws that performance metric out the window. Lines of code is a 1 dimensional metric. Lines of code is an output, not an outcome, and when we are practicing agile we work for outcomes, not output.
Velocity a measure of team velocity, the metric that is often used to compare one team to another, or individual velocity to other team members over a sprint, either way, is a performance measure of outputs. Again, one dimensional metric that is only useful for calculating output. Velocity does not measure quality of assessment which gives the perceived value and weight of what velocity is measuring. In actuality, velocity can only be a value for that one sprint, and would be incorrect to compare it to other sprint’s velocities for this reason. This metric, again, is wrongfully used to calculate team maturity, i.e., eventually be used for comparative results and finger pointing.
The team being efficient at designing, coding, developing, testing, reviewing, deploying, and making clients happy in a timely, effect manner, is the outcome. Lines of code, number of bricks laid, arbitrary value of velocities, all outputs. Team effectiveness, organizational profit, client satisfaction, are all outcomes. Outputs are the permanence metrics of the old world, scrum-butt, the rules of the blame game. Outcome indicators are the permanence metrics of teams, organizations, client satisfaction, the path of the truly agile.