Applying the Agile Canonical Form to write Performance Goals

In most companies, employees have to do some level of performance management. This typically involves each person writing performance goals. For those of you in companies that are adopting Agile (or even if you are not), as you think about your performance goals, one of the things to consider is applying the Agile story writing canonical form as the approach to writing goal statements.

For those of you unfamiliar with the canonical form, it is a language construct that many in the Agile community use to document their requirements (aka, user stories). This includes the role (aka, persona or actor) you are playing, your action, and the business benefit.

In many cases, each of us has a primary role we play within an organization. However, we may also have secondary roles that we play. The canonical construct includes the role so the roles you are playing in your organization or your product team can be effectively added. This may help in describing your goal more effectively. For example:

• As a Scrum Team Member, I will size the work using story points with the team during Sprint Planning, so that we gain team buy-in for scope and size of the story

 • As a ScrumMaster, I will exemplify Servant Leader attributes (and not command-and-control attributes) in order to help my team become self-organized

 • As a Product Owner, I will continuously groom and prioritize the Product Backlog so that the Scrum Team has a solid list of stories in which to work through

 • As an Agile Coach, I will coach and mentor the product team so they can adopt effective Agile methods

 • As an Agile Educator, I will ensure effective Agile instructor-led training is occurring throughout the company

Once you have the performance goal written in this form, then you can list the tangible tasks that make up the goal underneath.  You may consider this another interesting way to use the canonical form (which is usually meant to describe User Stories within an Agile context) for other benefits.

In summary, it is a good idea within a performance goal to identify the role you will play in relation to that goal, what is the action you expect to complete, and why you plan to do that action (aka, business benefit).  Using the canonical form can be an effective way to articulate the performance goal. 

Gaining first-hand insight into Employee progress within an Agile World

In the Agile world, some people find the performance review process a bit challenging and in some cases feel that it is unneeded.  Because we are moving from a more command-and-control environment to a team empowerment environment, a person acting in the manager role (e.g., functional manager, resource manager, etc) seems to have a harder time understanding what their employee is doing. Also, the manager needs to realize that when we move into an Agile world, discussion of performance should occur in a more collaborative manner with a focus on progress and learning.

Why does it appear harder? First, the employee is not (or should not be) taking work orders from the manager any longer and instead, the work should be driven from the product backlog (via the sprint backlog from sprint to sprint). Second, the manager actually does have less visibility into what the employee is doing since the employee should be 100% commited to their Agile Scrum team. So what should a reporting manager do? I’ve heard about conducting a 360 peer evaluation, but this is basically second-hand information. The question is, is there a way to gain first-hand information? What I recommend are the following ideas that can help a manager who has folks who report to him or her that are on an Agile (or Scrum) Team.

Let us start by considering the areas along the Agile process where a manager could gain direct insight into what the employee is doing. The two Scrum practices where a manager could listen into what their employee is doing is the Daily Stand-up and the End-of-Sprint Review.

• During the Daily Stand-up (aka, Daily Scrum), the manager can quietly listen into the progress that the Scrum team members communicate during this brief meeting. Before you do this, contact the ScrumMaster and verify that this Daily Stand-up is an open meeting that you may quietly attend. If you do so, ensure you tell your employees that you may be sitting in on the Daily stand-up. If you have employees on multiple Scrum teams, you may not have time to sit in on all Daily Stand-ups. Instead of sitting in on random Daily-standups, a tip is to attend the same Daily Stand-up for 5 consecutive days so you get an idea of the work done by your employee for a weekly period (for continuity and consistency). Since the Daily Stand-up focuses on what the team member did yesterday, what they are planning to do today, and their risks, you will have some idea of how story and tasks are connected to the work of the employee and how well they are completing the work.

• During the End-of-Sprint Review, you can potentially understand the employee’s progress by seeing what they demo (assuming the team members conduct the demo and not the Product Owner). If you learn that your employee is demonstrating work software during the sprint review, then you can quietly listen in to see what the employee built and how it works. Before you do this, contact the Product Owner and ScrumMaster to verify that you may quietly attend the meeting. If you do so, ensure you tell your employee that you may be sitting in on the End-of-Sprint Review for transparency.

You may notice that I emphasize “quietly” a couple of times. The key is that the Agile practices that I am talking about are not meant for the manager per se but for the purposes of building customer value and making progress through the project. The Daily Stand-up is specifically meant for the team members to communicate to each other on their progress. The End-of-Sprint Review is meant to gain valuable customer and Product Owner feedback so that we can ensure we are building the right product for our customers.

Next let us discuss other opportunities to gain employee insight  I suggest using 1:1s with employees to collaboratively discuss challenges, progress and learning needs but evolving it to become a continuous performance review.  These should be a low-key sessions that replaces the "big-bang" performance review.  During the continuous 1:1s, there should be an effort from both management and employee to be transparent and this should avoid any surprises when ratings or compensation matters are discussed. Ultimately, I would like to see the performance review process move away from the stogy and often negative intrustive event and evolve into a continous and collaborative discussion on progress and employee needs.  

What do you think of these ideas? Are there other ideas you have seen work successfully where a reporting manager can gain first-hand insight into their direct reports without obstructing the progress of an Agile project or the employee themselves?