If the overall point of taking an Agile approach to software development is to do it better and faster, then finding an efficient and easy way of measuring it has got to be crucial, right? What are the popular choices out there? Do they work and if not - why? While it’s perfectly logical to want to come up with a system of measuring the productivity of your workforce, there are a few things we’d encourage you to not do in expectation of productivity increase.
TIMING ALONE
Don’t expect that when people put in over-time, the actual number of tasks done will increase or that work will be completed with more diligence - more time at work hardly ever means getting more done, more often it means just getting more tired, therefore less efficient.
DON’T COUNT LINES OF CODE
This has always been a problematic approach, mainly because more code hardly ever means better code, so this logic fails. Also, if need be, additional, copied code can always be added for more on record, also ..it shouldn’t have to be said, that 4000 bug-ridden lines is not as good as 1000 bug-free lines of code.
This one can be extended right away onto paying devs for bug removal - since it’s normally themselves who control their creation.. can you see the problem?
HOWEVER TEMTING - DON’T PUT THAT MUCH VALUE ON ESTIMATES
They are not commitments - though tend to be misunderstood for those all the time. Estimations will be more or less (or much, much less) accurate on different occasions, and this has to be taken on as standard. Unless your team were working on the same piece of code over and over again, there is just no way to make a correct prediction how long it will take.
DON”T EQUALIZE DEVELOPERS
One clear reason for this is the sheer difference that can be observed between an average and a very good developer. There can be a huge difference in the quality and amount of work these do. No use then to have a standard for an entire organization, is there? Of course, you may want to say how you’re only hiring the best of the best.. but even if we say you do, they will still not all be of the exact same capacity - will they?
So, where are most of the problems with expecting to manage development perfectly well coming from? There is a strong chance this is a result of managers thinking of the dev team as of manufacturers of code - seeing them as just coding. If this were 100% of what they do, it might have been easier to measure their efficiency. But facts are, there is normally a substantial amount of research, problem solving, consultation and planning involved in a programmer’s day of work. Then there is coding.
WHAT THEN?
What can we do to get some sort of a feedback on how well or badly are they doing then?
Arguably, the most sensible thing to look at is the division of time they make for an item of work.
So, get them to make a note of how long an impediment has lasted, how long research took, how much time was given to an unrelated issue that needed to be dealt with immediately, how long testing took and how much time the item spent in waiting for going to each of the next phases.
Try timing your entire lead time - rather than only looking at hours worked since a task had been assigned to a dev, make the whole period from when a customer made their order to when a job has been completed, taking into account all of the waiting, the research, the impediments and actual coding. This gives you an idea of how much time you may realistically need to process another similar request in the future. If this whole process gets visualized and timed along a process line such as a task board - with time you would be able to assume the rough lengths of time each process takes, hence making keeping the stakeholders in the loop easier.
And since you’ve already got the work mapped out as a process, it will now be much easier to reassign and better distribute work among the different teams you’ve got. Distribution of tasks in a way that only forces a few (1 or 2) tasks onto one employee at a time is also possible. Thanks to this, items get done much faster and people less frustrated.
FINAL THOUGHTS
So - do measure how well the team are getting on with the work, but please spend some time devising sensible measurements.
There is also one more thing to consider - it can be, that rather, than building processes and looking at metrics, all you need is an observant, talented manager.. truth is, a good manager knows the typical performance of the people they manage, so spotting a critical descent of form will also be easy.
Keep in mind, though, that since Agile measuring can also imply agile team role re-evaluation, do periodically make sure that people on all positions are staying equipped.