I was just reading an article on performance appraisals by Shane Hastie. It is a good summary of some of the issues that traditional performance appraisals cause on agile projects.
But it leaves two questions unanswered:
- Where would you start if you actually had to do a performance agreement; and
- How would you actually know what was expected of you if you didn’t?
The situation is made worse, according to the links in Shane’s article, when you want the team to be jointly accountable for shared success rather than individual success. This is important if you want to work out how to evaluate testers or BA’s for example, because their purpose is to make the team successful rather than to stand out on their own.
So here is my first attempt at a pragmatic performance agreement:
Performance agreements are conversations rather than documents
Rather than trying to write out a performance agreement, just ask yourself these questions.
| Who benefits from the work I do? |
|
| How else do I add value to the organisation?
|
|
| What currently gets in my way?
|
|
| Based on all that, what needs to happen for me to be successful? |
|
| What is changing or could change in the future?
|
|
When you are done, ask your boss and key stakeholders the same questions. I suspect that each person you speak to will have a different view and this should highlight a number of key issues that you need to resolve, that would not normally be picked up by a written performance agreement.
Of course, you can and probably should document your performance agreement now:
Fill in details below
| My role is | |
| Which means that | [I create (or maintain or mitigate) {blah} so the customer/organisation can {blah}; or
I provide {what} to {who} so that they can {blah}. Without me they would have to {blah} |
| My top 3 – 5 responsibilities are (in order) | 1.
2. |
Now go back and check what your boss and key stakeholders think. Don’t let them off the hook though, push them to rank your responsibilities and add as many as they want, subject to then listing which are the top 3-5.
You can then add option fields to add more depth to the agreement if you want still greater clarity and focus.
| For each responsibility: |
|
| Add another “responsibility”.
|
|
Obviously this is hard. But I think it will highlight the key expectations you and others have for the work you are doing.
But now we have a baseline, you want to use this baseline to review your progress and also adapt to the inevitable changes that are occurring every day. Read my OODA loop article and see if you can find a way to apply this to your continuously evolving performance targets.
This last bit is hard so maybe you can find a better way. Otherwise this whole thing is just a starting point for more conversations with your boss and stakeholders. But then I guess that is the point, we want to have a starting point to orient ourselves and then we want to continuously improve the conversations we have.
James King 