Can developer productivity be measured?
Overview
Team who are not productive want to be productive and productive teams wants to be more productive. They trace their activities in one of the many productivity measurement software. But… Is really possible to measure productivity?
Increase productivity is the unicorn for Product Managers and some programmers. The main reason is to do self-marketing and telling their bosses something like “Hey! Watch this, i am doing well my job. I am highly productive for the company”. It is an instinct and it is ok, but often these people wrong at choosing the KPI.
Pitfalls of productivity measurement
Some companies appreciate extra hours worked. So, you can be seen as a “good employee” if you be in your desk more than 40 hours weekly. In this sense, this companies are full of employees who stay a lot of inside company without doing anything. As Microsoft showed us in Japan, software industry is not like an assembly line.
Other companies count code lines pushed. This is an excelent method to produce unnecessary extensive code, but not produce value added. In fact, often the better solution for a problem is the small one. Adding unnecessary code break the DRY philosophy. Programmer can commit more code line intentionally to complete goal. Adding a piece of code that non resolve exactly a problem makes is worst than adding zero lines.
Measuring progress by bug solved or tasks closed is not different from others examples. Programmers can add bugs intentionally to fix them later or they can add unnecessary task or slit them in smaller parts. Same thing but with a different name is the trend velocity. Its measure the effort from developers in the iterations, but again, to increase productivity is as easy as assign a higher story points value next time.
All of them are technical indicators implemented and tracing from technical people trying to measure something non-technical in an individual level. Remember we are not talking about software. We are talking about people helping a customer who want to grow a business.
Goodhart’s Law
Reason because that indicator are bad indicators is the Goodhart’s Law. Its declare:
When a measure becomes a target, it ceases to be a good measure
After receive a false goal, a development team focus their attention in the new “goal” instead the real one. Team get focus in technical issues instead adding business value. In this way there are teams that generates thousands of code lines without solving any problem to the business owner.
Measuring productivity from the right point of view
Unfortunately, individual performance can rarely be measured. There are persons who prefers fixing bugs (often adding only one line after ours of analysis). There are multipliers that amplify the intelligence and talent of those around them. There are people with a senior and junior seniority.
On the other hand, team performance, is far more visible. Maybe, the best way to track it is to ask, “Does the team consistently deploy working software for the customer?” This echoes the third Agile principle. Booked hours, story points, breakdown charts, and task throughputs are easy to measure, but they usually don’t give answers to right questions.
The correct way to measure the productivity of a team is to understand the level of satisfaction that the customer has with the software. It is not casual the fact that Apple is in the top of American Customer Satisfaction Index and its position at market cap. Negative feedback from our customers/users are more important than positives ones because negative feedback has more information about what we are doing wrong.
If we don’t measure productivity change from sprint to sprint, it doesn’t mean that we don’t have a clue at all. “Cycle time” is a measure of the time it takes for a bug, feature, or task to move from one status to another. Cycle time can tell you where there are bottlenecks, blockers, or breakdowns in your process in order to be addressed by your development team. Useful to decide if you should to get a new quality assurance specialist. Although it’s true that a productive tester has high delivery rate and push modifies frequently, is not true that testers who has high delivery rate are productive.
Starting watching
So, we need to analyze all variables in its context. An abnormal curve on the Cycle Time graph is not an indicator of productivity, it is an alarm that is turned on to be studied. Other variables that affect productivity are:
- Booked hours to meetings
- Presence of bottlenecks
- Team responsiveness
- Automation level
- Bureaucracy level
- Pending technical debt
- Team motivation level
- Synergy
- Team Knowledge
- Customer feedback
- Internal relationship
- Time sharpening the saw
- Suitability of the solution to the proposed problem
- Staff turnover rate
- Tech and business alignment
- Agility to work
See table below and try to answer wich team you consider more productive. Of course it is the better situation in front of the worst one. Both are unreal, but I think it is a good table to start managing the concept. I am sure you will agree that Team B is more productive than Team A. Notice we are not mentioned Trend Velocity because we can not compare two trend veloticty from two differents teams.
Conclusion
You must be careful at measuring. Productivity can not be measure at individual level and it is very difficult to do it at team level. Mostly because some factors like “Synergy”, “Internal relationship” or “Bureaucracy” are not measurable values. To reduce analysis to a simply velocity trend is naive (and questioned).
Unlike what many people think, productivity is not something that the team acquires immediately. It is more similar to a pool game, where at the beginning you are in a situation and you slowly approach a goal, identifying along the way some pieces of the game that could be better positioned.
To do as good as possible, you can identify situations that affect your productivity and try to fix it. It is important to know them and know how to react. Some of them can be measured and you can use Jira, but many other is difficult or impossible to measured. Productivity can not be measured directly but fortunately, you can identify unfavorable situations for productivity and attack them to improve productivity indirectly.
But… Which one is a good KPI? How should I react in front of this unfavorable situations? That and more, in the next article. ;)
Sources
The_7_Habits_of_Highly_Effective_People — Book
Measuring developer productivity
Scrum team size
Official Scrum guide
