10

I've seen individual evaluations for programmers done reasonably well, and horribly wrong. If leadership only ever evaluates a team as a whole, then that team has no way to reward individual initiative and identify/remove personnel who are detrimental to the team. However, if leadership treats the team members only as individuals, they stop being a team. ...


9

TL;DR You already know you shouldn't do this. However, if you must do it, focus on team integration and support of team values, rather than trying to perpetuate the 100% utilization fallacy or applying irrelevant metrics like lines of code written or bugs stomped per iteration. If the person makes the team better or the process more effective, then they ...


6

First Off: Don't tie whatever you do to any form of compensation decisions. As soon as you do this you will get 100% gaming of the exercise. Measuring individual performance is very difficult and probably more costly than the derived benefit. But if you must, I'd recommend some type of peer appraisal process (aka a 360) combined with having the developer ...


5

What I have seen tried: Measuring story points achieved by a developer - As soon as this was introduced the developers stopped talking to each other and focused only on the story they were working on. Output of the team dropped. Peer review / 360 feedback - This was rapidly gamed. Team members talked privately and made deals. Often reviews were ...


5

As you mentioned yourself, this is a difficult situation. There are a lot to say about it but I'll try to advise on some of the main points I see. Information You say you are new to the company. In two months you probably haven't gotten the full hang of things. And you now also have this situation you are asking about with conflict between team mates. Most ...


2

If you look at the news from some of the largest software and consulting companies you still see trend of not going individual appraisals. Individual appraisals kills self organisation and both the performance of your team and the quality of your code. I would have a serious conversation with the CEO about what what his goals are. If he wants high ...


1

I think the process of scoring and prioritizing projects, no matter its size and complexity, should generally be the same; however, based on size and complexity, the authority at different clip levels, the rigor and formality, and the controls would be different. For example, a business case for a $30,000, 8-month project might take all of two slides while ...


1

There's this eBook available on Google books. There's this book which is unrelated to computers that you can buy and preview on Google books. Here's another book you can buy and preview on Google books. Here's a 60 page PDF you can download on the subject. Here's a book you can buy on the subject. Here's an eBook on the subject.


1

This is known as a 'Lessons Learned Log' and if you Google this term you will find many definitions, discussions and even templates.


1

The most important thing is that the team is as productive as it can be. Measuring individual performance is not very important within Scrum. Scrum teams are supposed to be self-organising, so different team members make take slightly different roles. For example, I worked on a team where senior members of the team would take the "harder" bugs, but they ...


Only top voted, non community-wiki answers of a minimum length are eligible