Measuring productivity using Value Points

The major challenge for managers in 21st century is that of improving productivity of knowledge workers. The management in CDC Bangalore have also started working on this as they had an open feedback session recently.

Here is my proposal to improve productivity – I call it “Productivity Management Framework” or PMF in short. I am on a roll creating official sounding terms and acronyms 🙂 . Anyway,this framework can be divided into three parts – Measurement, Target,Reward

Measurement

Clearly, we need a way to measure productivity if we need to know if productivity is improving or not. I propose a new point system called “Value points“.

Managers of an agile team( DEV,QA and Doc) decide together how much a user story is worth to a customer and then assign a value point to it. This point has no relation to the effort required to complete a US. That is a US that is marked large could have 5 value points while a user story marked small could be worth 25 value points.
The criteria for setting points would be –
1) How important is the US for the customer? Does it help customers achieve something? Most features come under this and get high number of value points
2) If it is a bug resulting from a feature previously implemented by the team, then it does not have any value points assigned to it.This helps in ensuring that the quality of the feature implemented is also considered when the above system is used.

At the end of the year, we could just add up all the points a team achieves and that would be their productivity.

Target

Currently with velocity, the team itself decides on the size of the userstory and hence any target associated with the velocity will not work. The solution is to have the above  Value point targets for each team. There should be a target setting meeting with all managers and entire agile team present where this point target is set. This would be similar to how sales team get their sales target set at the beginning of the year.

Managers would also need to have a target. I propose that managers also have a value point target, but this target should not be a blind addition of all the points their teams achieve. The value point target for the managers should be at feature level. So, feature 1 is 25 points, feature 2 is 10 points and feature 3 is 10 points. This might correspond to 300 value points to the agile team but only 45 points for the manager. This would prevent the manager from giving more points to each user story just to meet his/her own target.

Reward

This is the most important part of the framework. Any productivity improvement initiative should have a buy-in from all employees. One way of doing this would be to have substantial bonuses to people who have achieved the target. If it were up to me, I would set up the reward system as follows –

Team – Every team would have a substantial amount set as bonus. If team achieves the target points, it gets the full amount else a partial or no bonus can be given depending on the company’s financial situation. Also, the bonus amount is same irrespective of number of people in the team. This encourages people to work harder to achieve the target with less number of people rather than hiring more people.
 It also encourages team members to help each other out to meet the target.

Possible issues

•Cumbersome process to assign points to all the user stories. Tracking them would be even bigger task as there is no inbuilt field in rally( the software we use to track). Tracking it in a separate tool would mean proper integration between rally and the new tool
•Issue resolution – The team might not agree with the value points associated to a US by the managers. This would lead to a very sticky situation.
•Meetings – People might complain about having too many meetings.
•Teams might change during course of a year. Managers can change during the course of a year. Need to think of ways to handle these situations.
The weakest point in the above framework is the measurement part. The value points assigned are very subjective and we cannot compare one set of value points( assigned by one set of dev/qa/doc manager) with another set of value points assigned by a different set of managers.

I am sure there are a lot of loopholes in this framework. What do you think are the major concerns in implementing this framework?

Valley of Death

I have started reading “Succeeding with Agile” written by Mike Cohn. I got this book  free when we attended the Agile tour Bangalore. So far, it has been a pretty good read. I had assumed that Mike would preach the ideal way of doing agile like having dedicated scrum master etc. but seems to give surprisingly practical alternatives( which we are following in CDC Software).

Before he starts explaining the process he begins with why a company decides to adopt scrum. One of the reasons he gave is “Valley of death”. It can be best explained with a diagram –

The black line is the revenue a company earns from its old product. The company then decides to work on a new cool product. So all its development resources are put into building this all-new product. After some time, the revenue from the old product starts reducing since the customers of the old product realise that they are not getting anything new.  The revenue from the new product has not yet started since the development is still working on it. This creates a sudden decline in the revenues of a company, but they cannot make reduction in R&D costs since the new product is still under development. This causes huge amounts of losses and death of a few companies. The companies that do survive this phase will start increasing the revenues again from their new product.

The valley of death makes perfect sense to me as Pivotal went through the exact same scenario. We stopped working on major enhancements for Pivotal 5.9 and worked on Sedna(Pivotal 6.0) for close to 2 years. This is a huge risk to take and management would prefer never to see another valley of death.

One of the ways to avoid valley of death is to adopt agile development methodologies. With frequent releases and incremental development, the large gap between releases can be eliminated and hence the dip can be avoided. 

Although agile helps avoiding the valley of death, people in R&D are already tired and bored of frequent releases as service packs. People have started to ask whether we will ever have the next version of Pivotal 7.0.  I feel that the excitement and enthusiasm of a new release has been lost. How can we keep enthusiasm amongst the R&D teams and still release every 3 – 4 months?  

Please do comment.