As a practitioner of the Agile way of working, most of my actions, techniques and experiments were driven through “common sense” and the “ground realities” of the team, team members and organizations with which I have worked.
I would like to describe one experiment where I attempted to change the way individual and team goals were set, and change the way people got appraised against those goals in large, product organizations. It was fairly successful and worked as an important element that drove effective Agile adoption.
Traditionally, most companies have their performance management models built on age-old principles and frameworks that don’t adapt to organizational changes. More concerning is the way organizational goals and an individual employee or team goals are linked to each other. I have seen many loopholes in aligning individual goals with organizational goals. The disconnection exists at various levels.
While this is a story about companies with traditional approaches towards software development, could you imagine what happens when such companies try adopting Agile? They utterly fail because of lack of attention to the aspect of goal-setting and appraisal models. In fact, Agile trainings and initiatives drive the employees in one direction and annual goals and appraisals drive them in exactly the opposite direction. This is because the measurement metrics for both aspects differ and don’t compliment each other.
In my experiment I mentioned above, I dealt with the above situation more as a change agent, rather than as a ScrumMaster or a development manager. Let’s look at a couple of example goals before and after an Agile mindset.
Goal setting examples
Sample goals and their measurement metrics set for a Sr. Software Engineer before Agile adoption strategy was changed (click images to view larger versions):
The above goals were not only unclear and difficult to achieve in an Agile environment, but were also very difficult to measure and to appraise employees.
The funny part was about goals for other roles. For example, the goals for a Software Engineer were 90% the same as above (literal copy/paste) with one or two items missing. The goals for a Tech Lead were also same, with the addition of a couple of new items on management aspects.
Now, let’s look at how I reorganized and redefined the same goals for the same Sr. Software Engineer role as part of a strategy to adopt Agile better.
Same goals and their measurement metrics redefined and reorganized after Agile adoption strategy was changed:
Through the above examples, I would like to convey to the readers of this article that changing the way goals are set and appraisals are conducted can significantly affect the effectiveness of Agile adoption at an organizational level.
Here are the three aspects to be considered while revisiting “Goal Setting and Appraisal Strategy” in the Agile world:
1. Performance management model
- There has to be a “Team Component” that ties all individuals to focus more on collective outcome, and it has to be considered a major piece of the pie in bonus/increment.
- Individual employee goals should be aligned with organizational goals to suit the Agile mindset.
2. Gathering input for appraisal
- A 360-degree survey should be conducted to get transparent feedback from each member about every other team member.
- More open evaluation techniques should be used while measuring Agile practices maturity.
- Team-level feedback should be collected from the product owner and ScrumMaster based on their observations of the team over a period of time (across multiple sprints). That could reveal valuable insights in terms of improvement in teams’ self-organizing ability, commitment exhibited during demos and quality focus shown in terms of “definition of done” adherence.
- Key Agile metrics like sprint velocity and burndown charts should be considered for team evaluation.
3. Providing feedback more frequently
- Instead of waiting for formal annual or semi-annual performance review meetings, key stakeholders and managers can meet the team and individuals one-on-one after every sprint or every alternate sprint. They could use this opportunity to make course corrections if the goals are off-track for any team member or for the entire team.
- Also, based on empirical data and changes in organizational priority, goals can be refined or revised once a quarter or once after every sprint release.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.
Like this? You’ll love Agile Eats
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!