Early on in any Agile transformation there will be people talking about teams, the 11th principle talks about self-organising teams. Now there are lots of recommendations and articles about what the team should look like, how big, what skill, and how to address team dysfunctions, even I have got in on this act here, and I am not going to go down that path now.
But once you have this team, ready and willing, how do you keep them fresh and motivated; and importantly for the parent organisation, how do you manage these people? It is trite to say, “they need no management, they are self-organised”. That is to wilfully ignore the practical realities of their context, which will often be within a larger organisation with objectives, hierarchy, annual reviews, performance management, training budgets, bonus pools etc. Whilst it maybe noble to preach that such practices are antiquarian and should be swept away in the birth of a new utopia… many people will look around them and hunker down, painfully aware that the second coming isn’t coming anytime soon, and when it does arrive, it will knock on their door last…
Given the constraints of reasonably standard HR practices, what can be done to ensure that the performance management practices support your agile transformation, rather than work against it?
What kind of people do you want working for you, and how can you assess people in such a fashion that the right type of people are rewarded and the development areas of each of them are identified? I really like this simple view:
So how do you find your “Team Picks” – does your annual review process really highlight them?
Many companies have an annual review cycle which, with the best will in the world, suffers from both immediacy and confirmation biases. In other words, given all the information now available to me I will award you the grade that I was going to anyway, unless something dramatic has just happened. Consistent behaviour contrary to my preconceived notion, that hasn’t had significant recent impact, will be ignored.
To improve matters I advocate two practices:
- Regular structured 360 feedback
- Team based assessment
360 Feedback
Within teams, have each member give feedback on one other team member each iteration, on rotation. By year end there will be a comprehensive assessment of each person, where each contribution is from a different premise, and has only be focused on recent events. It turns the feedback collation activity from an “year end” exam into “ongoing coursework”. Making it a continual activity also means that you can start to consider it in the context of what it takes to sustain your team, ensuring that this process is as sustainable as your automated test approach or your technical documentation.
Having done this the only caveat I had to put in place is that each person was to be assessed at the end of the year on the quality of the feedback given, is it full enough, is it balanced, is it actionable etc, without this the feedback will tend to either mutually assured destruction, or a collective congratulation circle – usually, thankfully, the latter.
Team based assessment
Secondly, you can assess the team collectively, where the only individual measure is an assessment of how much effort they have invested in supporting the team. How “teamy” are you. How much focus have you placed on “teaminess” to use two invented words. (this is in addition to the individual feedback assessment mentioned earlier).
A team assessment means that the team either does well or poorly, they should celebrate success together, or share the learnings, usually a little of both. When your peer does something great, you not only feel good for them but they share that feeling with you, because they know that you had a hand in it somewhere. This collective identity is permissive and contagious, once it starts to catch on, it typically grows deeper. This isn’t to say that every piece of work is shared amongst everyone, that would be onerous, but that everyone is happy with everything going on around them and would be willing to put their name under it.
We are social creatures and the ways in which we interact with others is often more important to our ultimate success than any innate talent in a specific area. Practices and policies that reward positive collective interactions will be beneficial to the individual and to their ecosystem. A team assessment will bring behaviours such as the most talented actively supporting the development of the least able and will help each individual ride out their own personal highs and lows. When you increase the sample size using an average, you will flatten out the peaks and troughs of success and struggle, and if you can get each team member to feel in line with the team, then you avoid any deep personal lows. Naturally you’ll also dampen the individual highs which might not be ideal for the person involved but can cause confidence / jealousy issues for their peers. In really mature Agile teams it is more than success that is shared, it becomes delivery, so at this point there is no individual high, because no individual acted or delivered without the contribution from their peers. This also helps avoid hero culture scenarios.
This type of approach really puts the hammer down on the kind of cultural ethos you are trying to promote and helps to show that you are placing equal emphasis on how work is conducted as much as the delivery result.
About me:
I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.
You can reach me at @philagiledesign or LinkedIn
philagiledesign 