In a short series of posts we will outline the step by step journey from traditional performance management (such as 360-degree appraisals and cascading goals) to agile performance management (such as continuous coaching, quality conversations and micro feedback).
This introduction will use lessons learned from software developers in their adoption of agile approaches to help plan your route.
Whilst the idea of agile performance management is quite new, it has many parallels with the more mature practices of agile software development. In particular a number of pitfalls can be avoided by examining the failed attempts at agile software development versus the successful ones.
The first lesson we can learn is that agile does not mean a free-for-all
A common misconception is that agile means unplanned, uncoordinated or unmanaged work.
This comes about because with agile approaches there is a reduction in formality, documentation and hierarchy, and an increase in personal accountability, conversation and collaboration.
Contrary to being a free-for-all, what agile recognizes is that there are likely to be many ways to achieve an end result. Not all of these may be apparent from the start. More significantly, a better end result may emerge as we get further through the journey and the landscape around us changes.
Agile approaches capitalize on this with short cycles of activity resulting in the delivery of meaningful work followed by just in time (re)assessment of priorities for the next cycle. In successful agile software development teams you will see daily check-in's that update on progress against personal commitments and highlight any potential roadblocks to success.
In the context of agile performance management this means that cascading organisational goals once a year, and reviewing achievement every 6 or 12 months is too rigid and far too slow to cope with the pace of change in modern business. A much shorter goal setting to appraisal cycle is needed. Experts argue about ideal frequencies but the argument is whether weekly or monthly feedback loops are adequate. No-one is arguing the case that less frequent feedback is better.
From Waterfall to Agile via Wagile
When tasked to change from traditional "waterfall" software development to agile software development, most software development teams could not make that change in one leap.
Many came up with their version of Wagile development as a hybrid approach.
The rationale for Wagile was to introduce some powerful concepts of agile whilst maintaining some of the familiar aspects of waterfall. In successful transformations Wagile was a stepping stone to fully agile methods. In other cases Wagile has become the final destination. For these organizations the potential benefits of truly agile methods have been lost.
It's the same scenario with your leap from traditional performance management to agile performance management. The process change is one thing, but the change in culture, competencies and tools is a whole different level of complexity, and one that takes time to fully accomplish.
In your journey to agile performance management there is an important decision to make about your need for stepping stones. The key question if you transition via a hybrid approach is how to ensure that this doesn't inadvertently become your new normal.
The lesson here is that Wagile is a nice place to visit on your journey but you don't want to get stuck there forever.
Done
Agile has a strong emphasis on completion of commitments.
To avoid any wiggle room it's common for teams to define what needs to be accomplished before a commitment can be declared as done.
We recommend defining those things that will test if your journey is complete; those things that make it crystal clear if you are done.
By way of example just some characteristics that we measure are
- Participation Rate - what percentage of all employees are actively engaged in performance management
- Participation Frequency - what is the median time between performance assessment/feedback events
- Sentiment - what is the overall sentiment of staff, are they in the flourishing zone of positive to negative feedback
- Relationship Distance - what is the minimum number of people that need to connect person A with person B
- Reciprocity - is there balance between giving and receiving feedback
- Anonymity - is the level of feedback given anonymously healthy
- Request Volume - are people asking for feedback, seeking to improve
The metrics that matter to you will be unique, but starting with the end in mind is critical to completing a full transformation.
Creating your route plan to Agile Performance Management
You will have a great roadmap to take you from traditional performance management to agile performance management by
- being crystal clear about your definition of done,
- implementing a lightweight governance approach to keep focus on your immediate next priorities,
- checking you're on the best bearing, and
- identifying the stopovers that you may need to make to complete your journey without fatigue
Of course, any plan is only as good as the execution of it. As the time comes to start your journey, the team at Pay Compliment make excellent travel companions and navigators.