Rewarding individual contribution can kill Agile

Nearly every place I’ve worked at would hold regular company meetings where employees were rewarded with a small token of appreciation, recognising exceptional performance or exceeding expectations in some way. It’s a nice thing for companies to do but it might seem counterintuitive to reward individuals while adopting an Agile culture. When you aim to build collaborative teams, perhaps one person standing out might be a cause for concern rather than celebration. 

It is a popular belief that rewarding individuals encourages the same behaviour in their fellow team members, which subsequently boosts overall team performance. This is known as the recognition spillover effect. I’m not convinced this always has the desired results as it’s quite a simple notion that doesn’t account for real-world complexities and emotions. For instance, I can imagine that if a team member feels they were more deserving of a reward than their colleague who received it, they might be demotivated by the lack of recognition. 

Using individual rewards as a means of improving teams is also particularly inefficient. Consider that the variation between the lowest and highest performing individual is 10x, but the variation between the lowest and the highest performing team is 1000x. It’s clear that focusing on boosting team performance will yield a greater, more rapid return. 

I’m often asked to nominate Scrum Team members for a ‘Star of the Sprint’ award. As a Scrum Master and an advocate for building an Agile culture, I’m more tuned into team successes than individual ones, and feel a bit uncomfortable singling out one team member. I'd much rather another team member or stakeholder nominate those who'd helped them directly in their work. Otherwise, it feels like I'm speaking on someone else's behalf and I’m sure the explanation would be much more meaningful coming from them.

When Scrum Masters are the ones putting people forward for rewards it’s usually to fill a void when nominations from others haven’t been forthcoming. Scrum Masters hope they can lead by example and encourage others to nominate their colleagues for rewards. In reality, others may come to expect that Scrum Masters will take care of it and rest on their laurels instead.

So how can rewarding individuals conflict with Agile? 

It may be difficult to see the harm in rewarding the best performing team member (which may explain why a lot of organisations still do it). Surely everyone needs to feel appreciated on a personal level even if they are part of an Agile team. However, if Agile team members are rewarded individually, extra care needs to be taken to avoid encouraging unwanted behaviours.

“Rewards need to be carefully designed to be consistent with Agile’s emphasis on teamwork.” - Mike Cohn, Mountain Goat Software.

With this in mind, individuals shouldn’t be rewarded for actions that the whole team is accountable for, like delivering a piece of functionality. If that's the case, you should question why they were working alone rather than collaborating. 

Individual rewards can encourage heroics from those who are keen to be hailed for saving the day. They could also encourage those who are easily distracted from Sprint work when there’s an interesting problem to solve. Neither of these behaviours demonstrates good teamwork and the team as a whole should be accountable for the work, succeeding or failing as a collective. When someone is motivated to take personal credit for a piece of work, they may reject the idea of collaborating through pair programming, etc. This prevents knowledge and skills from being shared amongst team members and could lead to knowledge silos and bottlenecks which limit Agility. 

Working with a Sprint Goal

I’ve worked with Scrum teams who have failed to meet a Sprint goal while one of their members was rewarded for unrelated work. Celebrating an achievement made at the expense of the team’s Sprint goal sends the wrong message regarding the most valuable outcome. The Sprint goal should deliver the most valuable, highest priority outcome. The team as a whole commits to it and all team members should focus their efforts on achieving it.

I’ve witnessed team members being rewarded for “going the extra mile” and working overtime to deliver something time-critical. The prospect of this behaviour being normalised makes me nervous, as a culture of overtime doesn’t support the Agile principle of sustainable development, where teams aim to keep a sustainable pace. Overtime might be called for on occasion but it shouldn’t become a habit. Team members should be encouraged to ask for help rather than plough through the work alone.

You might be thinking this is a minefield and perhaps it’s easier to keep rewards to a team level. However, there are other ways to show appreciation on an individual level without encouraging negative team-destructing behaviours. While managers can deliver positive feedback through performance appraisals, appreciation from within the team can be more powerful. It has the benefit of increasing the bond between team members and accelerating team maturity.  

There is a solution – it just takes the right conditions to facilitate appreciation between team members. 

Agile Retrospectives provide the perfect conditions for the team to show appreciation for each other. They are all in it together, or certainly should be, as the event is mandatory. Attendance of company meetings may be optional and I've noticed some people don’t attend. It's perhaps one meeting too many for some and non-attendance can easily go under the radar (unless someone is absent when they are called up for a reward). 

By the time the retrospective rolls around, the Sprint work is finished and the team has had time to fully consider what they value in each other. You can build some quiet reflection time into the retrospective, a luxury that doesn’t usually exist for other meetings. During the Sprint, team members get engrossed in their work and often don’t stop to consider what they appreciate in their colleagues. I found that nominations for company rewards would be requested at the busiest time when teams were focussing on getting the last of the Sprint work finished. This resulted in a lack of proper consideration and a bias toward the most recent and easier to remember events. Good work from earlier in the Sprint would sometimes go unrecognised.

In retrospectives, there’s no cap on the number of team members who can receive appreciation, or how often. With company rewards, the most deserving team member might be vetoed based on previous wins. It might also seem like the same people always get nominated; perhaps they are the most deserving or maybe the same people nominate the same individuals each time, limiting the nominees to those they work with closely.

One of the most valuable aspects of retrospectives is the safe space they provide for the team to be open and honest about their personal challenges and celebrate each other's ability to overcome them. They perhaps wouldn’t want attention drawn to their personal challenges outside of the team, but appreciate it when their teammates recognise their progress.

How to facilitate appreciation during retrospectives

Many of the popular retrospective formats focus on what the team did well and what it could improve on. While individual team members might get a mention under the “went well” category, they tend to be more geared towards the team as a collective. 

There are a few options for incorporating appreciation into your retrospectives. You could plan it as a separate opening or closing activity or add it as another category to any existing format. Perhaps don’t try and include it in the acronyms though, the 4Ls retrospective won’t have the same ring to it once you’ve added an A. I’ve noticed some variations on existing activities where appreciations have replaced another category. For example, there’s an adaptation of the FLAP activity (Future direction, Lessons learned, Accomplishments and Problem areas) which replaces the P for problem areas with a T for Thanks (making it FLAT). While this is very positive, it could be a missed opportunity to discuss problem areas. 

Some retrospective activities encourage everyone to participate, for example, 360-degree appreciation (sometimes known as a round of admiration) where every team member writes down what they appreciate about each of the others before taking turns to receive their appreciations. However, it might not be the best activity for newly formed teams. Some team members might not feel comfortable with it if they don’t like being the centre of attention. 

Scrum Masters can add more value to appreciations by using them to reinforce Scrum values. They can encourage the team to reflect on behaviours that demonstrated the Scrum values of openness, courage, respect, commitment and focus. Scrum teams could also consider how the actions of their teammates have improved the cross-functionality of the team or its ability to self-manage. Perhaps someone instigated the resolution of an impediment, removed a dependency, helped others learn a new skill or encouraged swarming on a difficult issue. 

Kudos cards could be used throughout the sprint, with team members using them to write messages of appreciation which they present to each other at the retrospective, with some teams posting them up on a board. This has the benefit of recognising things that happen earlier in the Sprint which might be forgotten by the time the retrospective comes around. 

Conclusion

Rewarding individual members of an Agile team does require care and attention as it carries the risk of promoting behaviours that contradict Agile principles and cause friction within the team. Rewards are a method of showing appreciation, but what motivates most people is the recognition from their peers, not the physical reward itself. For Agile teams, appreciation from within the team is really valuable as it helps the team to strengthen their relationships and improve collaboration. Retrospectives are the key to facilitating this positive recognition.