How do you reward within an Agile Team culture?

The primary notion of rewards within an Agile culture is that the team shares the success or failure of the work they are doing.   The driving principle is that unless we all succeed, none of us succeed.  There are advantages for rewarding at the team level.  Rewarding by team promotes the Agile team culture.  Team rewards promote and encourage team members to help each other out.  Trust is built when individuals must come together to share information and collaborate. This can work well except that it leaves no room for individual focus and can leave some top performers feeling underwhelmed.  So the question is, is it so simple to say that we “only” reward as a team?

It is true that some team members will align with the Agile culture quicker than others.  Also, some team members will, in fact, contribute more than other team members.  And maybe sometimes, it is important to acknowledge exemplary work when it occurs.   However, individual rewards can lead to unhealthy competition.  Past leaders who have been constantly rewarded for being the superstar will have a hard time with a team reward approach.  Under-performers may find it easier to lay low in an Agile team and just do the minimum.  By providing more reward to some team members could lead to a feeling of jealousy and resentment.   This is problematic in not only an Agile culture but any culture.  

Ultimately, you do have to remember that you get the behavior you reward.  If you give reward at the individual level, you will get a level of competitive behavior and a willingness to place personal achievement over team accomplishment.  If you reward at the team level, you will get a level collaborative behavior that places team accomplishments over personal achievement.

Team Reward Approach

Within an Agile context, rewards should be supportive of the team culture.  The question is, what does a reasonable reward structure look like?  First it is important to acknowledge that answer isn’t straightforward.  It depends on your context and situation.  As a suggestion, consider starting by making at least 50% of the reward based on team collaboration and success.  Then over time increase the team reward part to make it a major part of the rewards, and still leave a small percentage available to acknowledge individual growth, exemplary work, and more adaptive alignment to an Agile culture. 

Not all Rewards are Created Equal

What is meant by reward?  Not all rewards are created equal and a reward for one person can mean something difference from one person than another.  To some employees, reward means money in the form of a merit increase or bonus.  For others it can mean advancement and more responsibility.  Yet for others it’s the ability to have freedom to work on what they want.  As part of self-organizing teams, you can have Team members recognize each other.   For example, during a Sprint retrospective (if this is being applied), the first part of this event can be where team members recognize each other for their help, assistance, helping the team drive forward, complete stories, and more.  

Team Reward must Live within a Team Culture

Maybe the answer is not as simple as instituting one type of reward system or other.   Maybe this can only work unless it fits within a broader context of focusing on the culture.  For Team rewards to be effective, a company’s culture must embrace the team concept.  Maybe it has to first start with understanding people’s natural tendency toward an Agile culture and team environment.  Maybe there has to be an understanding of people’s willingness to adapt and align with Agile.  If individuals and/or management are not really willing to adapt, they may not be able to handle a team-based reward system.  In order to handle the competitiveness, potential jealousy, and other harmful attributes, the best scenario is when team members understand and believe in the Agile values and principles and in particular, the principle of self-empowered teams.  Ultimately, the reward system that best suits your needs can be driven by an Agile principles but it should be adapted over time as your organization adapts to the Agile team culture.   

Agile’s Little Secret – It Makes You Money

Agile tends to be introduced at the team level and it’s the Agile teams who are expected to adopt Agile.   While there is various amounts of buy-in from management, some don’t seem to understand that it takes an organization to embrace Agile in order to gain the business benefits.  In other words, management has a strong role to play including adapting their behavior, embracing the Agile values and principles, and leading a culture change, in order to gain the business benefits of Agile.  It requires significant buy-in to achieve a culture change.  But this doesn’t always seem to happen. 

Some of this is not management’s fault.  Part of the issue is that Agile gets introduced to them is various ways – as a way to improve productivity, as a way to speed up development, as a way to increase quality, but in most of these cases, those introducing Agile to them fail to mention the significant buy-in they need to make.  While each of these ways have different levels of merit, it often doesn’t convey enough of a reason for management to motivate a change in their behavior and their organizational culture.    

   

How about changing the message?  Though there are many benefits for going Agile, it occurred to me that to get serious executive/senior management attention and buy-in to Agile is to give them a reason that is near and dear to their heart.  Explain to your management that Agile can increase revenue—in short, it can help them make money (or more of it).  In my experience, this gets them to actively listen, versus the passive listening they may exhibit when they think Agile is an engineering method or something the engineering team and others must do.

Yes, Agile can lead to an increase in customer sales, ergo an increase in revenue. This is all true if the organization is truly allowed to “be Agile”.  This means that teams continually demonstrate working software to customers and they are allowed to continually adapt their requirements to customer needs.  Then teams can more closely align with what customers find as valuable.  The more value customers see in your products, the more likely they will buy (or buy more).  Maybe, just maybe, if you convey that Agile can make them more money, they will listen and buy-in to what it really takes.