Sunday 14 August 2011

Evaluating Software Teams


There has been a very interesting discussion on one of the LinkedIn groups I belong to on evaluations of team members for Software Teams and how to go about it. If you manage a Development team you'll know the answer isn't as simple as comparing producing features against the number of bugs, it's far more complicated than that.
Often there is little in software development to quantify and you are working with as many different people as you have team members. They all have differing levels of skills and different personalities. Even the area of applications they work in will make comparing production to other team members almost impossible. 
Developers can knock over 20 bugs and add 3 new functions in a one day but spend the next week trying to resolve a single bug. Performance against sheer production is just not an option. 
Managers need to look at other options. 
To properly evaluate, managers must be able to repeat the same evaluation 6 months later and compare the two to see if the individual is performing better than he/she was in the first evaluation, so the evaluation must be against something that is quantifiable, repeatable, comparable, and understandable. 
Luckily there are things that you can use other than functions vs bugs. You can evaluate items like:
  • Standard of dress (programmers turn up in tee shirts - but are they clean and non offensive). 
  • Attendance to work during required times and hours. This will include calling in if late for any reason. 
  • Attendance to meetings 
  • Quality of documentation and testing 
  • Time to respond to a request 
  • Ability to get along with the others in a pleasant and non-disruptive way 
  • Ability and willingness to help out others with mentoring. Includes things like contributing at meetings. Must be weighed up with doing their own work. 
  • Following the correct process 
  • If customer interaction is involved, how many complaints and compliments. 
  • Desk tidiness (mine is terrible so I have to make a real effort to tidy it every couple of days). 
  • Willingness to take on new work. 
  • General attitude 
  • Attitude to change 
  • Clarity and effectiveness of documentation
Try marking these out of 5 (5 being the best). Try to keep them all around 3 so that areas of discussion and commendation are easily highlighted.
After this the manager can make general comments on their assessment of the team member's skills. This part however is very subjective so must be introduced as comments only discussed behind closed doors and something for them to consider, but its not anything that can be quantified so it can't go into, say, consideration for a bonus. 
Try not to compare team members against others - this is THEIR evaluation. It's also not wise to evaluate the team itself - the team is where YOU will be evaluated, not the individuals. 
Your comments?

4 comments:

  1. "Performance against sheer production is just not an option."
    It can be one metric, why not? It is not an option in short term. But longer term (3/6/12 months) this is quite ok. And it is very cheap to measure.

    As for clean desk - I would find clean desktop, email folders etc. more important.

    ReplyDelete
  2. Hi AndrejV,
    I have never been able to define a specific metric that can be used to effectively evaluate development production in a software development team member. People do have different skills and sometimes these can relate more to knowledge of the application's code than to their personal skill. For example, I have worked in a very large corporate application where I was involved in various areas of the application as one of the team's senior developers. In those areas I was extremely productive, but move me to another area where I had not worked, and I would become a junior programmer until I learned the code and understood the application area.
    A developer may also be working in an area that is reasonably easy to look after with originally well designed structure, while another may struggle in areas prone to problems due to several reasons including a bad original design (neither was involved in the design, just in the upkeep and enhancement). Is it fair then to grade the easier job as a better developer with higher skills?
    I am intrigued though and would very much welcome any suggestions that you may have. If you have found a way then please can you share that. I learn new skills every day from others and am very oen to hearing of your experiences.
    Thanks. Steve

    ReplyDelete
  3. What is the point of discussing T-Shirts? If the Business needs (for some reason) for you not to wear T-Shirts, it's a simple business matter. Productivity Metrics are crap. Business discussions should be business discussions, not pseudo-math done as a pseudo-science.

    Retrospectives matter. Retrospectives are about "how do we improve our process for doing software"? What went well, and what did not go well and what are we going to do better. Forget numbers from 0 to 10 or 0 to 5.

    Warren

    ReplyDelete
  4. Software developers are people and sometimes they come to work in a attire that is casual, there must also be a appropriate attire for them so that they will look nice and presentable to some...


    cafe software

    ReplyDelete

Note: only a member of this blog may post a comment.