Experience Report

Feedback via Fudge Candies

About this Publication

This paper is about an experiment which was intended to replace an ineffective corporate process. After many transformations it ended as a well known, bottom-­‐up, light-­‐weight appreciation process and became a solid part of the company’s culture.

1. INTRODUCTION

Frequent feedback is at the heart of Agile. In an empirical process, we struggle to make feedback loops as short as possible. Instant feedback loops are an important step to achieve perfect agility, defined as the ability to immediately adapt to any change in the environment.

There are many kinds of feedback loops. Some examples include:

  • Business feedback loops, in which stakeholders offer their insights about an increment they have just been presented.
  • Technical feedback loops, in which developers assess code quality through peer reviews or in which code quality is assessed through unit tests.
  • Process feedback loops, in which people look at the last iteration and plan to resolve blockers and discover areas for improvement.

There is also another feedback loop that is of paramount importance: mutual appreciation of the work performed. It is a positive kind of feedback, when one thanks others for something they have done, and which has direct impact on one’s commitment to work.

In the well-­‐known book First, break all the rules, one of the 12 characteristics of successful and productive employees is that they do receive recognition or praise for a good work at least once a week (Buckingham). Lack of appreciation may even lead to dismissal. The U.S. Department of Labor says 64% of working Americans leave their jobs because they do not feel appreciated (Robbins). And since people are the most important part of the software development process, a company’s competitive advantage directly depends on whether it has this type of feedback well established.

This paper is about a bottom-­‐up experiment designed to establish an effective bonus system. The initiative was first rejected by the company but afterwards transformed into an appreciation feedback  process,  becoming part of our company’s culture.

2. BACKGROUND

The experiment was carried out in the Marketplace department of Allegro Group. The department runs several marketplace platforms in Central and Eastern Europe, allegro.pl being the biggest one. Established in 1999, Allegro Group has grown rapidly and went through several major changes, one of them being a SCRUM transformation in 2011. SCRUM helped to visualize lots of thorny issues swept under the carpet. In November 2013, we discovered a bonus system was one of the problems.

I had been a Scrum Master for two years at the time. After several months spent on helping teams to improve their work, I felt it was the right time to attack something much bigger at the corporate level. Also, I wanted to check if people have enough power to change the environment they are immersed in. So, ready to challenge the organization, feeling a bit like David against Goliath, I began my lonely quest.

3. THE STORY

In fact, I was not that lonely at the time. Scrum Masters in the organization enjoyed a safe conduct provided by the CTO, which made it safer to attack huge company issues.

The bonus process was divided into quarters. Every quarter, teams presented what they had achieved in order to receive a grade and a bonus. The reasons why this bonus system was disliked were the following:

  1. Heaviness. Each quarter, teams spent one week to fulfill the bonus process.
  2. Top down. It was based mainly on management opinion.
  3. Predictability. Bonus was perceived as expected. You simply got your bonus no matter what.
  4. No collaboration. No collaboration between people or teams was taken into account.
  5. No soft skills. In general no soft side of employee’s activity was taken into consideration.
  6. Motivation. It had negative, if any, impact on people’s engagement in work.

I  began  to  search  for  an  inspiration  for  a  lean  alternative  that  would  be  less  time  consuming,  light-­‐weight, democratic, with soft side of performance built in. The one that appealed to me the most was Merit Money by Jurgen Appelo. This is basically a kudos system, in which people give and receive credit for their achievements. Then, periodically, they may receive a bonus depending on how many kudos they have received and how much money is on the table. The prize is not fully predictable, for scheme participants know they will receive money but do not know how much and when – for each iteration there is a fair chance of getting money managed in a drawing.

I shared the idea with the manager, who in turn discussed the initiative with the CTO. I got an unofficial green light and had the project started.

3.1 Vision

The aim of the experiment was to propose a good alternative to the existing bonus system. Then, eventually, replace this system as the first bottom-­‐up initiative to change such an important process. If successful, it could be a solid, well-­‐known example that people can have much influence on their working environment.

3.2 Implementation

With that vision in mind, I proposed initial rules of the game. For an experiment purpose, the bonus was not real money but candies. Rules were as follows:

  • The experiment was divided into one-­‐week iterations.
  • Everybody receives 4 cards at the beginning of each iteration.
  • Participants can give their cards to anybody in the experiment group; one can also give it to the entire team.
  • Cards are given for performance, but there is no single definition of what performance is. It can be  a great test developed or somebody sharing a lunch with a hungry colleague.
  • At the end of each iteration, I decide how much bonus is at stake (100% bonus is the number of participants, i.e. if there are 16 players, there are a maximum 16 sweets per iteration).
  • Then, we throw a die. In the case of a lucky throw, cards are exchanged for the bonus. The probability of a lucky throw is 0.5.
  • The exchange rate is total #sweets/total #cards in the system.
  • In the case of an unlucky throw, the bonus is moved to the next iteration.
  • The experiment has a time limit. It ends after 3 months.

Described as above, the experiment resolved all of the drawbacks of the bonus system existing at the time.

In particular:

  • Heaviness – it requires no special effort from participants; they present cards to thank someone for something.
  • Top down – it is mainly based on peer feedback.
  • Predictability – since there is a drawing and the exchange ratio varies, you do not know exactly when you will receive a bonus and what its amount will be.
  • No collaboration – it is based on peer feedback, hence it promotes collaboration.
  • No soft skills – it includes both hard competencies and soft skills because of no precise definition of performance.
  • Motivation – much more effective, because appreciation is a very strong motivator.

3.3 Hypotheses

Every valid experiment should be based on certain assumptions. The initial hypotheses were the following:

  • Participants will present their cards with ease, at least 30% of their cards per iteration.
  • 90% of participants will stay with the system.
  • The system will grow, 16 initial participants will encourage at least 5 others.

3.4 Let’s start

The first step you take when getting started with an experiment is finding people  who  share  your  vision.  Therefore, I started to look for teams that cooperated closely, so that we  could  observe  appreciation  not  only within one team, but also  between  teams.  We  wanted  to  invite  mobile  phone  teams,  but  failed,  for  the  teams did not buy the idea – one person strongly opposed to it and others followed. We concluded the concept was            not clear enough, making people feel unsecure to step against the bonus system they knew. Also, we did not require whole teams to participate and searched only for volunteers. If the idea had been presented as a fail-­‐ safe alternative and just for those who wanted to try, we may have been luckier.

Equipped with this knowledge, we gave a try in two other teams, who also appeared to be reluctant and asked for some time to rethink the concept. Ultimately, we managed to gather 7 people from one team  and  2 members from the other. Then, the idea was proposed to another team, of which next 7 people joined us. With 16 people on board, we were ready to start.

First we wanted to see how people value the existing system. All 16 participants received an anonymous survey and their average response was as below:

  • Number of hours participants spent last quarter to feed the bonus system: 40 hours
  • Does the bonus system support cooperation?: 2.6 on scale 1–5
  • Do you think the system is fair?: 2.1 on scale 1-­‐5
  • Are you satisfied with the bonus system?: 2.2 on scale 1-­‐5
  • Does the bonus system support your motivation?: 2.2 on scale 1-­‐5

It proved clearly that the existing system was time-­‐consuming and poorly rated.

The last task before starting was to set up  time limits. In  order to  adapt quickly, the experiment was divided  into weekly iterations. Its life span was initially set to one quarter, but then changed to 4 months, as it was early  December  when  many  employees  take  days  off,  being  out  of  office  even  from  mid-­‐December  to  mid-­‐ January.

3.5 Control

In order to prevent the system from being misused (money was to be involved in the future), we ensured as much transparency as possible. Two aspects were strictly monitored:

  • How many did cards people give?
  • Who gave a card to whom?

To answer the first question, we had to ask each person about the number of cards in their possession after the end of each iteration.

The latter required cards to be issued with owners’ names on them. When a person decided to exchange received cards for candies, we were able to note down who gave the cards to whom. Then present it on a public space.

The cards transferred from one person to another but not exchanged into candies afterwards, were out of our sight. But this was not an issue: no bonus – no attempt to misuse the system.

3.6 First issues

As soon as the experiment started, various issues began to pop up. When resolving these issues, a number of changes (listed below) were introduced in the system. However, with every tweak, the game was becoming more and more tailored to our environment.

Cards layout

In the beginning, every card was marked with its owner’s name, issue date and experiment title.

Figure 1. Initial card view

Since the experiment was open and intended to grow virally, players naturally started to hand over cards to persons from outside the game. Sadly enough, the recipients rarely knew what the project was all about. In order to help them out, a Wiki page was developed, with a link to it placed on the cards.

As the experiment continued, we observed some participants started to write notes on the reverse   side of the cards to explain what they gave their credit for. Therefore, a dedicated space appeared on the front side of the card.

Also, we noted a situation when a person tried to misuse the system by giving away all of his cards at one time just to collect sweets. For that reason, we announced that only cards with a written thank you sentence could be exchanged for candies. A vast majority of players had already been doing it anyway, so the decision did not cause much trouble and made misuses more difficult.

Figure 2. Card at the end

Bonus amount

Every iteration,the company was to decide what bonus should be put on the table. The challenge was how to link it with business performance. At first, it was connected with business results, but such results were only available monthly. Therefore, we moved to the percentage of successful releases – at the time there were two big releases each week with ~40 teams participating. This could possibly motivate teams to release a high quality code. Yet, here again, most integration problems were unpredictable, because of overlapping changes – so the teams felt that they did not have much control of it.

Then, an excellent idea emerged – why not ask Product Owners to evaluate their teams’ work. The concept was brilliant, as POs have the best knowledge to assess their teams’ productivity. In this way, we managed to create an important feedback loop with a crucial role in maximizing the value. This change made the feedback very regular and visible, which was an additional benefit at the time.

System flush

Another interesting observation was that over time people tended to retain more and more cards instead of giving them away. This had a negative impact on the game. As we followed the initial idea, the exchange rate was the number of sweets in the system / number of outstanding cards.

Since the exchange rate depended on the number of outstanding cards, a bonus in the pool increased but was not spent. We tried an option in which the bonus was divided by cards claimed to be exchanged, instead of the total number of cards in the system. It worked well in a way that bonus was spent right away, however it was not fair toward those who were absent or on holiday. Those lucky ones had an exchange rate 12 times higher than the average.

Therefore, we decided to flush the system regularly. Cards had their “expiration date” after which they could not be exchanged. In addition, we changed card colors to make the obsolete ones easily eliminated.

This move made participants more active, especially as the expiration date approached. In our experiment, the expiration date was Iteration 13 (last iteration). The participants’ reaction has been presented on the chart below:

Figure 3. Outstanding cards given

It is worth noting that after the end of the experiment, we made the exchange rate even easier: a candy/card  exchange  rate  was  an  average  grade  given  by  POs,  presented  on  scale  0-­‐100%.  For example, if PO’s average grade was 82%, each card was exchanged for 0.82 candy, rounded up.

Sweets

Another field of experimentation was the currency of the bonus. We tried different sorts of sweets, ranging from small ones, through expensive ones, and finally hit a jackpot with fudge candies. This made the participants go crazy about the game (note that this may be a regional phenomenon), as shown on the chart below, with fudge candies introduced in iteration T8.

Figure 4. Cards exchanged to sweets

Lessons learned was that currency attractiveness is obviously an important factor. As an interesting side note, the Polish name for fudge candies is Krówki (which stands for “little cows” in English), and so Krówki has got into the company’s speech for good, becoming the name of the game.

3.7 Major change

As the experiment was coming to an end, a new corporate bonus and recognition system was introduced, creating a hurdle we could not overcome, taking into account its organization-­‐wide and untouchable nature. It appeared as if our four-­‐month effort was just a nice exercise. I felt it was Goliath to win. There will be no proof people can change their working environment at higher level.

3.8 Hope?

Despite the circumstances, players’ behavior looked very promising. A considerable number of people joined the game, liked it and wanted to continue. To compare results with the initial assumptions:

  • On average, participants handed over to others over 21% of their available cards every iteration (30% initially assumed)
  • 97% participants claimed they would like to continue the game (90% initially assumed)
  • 17 initial participants encouraged 15 others to join (5 new players initially assumed).

Figure 5. Popularity growth

We were stuck in a situation, in which an experiment intended to replace the bonus system got blocked by the corporate process. On the other hand, there were 32 people appreciating one another, having fun, enjoying sweets and willing to continue the game. They spent 21% of their cards, with 65% of the spent cards  exchanged for the candies. An additional interesting fact was that 16% of the cards were handed over to other teams. It looked like it was a good appreciation currency in relations between the teams.

The system grew, participants retention was a miracle, sweets played an important fun part and the game, and it not only supported appreciation inside a team but also between teams. It seemed the game was a very valuable tool. But what exactly was this value? In the final survey, one of the questions concerned the best aspect of the game:

  • 65% of participants said it was positive feedback and appreciation
  • 50% of participants said it was fudge candies

When asked about hints for possible improvements, the participants gave mainly the following two answers:

  • 15% -­‐  there are too many cards
  • 12% -­‐  simplify the exchange rate.

Therefore, quite confident that the whole thing was worth continuing, we launched Krówki in the entire department with a few minor tweaks.

  • Periods – there are 3-­‐month periods within which cards remain valid.
  • Iterations – each lasts 2 weeks, each person receives 4 cards per iteration (more cards available on demand).
  • Distribution – a Scrum Master is the first point of contact in each team and manages distribution of cards and sweets.
  • Coordination – there are 2 game coordinators per location.
  • Exchange rate – simplified, an average assessment of Product Owners on a scale from 0 to 1.
  • Each drawing is conducted in a different team room so that people can see how it works and ask questions.

We started in July 2014. Now, 11 months later, there are 233 people involved in 4 different locations. The name of the game is part of our corporate speech. If you want to appreciate somebody for something, you just want to give them Krówki, which is a synonym of appreciation. This was a huge success with no precedent.

4. WHAT WE  HAVE LEARNED

First of all, making this kind of culture change is not possible without passion, determination and consequence of a leader, who is driving it until it gets enough momentum to be part of company culture. Without such a leader this game would not grow just by itself.

Apart from the obvious that you should start small, tweak and then grow, I am convinced that the unique status  of  the  game  at  Allegro  comes  from  the  fact  that  since  the  onset  it  was  a  bottom-­‐up  movement  that developed owing to its active participants who wanted to appreciate their mates, thus inviting new players to join. We frequently emphasized that it is a social game, participation is optional and everyone can join or leave it at any time.  The responsibility is on the participants’ side.

I had an opportunity to discuss kudos systems with people from outside my organization. They admitted they experienced similar problems in their companies, as employees simply did not buy the whole concept. As  it appeared, the quite common pattern was that the systems were introduced by CEOs or line managers, who developed the schemes and handed it over to employees for implementation.

Telling people to appreciate one another is doomed to failure. They will be reluctant to do it, sensing a management performance trick. If you encourage them to do it, find change agents, make it a game, and then leave it to their own discretion, you have a much greater chance to succeed.

Another observation is that simplicity is the key. The game needs to be simple. In our case, people often did not get how the exchange rate was calculated, even if the formula kept on being patiently explained. Initially,  the number of all the fudge candies was divided by the number of all the outstanding cards, where the number of candies depended on an average performance assessment made by PO’s. Afterwards, we had it simplified, but still the simplest and natural ratio would be 1:1. A drawback is that PO’s feedback would not be needed any more.  But if you imagine this feedback is already part of company culture, then why not?

5. ACKNOWLEDGEMENTS

First I’d like to thank Adam Michalczyk. I could always count on your trust and silent managerial support.

My  thank-­‐you  goes  also  to  those  members  of  Pi,  Delta  and  Gamma  team  who  were  early  adopters  of  this game. Without your open mind and trust it would not be possible. A special thank you goes to Piotr Siwiński  and Tomek Jankowski, who are the best change agents I could imagine. Your natural gift of appreciating others was core of this game and attracted many others to join.

It would not be possible without hard efforts of Ewa Kosterka, Asia Toboła and Rafał Bryk, who helped to organize the game and provided many valuable insights how to improve it along the way.

I appreciate all of the players of Krówki. Your actions is the best proof this approach has great value.

At last I would like to thank David Grabel, Rafał Bryk and Dobrochna Mierzejewska for valuable insights, which helped me to improve and clarify this message and everyone benefited as a result.

REFERENCES

Buckingham, Marcus and Coffman, Curt “First, break all the rules” Robbins, Mike “Focus on the Good Stuff: The Power of Appreciation”

Appelo, Jurgen, “Merit Money”, https://management30.com/product/workouts/merit-­‐money-­‐bonus-­‐systems/

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Agile2015

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Abstract—Manager as scrum master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a …
‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’ This principle from the Agile Manifesto – that teams are ‘self-organizing’ – may sound simple; however, supporting sel…
Abstract—Manager as scrum master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a …
‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’ This principle from the Agile Manifesto – that teams are ‘self-organizing’ – may sound simple; however, supporting sel…

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now