InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Individual Rewards on a Scrum Team

Posted by Shane Hastie on Nov 30, 2009

Sections
Process & Practices,
Architecture & Design
Topics
Agile ,
Collaboration ,
Software Craftsmanship
Tags
Compensation ,
Scrum

A recent discussion on the Agile Alliance LinkedIn group started with the question by Reeju Srivastava:
Should we have an individual recognition reward on a Scrum team?”

This question prompted a vigorous debate, with opinions for and against. 

Here are some of the discussion points raised:

FOR:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

 When folk argue that a competitive reward system is no good, they usually start from the rather extreme point of view that competitiveness is a zero-sum game in which winner takes all. But in most real life situations this is not the case.

In most team environments the team dynamic resembles that of a Nash equilibrium (like the one depicted in the movie "A Beautiful Mind"). All the "players" have the same goal in mind and they try to outdo each other but never in a way that diminishes the team's overall initiative or deviates from the primary goal.

There is nothing wrong with rewarding the individual "players" in a Nash equilibrium. In fact, if they were not, then there wouldn't be one

In business school they teach that in their careers, individuals are motivated mainly by 3 things:
- personal growth
- money
- recognition

If the reward system fails to sufficiently motivate the individual via these channels, then expect employee retention problems. This may not happen immediately, but over the medium to long term it will.

Although many societies have tried, none have succeeded at repressing the individual for very long periods of time. Invariably, such social orders fail either because the members of the society outright revolt or because they simply migrate/defect to neighboring societies that do offer an appropriate reward system.

It's quite true that too much competition can destabilize a team. This is why few teams tolerate "prima donnas". But without competition, the risk are that:
- members leave in favor of more rewarding opportunities
- weaker members are not motivated to excel
- stronger members are demotivated from excelling
- the team (as a whole) stagnates and won't improve its skills set

Any team can tolerate a certain level of competition, and a certain lack of rewards. There is a "middle ground" of stability between extremes. I believe that's one interpretation of the Nash equilibrium. But outside of that "middle ground" lie risks

By Virgil Mocanu

As has been mentioned several times I believe this is a valid scenario when the team choses to recognise individual excellence above and beyond normal practice. Being as the team has collective responsibility and accountability for delivery, then I advocate that the team can also control how the process works for recognition and motivation. Even though the principles of Agile methodologies drive collaboration I wouldn't say that's to the exclusion of the individual. After all we have individual aspirations and career development even whilst in a close knit collaborative environment. I believe we need to recognise the benefits in the individual to create the synergy of the team, enabling particular members for design roles over code based on experience and expertise, depending on the requirements in hand.
By Sean Capes

AGAINST:

Why is one person ever worthy of being elevated above the team? What do you hope to achieve? Why do you want to do this?

 By Kevin E. Schlabach

 

Scrum teams work beacuse they very closely bound to each other. Individual recognition may break this well knit fabric and create rift between the team members

 

By Archit Jauhari

 

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest.

 

That then begs the question of how we appropriately reward the masters vs the novices and all levels in between. The only way I can think of is to have a factor as a function of objectively, fairly determined skill level.

Any behavior that sets the stage for undermining team trust is a bad idea.

By Jay Conne

 

Simple answer... No.
Since a scrum team is, as a whole, responsible for their commitments and work, the possibility for this to be implemented indicates that something is wrong within the team. How could one individual stand out without it being a collective decision?

 

If things run normally, either someone is doing stuff he shouldn't really be doing or it was a group decision that this person should do the thing in question. Neither warrants a personal recognition.

Then, of course it's always good for people to get noticed when they work hard. But I would handle it in another manner.

By Daniel Liljeberg

 

 

Kevin Schlabach blogged on the topic at http://agile-commentary.blogspot.com/2009/11/individual-recognition-on-scrum-team.html


Are individual rewards used on your teams, and do they promote or detract from team performance?

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Great item - here are a few other sources: by Mark Levison Posted
In addition I should have mentioned that I'm firmly against this practice by Mark Levison Posted
from team member by Saad Khawaja Posted
Re: from team member by Mark Levison Posted
Re: from team member by Saad Khawaja Posted
A "we" culture, 2 tools by Mike Bria Posted
Stated more clearly by Mark Levison Posted
  1. Back to top

    Great item - here are a few other sources:

    by Mark Levison

  2. Back to top

    In addition I should have mentioned that I'm firmly against this practice

    by Mark Levison

    If you have individual rewards then you will get individual behavior and not teamwork. For example if I'm rewarded for pumping out lines of code - then forgot mentoring and pair programming, heck I might not attend the daily stand-up.

    If the team chooses to recognize individual practice then resentment will build over time. Example: Sure Fred is good and does a great job to help the team, but why are my contributions not recognized and rewarded.

    This is a very slippery slope but it can quickly destroy the team that the Scrum Master and Coach have spent so long building.

    Cheers
    Mark Levison
    The Agile Consortium

  3. Back to top

    from team member

    by Saad Khawaja

    I think that team members should recognize each others efforts, I think that will have a better effect, rather than a manager.

  4. Back to top

    Re: from team member

    by Mark Levison

    Saad - think how you would feel if your fellow team members always recognized the prima donna of the group, but never you. This person may get the most attention and glory - but not contribute the most. I've seen this do great damage to teams, damage that takes along time to undo. Tread with care.

    Cheers
    Mark Levison
    The Agile Consortium

  5. Back to top

    Re: from team member

    by Saad Khawaja

    Yes such folks do damage the team. I would check the behavior of the "prima donna", I would ask the team not to always recognize only that individual but also others. I would point out other folks contributions, even if they are mine. I though Agile brought honesty, and if the team members can not be honest and humble, then I would not want to be on that team. I would eventually leave.

  6. Back to top

    A "we" culture, 2 tools

    by Mike Bria

    Regardless of whether your org'z official policy is or isn't "individual recognition", I've found two things to be the consistently reliable anecdote within a team for the possible negativity described here:


    • Pair programming. If all code is written in pairs (especially if they rotate), "singling out" drops drastically (as a natural byproduct). Even if certain people are more productive than others, it doesn't "feel like it".

    • The "iJar": (Assumes pair programming) Anyone talking about what they've accomplished (or plan to) must use the "We" word, instead of the "I" word; else, $ into the kittie. For example, "Yesterday, *we* added the new search feature..."

  7. Back to top

    Stated more clearly

    by Mark Levison

    I seem to like commenting on this item :-) There is no evidence that rewards work for individual motivation and heaps of evidence that it doesn't.

    There is even a good TED talk on the subject Dan Pink: www.ted.com/talks/dan_pink_on_motivation.html

    Cheers
    Mark Levison
    The Agile Consortium

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.