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.

What got you here won’t get you there…

This book was written by Marshall Goldsmith who helps successful people get even better. He has put down his methodology to improve so  that the less fortunate amongst us( he charges a 6 figure price for his sessions) can also benefit.

He starts with what he calls twenty bad habits a successful person has. Some of these characteristics are –

• Need to win –  Need to win…when it matters, when it does not matter. No matter what, the need to win causes people to treat people who are hindering like dirt.
• Need to add value – When someone comes with a great idea, you say something like “That is good. It would be better if you do “. You might improve the idea by 2% but reduced the motivation of that person by 50%.
• Speaking when angry – ohh… way too familiar for me 🙂
• Starting with However, but or No –  When you start with “I agree, but” or “No, I believe” or “That is correct, However…” , You are saying you don’t agree.
• Too much negativity – “Let me tell you why it wont work”. This really pulls down other people.
• Punishing the messenger
• Failing to recognise other people

There are a lot more… but it is enough to say if you say that when you are reading the 20 flaws, you will recognise yourself in some of them. However, there could be some flaws that you are not even aware of.

The first step is to identify which of the problems you have. Marshall suggests asking the people you work with. You might not agree with all the feedback people give, but the only correct answer to any feedback is “Thank You”. He also suggests a way to ask for feedback. You should ony ask “How can I do better?” and nothing else.

The feedback will suggest that you have one or more of the twenty issues listed. Once you get the feedback, you should work on only one issue at a time. The issue with trying to change is that you need to change 100% to get credit of 10%. That is because once you have established a bad trait, no matter how much you change the perception will always lag behind.

To overcome this, Marshall suggest that you announce the one issue you are going to be working on to the people who gave you the feedback. You should also practise feedforward. That is, you should ask suggestions from people as to how you can improve on that one issue. Now that you advertise that you are working on one issue, every effort you make to improve on it will be noticed by your team. Hence the perception of you changes a lot faster than if you do not share the information.

One last idea that I liked was to recruit a helper. This helper should impose a fine every time you display the bad habit. I already tried this out on a fresher who joined our team recently and was still in the college mode of calling me and everyone around as “Sir” or “Madam”. I imposed a fine of 5 rupees every time he called me Sir. After 45 rupees, he has stopped it :-). So, I know this works.

With many companies moving to agile, people are working more closely with each other. Managers have a lesser idea about your good traits and bad traits compared to your team members.Hence, it becomes more important to ask the opinion of your team members to improve yourself. Do you agree?

Do Comment.

Cross functional Managers

When I started reading Re-Imagine by Tom Peters, I thought of a way to build a proper agile team where a person is able to test as well as develop for this team. You can read about the post here – https://bigfatbooksinapage.wordpress.com/2010/12/19/hiring-in-an-agile-environment/ 

The drawback of the idea was that since a person was doing both QA and Dev job, who would be responsible for the person’s performance? How does the appraisal process work for this new hires?

 

The solution was given in a later chapter by Tom Peters himself. The solution is to have Cross functional managers(XF Managers). Why do we need a separate manager for QA,DEv and Doc when the members of the agile team are working together on a single product? Why not make a manager responsible for the entire product?  So, if two agile teams are working on a single product, then there can be only one manager who manages both the teams, and also all the aspects of it( DEV,QA and DOC).

 

Currently a manager has to deal with only one aspect of development. This is true till VP/Director position. However, after this position, the person is responsible for all the aspects of a product. Why keep the complexity of managing different aspects only at such high level? What happens if the company suddenly loses a person in this position? It has to struggle while the new person comes to terms with the complexity of managing cross functional requirements of a product.

 

Ideally, there should be lots of people who are experienced in dealing with cross functional requirements of a team in a company. A manager who has experience in managing a cross functional team would be great for an organisation.

This gives the  company a long endless list of managers who are capable of replacing people one level above themselves.

 

This idea also matches the “leadership pipeline” concept where a company is supposed to have a pipeline of potential leaders to fill up any position.

 

I am sure there will be problems initially. Suppose the current QA manager becomes the XF manager for a team,  he/she might not be able to understand the complexity and give proper guidance in a particular situation to the dev team. Similarly, if the current Dev manager becomes XF manager for a product, he might not give enough importance to QA side of things leading to a lot of dissatisfaction. However, all these problems will be temporary in most cases. If the problems persist,the company will soon find out the capability of managers. Better to find out inability at team manager level rather than at VP level. Right?

 

I know that companies that are already structured along the lines of QA,DEV etc will never restructure according to the idea above. But, I believe,if dont restructure, we will never be able to fully get the benefits of following agile practises.

 

What do you think?

Post a day challenge – Who deserves more credit?

Who deserves more credit? hmmm… very interesting question. I can think of two sets, one in the business world and one in my life as a software engineer.

In business world, I feel TATA motors deserves more credit that it gets. Ratan Tata has invested in  in-house R&D way before other Indian automobile companies. The result is that Tata indica was the first truly Indian car. Also, the way R&D has progressed in tata needs to be applauded more. From the initial less-than-great Indica, they have moved on to awe-inspiring Tata Nano, which despite being the cheapest car in the world is able to pass EURO N-Cap test successfully.I would like to see Maruti or Hyundai cars do that…. Unfortunately Indian media likes to focus on the negatives rather than praising good engineering efforts. Just type “lamborghini” or “ferrari” car fire in google and you will get hundreds of images of these supercars burning. Yet, these foreign cars do not get any adverse publicity.

I just hope for the sake of innovation in India that Nano is a huge success. I wish that it becomes the best-selling car in year 2011.

On the software engineering side, i find that QA does not get the credit it deserves. Many people, including in my company, believe that testing is not skilled work. If someone leaves the company, he/she can be easily replaced with another person. However, I have been working with excellent people who have shown me what real testing is. The ability to test a piece of functionality in numerous different ways is true talent and skill that cannot be easily replaced. I also find that the more a person works on a product, the better the person tests.Most of the credit for a successful release will be hogged by the development team while QA gets only the blame if some issues crop up. The faster a company realises this, the better it is.

I realised this when we started working in agile. Scrum makes people work closely. Working closely helped me realise the skill that a good tester possesses. It helped our team realise what a big factor they are in the success of our team. So, the solution to “How to give people more credit” is work in agile mode. 

Who do you think deserves more credit? Let me know.

Hiring in an Agile environment

I am currently reading a book call Re-Imagine written by Tom Peters. So far, the book basically talks about how things are changing towards service. Having a great product is just the price for entry and great service is what makes a company successful. He also talks about customer success rather than customer satisfaction. More about this in a later post… after I finish reading…

 

One of the key points he tells is that we have to completely Re-Imagine the way we do things. Re-imagine everything to be successful.

 

In our current agile teams,there are always a bottle neck. Some times it is developers, if the new feature being developed is investigation intensive or it is the testers if the sprint involves a lot of US that are testing intensive.  The agile methodology says that every member should be able to do everything. Sure, people should have expertise in certain areas, but every member should be able to develop as well as test. However, with our current setup, it is very difficult for a tester to learn coding and God alone can help our customers if we trust developers to do testing.

 

Even when we have opening now, we still seem to be hiring according to old department of Dev,QA and Doc. 

Instead, we should re-imagine the hiring process and hire a ‘Agile team member’.  Since it is very difficult to teach an old dog new tricks, this new hiring process will work only for fresh Graduates.

 

Here is what we should do –

• Create a comprehensive aptitude test.
• One round of interview where the existing team members( not manager or lead) will interview the candidates. The team members select the candidates. After all, it is the team which has to finally work with him/her once hired. This interview need not be technical in nature.

Once the candidates are selected, they are given 6 months to prove themselves. Their 6 months would involve doing the following –

• Learning about the product
• Start contributing to the team as a tester at the end of first 3 months.
• At the end of 6 months, they should have finished the following –
  • Create one cool project with the things the candidate has learnt. This project should be designed coded and unit tested by the candidate.Any standard project like “library management” or things like that will be rejected by the mentor immediately.
  • Should be able to contribute to the team as a developer.

At the end of 6 months we have a truly rounded candidate who can do both testing as well as coding. I am not considering technical writing as it is rarely a bottle neck in the team.

Advantages

• True Agile team member. No more QA,DEV,DOC business..
• We might just get a star amongst us. Since the candidate is still a fresher, the ROI for the company will be unmatched.
• We get 6 months to evaluate a candidate.

Disadvantages

• A fresher might have ‘further’ studies in his/her plans and might quit soon.
• Management issues. If the candidate does both QA and DEV who evaluates the person. How will the appraisal process apply? Do we need to Re-imagine the appraisal process?

What do you think? Does your company hire a developer or an agile team member?

Planning using effective velocity

We have been following agile and Scrum in particular for about 2 years in CDC Software.In these two years, we have learnt a few things that are not mentioned in any of the books on agile.

 

All the books say that one needs to look at velocity of a team to figure out how much of a team can complete and plan accordingly. Experience shows that it is not easy. What we need to consider is effective velocity.

 

I believe, even in stories there are two kinds –

• one that is useful to the customer – ex:- fixing defects or providing enhancements. 
• Required to be done but not useful to customer ex:- update sandbox, technical spike,integration testing etc.

 

The velocity of the team in one of the releases read like this – 72,80,102,89 for a total of 343 points. 

If we consider only US that are useful to the customer, our velocity reads like this – 64,58,64,43 for a total of 229 points.

If we take a useful stories as a percentage – 229/343*100 = 66.7%

This lets me define a new terminology – Useful Story Points Percentage or USPP. Sounds like a real term that is widely used in the industry no?

I verified the figures for two previous cadences and the USPP varied between 66 and 75%. Overall we found that the percentage increases if we use a 3 week sprint and reduces when we use a 2 week sprint.

Now, coming to planning,Velocity of a team is supposed to be used by the product owner to plan a cadence. If the team’s velocity is 50 points per sprint, they should be able to finish approximately 50* 4= 200 points worth of user stories in 4 sprints. However, when a product owner creates a backlog, he/she puts in only user stories that are useful to the customer, i.e only enhancements and defects. Hence the team should consider the USPP and take effective velocity into consideration while planning. So, a team can finish only 200 * 0.75 (Velocity * USPP) in a cadence.

So, product owners should take into consideration Effective Velocity of a team while planning for a cadence. I calculated the effective velocity of our team in the last two releases and found that they were very consistent at 57 and 58 points per sprint.Do you know your team’s USPP and Effective velocity?

What do you think about my analysis? Please please do comment

Nuts! The story of SouthWest Airlines

Nuts! is a very nice book about the success of SouthWest airlines. The book reads like a good novel and worked really well as a bed time story book for me.

 

SWA is the pioneer of the low-cost airline.Their business model has been replicated many times all over the world, but no one has been able to replicate its success. Before I begin, some facts about SouthWest Airlines(SWA) –

• Only airline company to make profits every year since 1973.
• Has never mass fired employees
• Has never lost a passenger to accidents
• Has the highest customer satisfaction rating
• Serves double the number of passengers per employee than the nearest rival. i.e its employees are 100% more efficient than other airlines.

Although many airlines copied SWA business model(sell cheap tickets but keep the planes full and in the air), they were not as successful because no one copied the root cause of the success.

SWA are able to achieve this incredible set of figures above because of the following –

Difficult Birth – When SWA began operations, Airline industry was tightly controlled sector. Competing airlines filed a suit claiming that 2 airlines are sufficient to cater to the needs of 3 cities SWA wanted to fly. These two airlines also threatened to not hire any employee who has worked for SWA. This resulted in the existing employees of SWA bond together and form a “rebel” group in airline industry. Eventually, the lawsuit was squashed and SWA was allowed to fly.

Culture –  Because of the difficult birth, the company employees have a family spirit. The employees really care of each other. ex: when an employee lost both his arms in an accident, the company founder Herb Kelleher kept him in the company roles so that he could get regular salary and medical insurance. The employee’s wife was so moved that she offered to help the company in whatever role she could help. She began by helping SWA provide the “personal touch” to all employee related stuff. She was so good at it that she finally retired as  HR head.

Culture –  They hired for attitude and not for qualifications. Since rival companies did not hire SWA employees, SWA didn’t have a large pool of talent ot hire from. So, they started hiring people from other industries. These new people did not have the baggage of airline industry with them and brought their own fresh thinking. This gave SWA a unique advantage unmatched by other airlines.

Culture –  SWA is a fun place to work. People’s creativity is encouraged. SWA is the only airline whose planes are coloured differently. i.e they do not have their own unique color. When they wanted to support a “water world” like aquarium in a city, they painted their plane to look like a giant killer whale. Some times they had christmas parties in september because september was only time when Herb and other senior members of the company were free!

Culture – SWA employees have “Can do attitude”.During a particularly difficult year, people figured out that only way to be profitable is to turn around a plane in 15 minutes. SWA employees understood the seriousness of the issue and they achieved a 10 minute turnaround!!

Culture – One of the few companies that believe in “Employees first, Customer second“. This does not mean they do not care about customers. Remember that they have the highest customer satisfaction amongst all airlines. It is just that the company does not put unnecessary restriction on their employees.  One customer complained that the hostess sang the initial “Here are the exit doors, the oxygen mask will drop in case of emergency etc….” announcement bit. The company rewarded the employee for making a boring task more interesting and entertaining as singing made more passengers actually listen to the instructions.

Culture- One of the few companies which treat all employees the same. In fact every employee irrespective of his experience has to spend one week as baggage handler or airplane cleaner. This creates the “respect” for other jobs in the company. The result – only company where the pilots and mechanics help clean the plane for the next flight. Only company where other employees chip in to remove and load baggage.

Culture – When the company was going through a bad patch, the Herb reduced his salary to 0 and asked his employees to reduce their salaries by whatever % they deemed fit. He gave details of the balance sheet and said that they need to cut expenses by 20% to remain afloat. Result, every employee took voluntary cut instead of seeing his fellow SWA employee being fired. The company compensated them with SWA stock. Currently about 10% of SWA is owned by employees.

The company culture enabled them to do things that other companies will fail to do.You might be sceptical about the above. How can culture make a company profitable? Well culture does not directly affect profitability…true,but it enables you to take measures that would fail if the culture is not present. Here are some examples –

Ruthless efficiency –  Most efficient operations. Every plane stays on the ground only for 10 minutes before it takes off for a new destination. Can you imagine? 10 minutes to get all passengers off, all luggage off, clean the plane, load new passengers, load new baggage and refuel the plane and takeoff. I don’t think we could manage to do that in a large car let alone a plane. 

Ruthless Efficiency – They have only one kind of plane Boeing 737. This helps them save money on training, spare parts and down time. If one plane breaks down another one takes over without a hitch.

Ruthless Efficiency – They never operate out of regular airports. They always chose low-cost alternative airports which are willing to offer the airline many hangers. Since some of these airports are down on business because of the “big” airports nearby, they are more than willing to get at least one airline. Result- Some of these airports are exclusively used by SWA.

I recently found a video that shows the culture of SWA airline –

As the above points show, it is a mix of great culture and eagle eye on efficient operations that keep SWA profitable. Indian airline industry has a lot to learn from SWA…for sure.

There are certainly a lot of things software industry can learn. Especially companies like CDC which are moving to agile and experimenting with empowering employees. What do you think? Do comment

Re-Imagining the hiring process…

One of the books that had an impact on me is “Re-Imagine!” by Tom Peters. In fact, when I was reading this book, I was tempted to post about it in our company intranet even before I finished reading. So, In all I have written about 3-4 posts regarding this book. This is the first of the posts…

I am currently reading a book call Re-Imagine written by Tom Peters. I have read only about 20% of the book but I am already tempted to recommend it. This is because, it sparked an idea in me.

 

So far, the book basically talks about how things are changing towards service. Having a great product is just the price for entry and great service is what makes a company successful. He also talks about customer success rather than customer satisfaction. More about this in a later post… after I finish reading…

One of the key points he tells is that we have to completely re-imagine the way we do things. Re-imagine everything to be successful.

 

In our current agile teams,there are always a bottle neck. Some times it is developers if the new feature being developed is investigation intensive or it is the testers if the sprint involves a lot of User Stories that have testing.  The agile methodology says that every member should be able to do everything. However, with our current setup, it is very difficult for a tester to learn coding and God alone can help our customers if we trust developers to do testing( Hey, I am a developer and I know how well we test :-)).

 

Even when we have opening now, we still seem to be hiring according to old department of dev,QA and Doc. 

Instead, we should re-imagine the hiring process and hire a ‘Agile team member’.  Since it is very difficult to teach an old dog new tricks, this new hiring process will work only for freshers.

 

Here is what we should do –

• Create a comprehensive aptitude test for freshers.
• One round of interview where the existing team members( not manager or lead) will interview the candidates. The team members select the candidates. This interview need not be technical in nature.

Once the candidates are selected, they are given 6 months to prove themselves. Their 6 months would involve doing the following –

• Learning about the product
• Start contributing to the team as a tester at the end of first 3 months.
• At the end of 6 months, they should have finished the following –
  • Learnt .NET
  • Passed a Microsoft certification. Company will pay the cost if the candidate passes
  • Create one cool project with the things the candidate has learnt. This project should be designed coded and unit tested by the candidate.Any standard project like “library management” or things like that will be rejected by the mentor immediately.

At the end of 6 months we have a truly rounded candidate who can do both testing as well as coding. I am not considering technical writing as it is rarely a bottle neck in the team.

Advantages-

• True Agile team member. No more QA,DEV,DOC business..
• We might just get a star amongst us. Since the candidate is still a fresher, the ROI for the company will be unmatched.
• We get 6 months to evaluate a candidate.

Disadvantages-

• A fresher might have ‘further’ studies in his/her plans and might quit soon.
• Management issues. If the candidate does both QA and DEV who evaluates the person. How will the appraisal process apply?

 

How does your company hire people?  Would the method I describe above work? Do comment

Why Agile is a step in the right direction

This post was written after CDC introduced Agile development methodology to do software development. After more than a year, I can confirm that the methodology works. We released two releses on time. CDC(Pivotal) had a dismal record of delaying releases before agile.

Before I start, I have to make a confession… I love Agile. I like the fact that the team can decide how much work to take up. I like the fact that the communication between various disciplines are very open. I love the fact that we all sit together and I can shout out to someone “Hey, you know I thought of a scenario…Can you try out and see if it works?”. He would try it out and tell me if the things work as expected or not. In fact,it makes me think “Why were we not following this before? It’s such a simple idea” . Anything that sounds like a simple idea in retrospect is a hallmark of a brilliant idea.

Peter F Drucker is considered to be father of management. I read one of his books “Essential Drucker”. This is not a book in the traditional sense, but a collection of essays Peter had written during his career on various subjects. This book is not for anyone looking for an easy read.I recommend this book only to the “seriously interested in doing MBA” category of people.I am hesitant to buy his other books as I fear I will not understand most of it.

 Anyway,one of the chapters in this book is about challenge of managing a knowledge worker. By the way, Peter coined the word “knowledge worker” in 1959 when there were almost no scope for a knowledge worker. He says, the primary contribution of management is to increase the productivity of workers.

The main issue is measurement.It’s a human tendency…If humans can measure, humans will improve in those aspects.

 How do you measure manual work? By the out put generated. ex:How many cars were produced in this shift? How many days does it take to build a house? All these factors are easily measurable.

Result – 

In the 20th century, management did very well, there was a 50 fold increase in productivity in manual labour. That is 5000 % increase in productivity in 100 years.They brought in a lot of innovations like assembly line, just-in-time parts delivery etc.

However, the main challenge of 21st century is to increase the productivity of knowledge worker.

How do we measure knowledge worker’s contribution?Can you measure a teacher’s productivity by the marks her students get? Can you measure a scientist’s productivity by the number of inventions he makes?

 Lets take software industry

Can you measure the productivity of a coder by number of lines of code he writes? I can write same logic in 2 lines or 10 or if I use some creativity in 100 lines. Can you measure quality assurance by number of defects he finds?All the QA people would want to test a fresher’s code since he is more likely to find bugs.

This has been the problem. Since it is not easily measurable, productivity levels have not increased the way it increased for manual workers.

 Peter says solving it would be the biggest contribution a manager can make in this century.

 I believe agile is the first step in measuring this productivity.

 Agile the first step

 I believe agile provides a way to measure productivity = in terms of velocity or story points. The points are associated with a user story by the team beforehand. So a team may commit to do work corresponding to 100 points this week. Now, managers can track this velocity and provide inputs to increase this to say 110 points by next release. That is a 10% increase in productivity. Now, manager can concentrate on a number… it is measurable, hence it is improvable!!

Managers should provide an incentive for the team to  increase its productivity. Maybe a nice bonus to the team that has consistently increased its productivity? This incentive would push  everyone in the team to develop more as a team. An individual cannot get this bonus by improving his own productivity. He would have to suggest changes to the way others work aswell for the team’s productivity to increase.

 I can think of a few flaws –

1)The team might increase the points associated with a user-story just to meet the increased point target.
2)One cannot measure productivity of a single member. The productivity can be measured only as a team.
3) The team can not change. If the size changes, it would be impossible to measure productivity till a baseline is set again.

I think the first flaw will sort itself out. The team members might be able to boost their velocity to 110 by bumping up their estimate. But, if they do, their target for the next release would be 120. I am sure at some point it would be impossible for the members to meet the target without improving their actual productivity.

 As for the other two flaws, I am not sure how they can be fixed. I am sure someone will think up another process which solves them. Maybe someone from India?   I am still not sure how we can measure productivity of a school teacher though… We cannot divide up her work into small chunks. Or can we?

I was wrong on the first flaw. I believe the teams are increasing velocity without actually delivering more to the customer. Hence, velocity cannot actually be used to measure productivity. We need to think up of some other way to measure productivity. However, I still love agile :-). Is there any move to measure productivity in your company? Is it Dilbertian or does it make sense?