go to content go to search box go to global site navigation

Tech Blog

Agile Evaluations

Our team has been interested in trying to figure out how to measure our ability to improve both personally and as a team. Our teams purpose is to deliver high-quality software as quickly as possible. This is hard to measure, so the next thing to consider is what the best proxies are. We decided that we would instead measure and improve each developers skills and hope that this would lead to team progress.

A traditional way to accomplish this is to have a manager (me) sit down with each of the team members and talk to them about their goals and their shortcomings, but the reality is that the other members of the team spend much more time with each other than I do. I asked each person on the team in private if they were comfortable with the idea, and we decided that we were comfortable with each of the team evaluating each other. We all agreed that we would be HONEST and that it would be ANONYMOUS.

As a team, we decided on some attributes of a good developer that we believe lead to delivering high-quality software quickly (the criteria are listed at the bottom). Then I built a survey form, and had each person in the team evaluate each other (and me) based on these criteria (N/A, Needs Improvement, Adequate, Above Average, Badass!).

Then I gathered up the results, and had one-on-ones with each person and we talked about the areas where they were doing best and the areas where they were doing worst. Each person chose one area to focus on and we will see next time how we are all going.

As with all such things, we have made a number of minor changes to the process for next time, and it will continue evolving as the teams' needs change.

The criteria we chose

  • Makes others look good
  • Knowledge sharing
  • Team success over individual (ego suspension)
  • Pairing/Collaboration
    • Open minded
    • Seeks opinions
    • Active participant
    • Good at listening
    • Keeps pair on track
  • Open communication
    • Gives (effective) feedback
  • Knowledge sharing
  • Code quality
    • Good code structure
    • TDD
    • Simplicity
    • Leaves things better than you found them
  • Doesn't chase rabbits down holes
  • Passionate
  • Communicates effectively outside the team
    • Within the business
    • Within the community
  • Doesn't reinvent the wheel/uses external resources where appropriate
  • Continuous improvement/learning
Published