One thing every Agile methodology has in common is the concept feedback loops, and ideally, fast feedback. These feedback loops can be internal or external and can take place at varying intervals. Feedback can be received from customers through UAT (user acceptance testing) or following the release of a product increment. Alternatively, feedback can be received from the Development Team/internal stakeholders through events such as Sprint Reviews, Sprint Retrospectives, Sprint Planning and the Daily Scrum. This feedback allows improvements/changes to be made to the product or the processes being used to deliver the product.
One process that many of us go through that rarely features fast feedback loops is the annual PDR (performance development review) process. The PDR process is a personal feedback loop where objectives/goals are set and are attempted to be achieved prior to the next review, before inspecting and adapting and setting the next set of goals.
In my previous roles the PDR process was one that we went through twice a year and it generally had two elements. Firstly, we looked at the objectives that were set at the beginning of the review period and secondly, we ask for 360 degree feedback from managers, peers and those that report to us.
In the weeks leading up to the review meetings with line managers, the focus of many moves away from the day-to-day delivery of the product increment to achieving one (or more) objective in order to sign off the objective as complete and in some cases, secure a bonus payment. This can slow the flow of user stories being developed as well as increasing cycle time (the average time it takes for user stories to be delivered) and causing a reduction in velocity.
Asking for 360 degree feedback for a six month period has its own difficulties. Can line managers, peers and direct reports remember what you as an individual were doing six months ago? And, if there were things that could have been addressed, why were they not mentioned sooner?
The annual or bi-annual PDR process is not agile. Some feedback may be shared/received through events such as Sprint Retrospective, but this is generally limited at an individual level, with the Development Team looking to identify how they can improve collectively. It is more likely that actionable feedback will be received through 1-2-1 meetings with line managers, however, this may be just one persons view rather than the feedback of many.
In order to make the PDR process more agile, it is necessary to more away from longer term objective setting. Due to the environment that we work it, it is often the case that objectives set six months ago are no longer relevant or achievable by the time it comes to be reviewed due to a change in priorities. If an out of date objective was an item in a Product Backlog, it would be dropped in favour of something that would deliver greater value.
It is my suggestion that personal objectives be set that allow for faster feedback and the ability to inspect and adapt. By setting one personal objective per month it would increase the chances of that objective being achieved as well as reducing the likelihood of a dip in team performance once/twice a year.
This type of objective setting may make it easier for knowledge sharing to be undertaken or process experiments to be run. It is also possible that objectives could be linked to longer terms actions identified in Sprint Retrospectives.
By setting only one objective it will also prevent the need for individuals to context switch or multi-task their objectives. We would not expect members of a Development Team to be working on four, five or six user stories at the same time, so why should objectives be any different?
Over the course of six months or a year (whatever your PDR cycle) the output from the individual monthly objectives can be collated and produced as evidence without the need for that drop in team output.
So at your next PDR, why not suggest only setting one objective that will be achieved over the course of the next month. You can then look to review progress in a months time and then, inspect, adapt and set the next objective.