Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I am writing a report which requires the analysis of performance of each individual team member in my team.

This is for a software development project developed using the Unified Process (UP). I was just wondering if there are any existing group appraisal metrics used so I don't have to reinvent the wheel.

share|improve this question

migrated from stackoverflow.com Jan 6 '12 at 13:53

This question came from our site for professional and enthusiast programmers.

    
In regards to the bounty on this question, I'd say that an answer would need to go beyond a simple link to the Programmer Knowledge Matrix (goo.gl/Cmfx)... –  Tiago Cardoso Jan 23 '12 at 12:39

4 Answers 4

Please don't measure individual performance - the team succeeds or fails as a unit. Measuring individual performance is somewhere between difficult (How do you deal with pairing? How do you measure the contribution of architects, designers or other non-coders compared to coders?) at best to divisive and counterproductive at worst, see "The Darker Side of Metrics" by Douglas Hoffman for examples of what happens when you try to measure software productivity.

Team performance is already adequately covered by existing XP or dX methodologies. If you want to do Agile with a UP foundation, as a previous RUP consultant I strongly recommend "dX, a minimal RUP process" by Grady Booch, Robert C. Martin and James Newkirk. It is no coincidence that 'dX' is 'XP' upside down! :-)

share|improve this answer
5  
If you don't "measure" individual performance, how do you give raises or promotions? How do you know whether someone should become a "lead", "domain expert", or otherwise senior member? Or is this excluded by the Unified Process definition? (I don't know much about UP) - or is your dislike of "measuring" only against concrete metrics that are known to be worthless for evaluating competence, like number-of-lines-of-code, or number-of-defects? –  Merlyn Morgan-Graham Jan 9 '12 at 10:08
    
@MerlynMorgan-Graham - Fox is right - that is the worst thing you could do. It would kill team work and effectively your projects. See my answer for details why and what you <b>should</b> measure. –  Danny Varod Jan 23 '12 at 16:32
    
@DannyVarod: FYI, I was playing devil's advocate :) Glad it spurred you to answer those questions yourself. –  Merlyn Morgan-Graham Jan 23 '12 at 18:53

I agree with @Fox that the individual performance evaluation might be dangerous and unfair, but if you still would like to do it - or you have to do it - then check on the 360 degree evaluation feedback (the wikipedia article). We used it with the addition that the evaluators had to put an ordered list together with the names of the team members including themselves. After merging the different lists and opinions together we had a clear view on the team members' relative (to each other) performance.

share|improve this answer
    
With all due respect, I think that "a clear view on the team members' relative performance" was exactly what your process was guaranteed NOT to provide. For relative appraisal, you need a common set of objective criteria. 360-degree is subjective. Say your star programmer stayed up late working on a tough problem only he can handle. He slept in, skipped his shower, rushed to work for a morning meeting the day folks wrote their evaluations? Would his talent, dedication and resultant slightly odd aroma not affect his relative standing on the team? We'd like to hope not, but can you be sure? –  ghoti Jan 20 '12 at 18:22
    
I learnt that when we are talking about evaluation it will never be objective. Even if you have criterias, people will fill out forms based on their feelings, impressions and views. For example, your manager asks you to rate your colleague about "how hard is she working" in a scale 1..5. What is 2 or 4 in this context? I'm I a 3, then she is a 2? Maybe. If the questions sound like this "Is she working harder than you?" than the answer is a bit more easy. + in our case almost 50% more colleague gave us the ordered list than filled out the previous survey. –  Zsolt Jan 26 '12 at 13:56

The are a few kinds of contributions e.g:

  • Analysis of problems and translation to UX, requirements
  • The production of design
  • The production of working code and unit tests
  • Creation of integration and system tests
  • Pairing up with another developer on his/her machine
  • Guiding another developer or reviewing others' products
  • Debugging bugs and fixing in any code (by any author)

Ideally, any developer should be able to get his hands dirty in any code, to get the work done - so measuring by metrics on area of code is wrong.

Measuring by lines of code is completely idiotic (sorry to have be the one to tell you this). See example here. The quality of the code matters - not the quantity. In fact shorter is often better.

Measuring by number checked-in components is wrong - doesn't account with non-coding work and pair programming (which happens all the time, even if not officially). Also this ignores quality.

The ultimate bottom line is team work, not the work of individuals.

The time spent guiding others is often more important than the time spent working alone.

If you reward individual performance you will be ruining the team work and making your projects fail in the long run. (See this link.)


What you should measure is things like (not a full list and not in any specific order):

  • Research and Innovations - self learning, solving (design or code) problems using unique thinking, introducing others to new technologies and methods
  • System vision (seeing bigger picture beyond single tasks)
  • Quality of design (maintainability)
  • Quality of code (readability, test coverage)
  • Completion of personal commitments on time
  • Responsibility - does the developer make sure outputs are usable and depended tasks aren't stuck and help others complete depended tasks when necessary
  • Guidance - does developer help others when possible if they need help or to maintain quality of teams outputs
  • Adaptability - willingness to consider changes and new ideas
  • Does developer take on tasks upon himself beyond his personal responsibilities
  • Communication - does developer communicate well with team

The above are important factors in deciding seniority, accomplishments, rewards and etc.


Team leaders should be chosen by team leading skills, not by coding skills. E.g:

  • Project management
  • Analysis
  • System vision
  • Guidance
  • People skills
  • Ability to listen to anyone
  • Ability to drive others, whether subordinates, bosses or neither
share|improve this answer
    
That's a very good and thoughtful answer, thanks Danny! Besides, I completely agree that less code means better code. –  Tiago Cardoso Jan 23 '12 at 17:34
    
+1 for demonstrating what you should be on the lookout for. How do you truly measure the things you're mentioning? Is there any scoring system that can be used for each of them? –  Merlyn Morgan-Graham Jan 23 '12 at 18:58
    
Yes, however not automatically. Many companies hold periodic performance reviews, prior to which all employees and their direct managers are required to recall (in writing - in brief) all they have done (including non-personal tasks) since the previous review and then grade themselves (using a non-numeric scale of 1...5) on the above according to what they have done. Each employee then meets 1:1 with his/her manager and the manager makes modifications as necessary (in both directions). Look up material on performance reviews for more details. –  Danny Varod Jan 23 '12 at 19:22
    
+1 for a detailed and thoughtful answer. The points of evaluation mentioned are same as I use for evaluation. Also very important is to give periodic feedback so that there is a chance of improvement and performance evaluation in the end does not come as surprise. –  asolanki Jan 26 '12 at 16:59

Measuring individual performance is critical, and part of an individuals measurement must be their own performance AND importantly how well they contribute to the team. The output and behaviour of the team is an aggregate of the output and behaviour of the individuals.

You should not blindly use metrics and I would agree with the other posters that blanket metrics use eg: lines of code per hour or number of defects per hour is a fools game. But, you need to measure their performance.

A team is a collection of individuals. If you treat your top performers the same as the bottom performers, your top performers will become disgruntled and leave while your bottom performers will get a free ride.

share|improve this answer
1  
Re: @Danny Varod answer - if I could I'd +1 the answer and comment - I completely agree and would flag that while Danny states "If you reward individual performance you will be ruining the team work and making your projects fail in the long run." - he then provides a list of ways to measure individual performance (self learning, introducing others to ideas, communicating with others, code quality, helping others, timeliness). All items that an individual does on their own AND that will allow you to measure their performance directly while also measuring how they contribute to the team. –  jasonk Jan 25 '12 at 5:43
    
Jasonk, I believe you have now enough rep to comment on @Danny's answer, removing this one. –  Tiago Cardoso May 4 '12 at 12:23

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.