Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When my Manager told to team that "now onwards successful user stories will be considered for appraisal!"

We sat there for while shocked and that was one of the several jaw dropping moments he gave us :-)

We felt that was stupid idea, since this will ruin all concept and goal of agile development methodology.

Let me know what you people think? and how can we convince him?

share|improve this question

5 Answers 5

up vote 8 down vote accepted

Sandy, unfortunately your manager's statement is a classic misunderstanding of scrum in particular and agile in general.

The proposed approach kills collaboration and counters the principle of collective code ownership. User stories in agile (if it is a real agile) rarely get completed before being touched by multiple people. Also, you will have user stories from time to time that need swarming in order to be finished within the iteration. How are you going to all get that when the individual incentives are aligned 180 degrees in the opposite direction?

Your teams instincts are correct. What sources would I suggest in the short term for you to read as you brainstorm the response to your manager? Look at blogs of renowned agile experts like Mike Cohn, Martin Fowler, Elizabeth Hendrickson, Jurgen Appelo, Esther Derby and several others and look for articles about agile team organization.

share|improve this answer

My main objection to this method of assessment is that it can be an obstacle to co-operation between developers. I think that an important part of the productivity of a development team is the willingness of team members to help each other. As I understand the suggested scheme, it could lead to developers sticking with their own assigned tasks and ignoring other team members who are stuck and could easily be unstuck by a little assistance.

We are always looking for the contribution the programmer is making to the team and the business.

share|improve this answer
    
I totally agree with you. –  Coder Hawk Oct 25 '10 at 12:58

This is on a par to measuring lines of code, or number of bugs - but slightly more sophisticated.

At first glance there's nothing wrong with the measurement, but when you think about it you start raising objections:

  • what about more complicated stories?

is the most obvious one that springs to mind - I'm sure there are others.

You manager obviously thinks this is a good idea, so you need to be careful that when you raise objections you can also present solutions. This solution might have to be a modification to his scheme rather than a new scheme.

So for example you might want to point out that someone who just works on "easy" stories will complete more than someone who works on a more "difficult" one and this might lead to a concentration on the less important aspects of the development. So one solution might be to consider the number of story points rather than just the number of stories.

share|improve this answer
    
If you think in the way of raising objection and taking accountability then its fine. We thought about story points too, but in most cases one user story is split into more than two tasks according to sprint and each tasks are carried out by different members; then appraising on story points won't work! what you think? –  Coder Hawk Oct 25 '10 at 12:23

I agree with ChrisF that this goes back to the same problem with any measurement. What you praise is what you get. There are always going to be people that game the system, whatever that system is going to be.

The only real effective method that I've found for rewarding programmer's comes with three steps.

  1. Leads know and understand the abilities of the people on their team.
  2. Managers listen to the recommendations of the leads for team members who aren't pulling their weight.
  3. The team is praised as a whole for successful sprints.

The entire key is that programmer's are not cogs in a machine that can be 'tuned' by looking at statistics. The real people need to be examined and improved as whole and the team needs to be able to rely on each other in a cooperative, and not a competitive manner.

The poor performers on the team are given every opportunity for improvement and enrichment before they are considered to be let go. Ultimately, good programmers will thrive in this environment and the poor programmers, who refuse to be improved, will be let go.

share|improve this answer
1  
+1 - for "The team is praised as a whole for successful sprints." –  Coder Hawk Oct 25 '10 at 13:05

Most of the time, User Stories are completed in a collective effort. This makes it virtually impossible to base individual appraisal on this metric.

The metric itself can be easily manipulated since the planning process is also a team effort and even sooner than later, the whole system gets rigged. That's definitely what you don't want in a people focused process.

I think good performance has to be recognized by some kind of bonus system based on team success, but User Stories are not a good indicator of success.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.