performance feedback is one of those issues that seems to confound Traditional and Agile projects alike. Even with Agile projects, sometimes the Performance Feedback gathering is left out of the retrospectives. Frequently the Performance Feedback is left to the end of the project or at major milestones to gather feedback.
I have worked at Protegra for over 8 years. Protegra is an extremely collaborative company that embraces the principles of Lean (& Agile), but we have also struggled to capture high quality, timely, and meaningful information to assist in Performance Feedback. I played the role of Delivery Manager for over 4 years and we frequently struggled with trying to counsel people in regards to Performance Feedback for whom we had little information on. Since we are a project based company and we fundamentally do not believe in supervisors or managers, we also did not have roles that were solely responsible for gathering and delivering feedback. It was the responsibility of each and every team member to do this. So what did we do?
Just like every improvement, we did this through a series of small improvements. Rather than go through each improvement, let me recap where we are now. To summarize, this resulted in three areas of change:
1) Reinforce the terminology of Performance Enhancement to fit the intent and communicate the reason behind gathering the information
We have found that language is very important to communicate the true value of a process. Many people viewed Performance Feedback as being required for compensation. We re-inforced the language of Performance Enhancement and stressed it is about helping people improve on the competencies they want to improve on and that are important to the role. It is not a cookie-cutter approach where we fit people into a role description and rate them accordingly. This was a fundamental first step on the change. (And it is a continuous effort)
2) Create a Technical Performance enhancement Framework
The next step was perhaps the most difficult. We created a framework that recognized the true competencies of our culture, roles and team members that we are aware of. An important distinction was that these competencies were for our culture and roles and not positions. We don’t have positions at Protegra, but rather a variety of roles anyone can play on projects. Unlike other Performance Enhancement systems, this is a constantly evolving collection of competencies as new competencies and skills become valued at Protegra. Another key aspect was to ensure that the competencies also had objective criteria to be able to help assist people in the evaluation of the competency. Instead of just stating:
“Mike is a good .NET developer and has achieved an intermediate level of Programming expertise”
The competency framework will prompt the reviewer to evaluate competency aspects we incorporate in the terms “good” and “intermediate level”. For example, for the role of a Software Developer on a project these would involve providing grades on such aspects as:
– Use of SOLID design principles
– Use of Standard Design patterns
– Creation of Change tolerant code
– Creation of Automated Test Cases and test coverage provided
– Among others
This level of information is gathered on less frequent basis due to the amount of effort required. It is very important, but we still needed to capture information quickly and frequently that could feed into this structure.
3) Hold Retrospective Performance Feedback sessions “In the Round”
The most important aspect we then implemented was holding Performance Enhancement sessions “In the Round” as part of each and every retrospective. Unless the Performance Enhancement is incorporated into the process of the project, it will be left behind. Although people were apprehensive at first, as they become comfortable with the process and more comments and feedback was gathered. To be honest we have only recently implemented this process but the results are quite astounding. In this setting we also asked people to consider the following questions when evaluating their teammates:
– What can they do more of?
– What can they do better?
– What can they do less of?
– What can they do differently?
It is still a work in progress but the results are going in the right direction. I believe our approach again aligns with the Agile approach.
The largest realization I had was that holding Performance evaluation Sessions at the end of a project or during a considerable period of time is EXACTLY like having a User Acceptance Testing (UAT) phase. But we were rather having an Employee Acceptance Testing (EAT) Phase.
We need to attack the elimination of the EAT Phase is projects like we have eliminated the UAT phase. This validation of team members needs to occur daily just like our testing!
Re-posted from http://bornagainagilist.wordpress.com