First Steps with Merit Money At AVL India – Rewards That Actually Motivate

Two years ago Mr. Madhu Mohan, the Head of Software Development of AVL India, an affiliate of AVL List GmbH, asked me if I could suggest him a reward system that actually motivates employees and supports their Agile teams. I suggested the Management 3.0 practice Merit Money and supported them during implementation.

AVL India has about 50 employees working in the software development department. They are organized in 8 agile teams, who develop cutting-edge software products for the modern vehicle development process.

During my last visited in December 2017 I reflected with Mr. Madhu Mohan (Head of Development) and Mr. Sunil Singh (Lead Scrum Master) about the current state of implementation of Merit Money.

Me: What was your initial motivation for introducing Merit Money?

Mr. Mohan: We needed a reward scheme, which could not be tricked. Earlier we faced the problem that employees tried to trick the reward scheme by applying politicial tactics. Also the team should get the main influence on reward distribution. Further it should fit to our team-based approach that we implemented since our introduction of agile practices, three years ago.

Mr. Singh: Team work and motivation are key for us. So we needed a highly transparent and motivating reward scheme, which enforces everyone on a team to support other team members.

SW: How did you implement Merit Money?

Mr Mohan: We decided to pilot Merit Money in 2 of our teams to see how it works. After evaluation we decided the next steps.

Mr. Singh: I was responsible for introducing Merit Money in both pilot teams. We believed that both teams were mature enough to start with this practice. We met with some resistance in the initial phase as people were skeptical about the whole process.

SW: How does Merit Money effect team work and motivation of the team members?

Mr. Mohan: As I see it, each team member strives to earn the respect of other team members by contributing to the team cause.

Mr. Singh: We find that each member of the team is always ready to help other team members. By making the results of the polls public, it becomes a great motivating factor for the team members.

SW: What threads do you see with Merit Money?

Mr. Mohan: There will be some complacency that sets in. Typically I could notice that some members were just doing an average distribution of the virtual money amongst all team members without putting any thought to it. So the Agile Coach has to constantly support the team till they get mature with the practice and as a team.

Mr. Singh: Watch out for suspicious patterns at least in the initial phases and provide a safe environment.

SW: What tips can you give to others who want to introduce Merit Money?

Mr. Mohan: You should do the polling at the end of each (2-week) sprint before people forget the contribution of others. We must pay  attention regards confidentiality, due to the concerns brought up by the team members. It will not be  nice for a team member to know that someone else rated him low. This was the biggest challenge I faced in one of the teams. Today technology and platforms are so advanced that there are multiple options to do a confidential polling. One of the teams has adopted Google forms for this. And it works fine.

Mr. Singh: Create a light and friendly environment during the rating exercise. Too much of explanations (why 9? why 3? etc) will not let the process succeed. So make people feel that it is part of their routine work.

SW: What are your future plans regarding Merit Money?

Mr. Mohan: I would like to roll out the process to all the teams and some weightage of the annual appraisal system should be derived from this.

Mr. Singh: We should be able to use this to make better performing teams from current standards.

Handbuch für Agile Rollenspiele

I have published a mini-book (in German), which describes my way of conducting role-plays to train coaching-, moderation-, and leadership-skills of Agile Coaches, Scrum Masters and other leaders in various team situations.

I am currently working on an English version.

Feel free to comment, taylor, and republish. The material is licensed unter the CC BY 4.0 license.

I am happy about your feedback, experience reports, and taylored versions. Please share them in the comments. Based on your feedback I plan to provide updates in the future.

I would like to thank everyone who supported me with this work! Special thanks to my colleagues at AVL, the participants of my sessions at Agile Coach Camp 2017 and Agile Facilitation Lab 2017 and the moderators of the Scrum User Group Graz who provided valuable feedback.




5 Most Powerful Acronyms for Agile Coaches

AcronymsPhoto by tuchodi is licensed under CC BY-SA 2.0

Personally I love acronyms, because they serve me as mnemonic for some of the important stuff that I shouldn’t forget as an agile coach. Further they are simple to teach and made to stick. Here are my top 5 acronyms for agile coaches:


The Scrum values can be easily remembered with the acronym “FROCC”, the misspelled frog:

Focus – we focus on a few things at a time
Respect – we respect our colleagues like we want to be respected
Openness – we express our thoughts about how we are doing
Courage – the team gives us the courage to take greater challenges
Commitment – we are committed to success



A well refined product backlog is “DEEP”:

Detailed appropriately – the details are added over time
Estimated – backlog items are estimated
Emergent – a product backlog changes over time
Prioritized – the most valuable items are on top



When it comes to prioritizing your backlog “MoSCoW” can serve you well. Distinguish your features by:

Must have – the requirement is core and must be satisfied for success
Should have – the requirement is should be satisfied for success
Could have – the requirement is desirable but not necessary for success
Won’t have – the requirement will not be implemented



“INVEST” in well-defined user stories. A user story must be:

Independent – the user story has no dependency to other stories
Negotiable – user stories can always be changed and rewritten
Valuable – a user story must deliver value to the end user
Estimable – you must be able to estimate the size of a user story
Small – a user story must fit into a sprint, but should be smaller
Testable – a user story must be testable

Source: User Stories Applied (Mike Cohn)


Make (iteration) goals always “SMART”:

Specific – target a specific goal
Measurable – quantify or at least suggest and indicator of progress
Achievable – be realistic
Relevant – check relevancy of the goal
Time-bound – assign a target-date


Any other suggestions?

Practical Guide: The 7Ps Framework


Meeting” by John Benson is licensed under CC BY 2.0 

In this blog post I introduce the 7Ps framework from the book Gamestorming, which is fundamental for me in regards of planning successful meetings.

James Macanufo’s 7Ps framework is a tool for planning and preparing meetings. I use it as a checklist each time I am inviting someone to a meeting. So here are the 7Ps that you should pay attention before sending out your next meeting invitation:


Why are we having this meeting? – Giving people a purpose to meet is most fundamental. Explain your participants why you are having this meeting and if you can’t come up with a purpose don’t have the meeting.


What specific artifact will we produce out of this meeting? – Think of what you want to produce as an output of the meeting and communicate it to your participants. Depending on the desired outcome people will set their expectations.


Who needs to be there and what role will they play? – Depending on the purpose and the desired outcome select the right people for your invitation. One strategy is to think of the questions that need to be answered first and than select the right people who might have answers to it.


What agenda will these people use to create the product? – You can either define the agenda on your own or co-design the agenda with the participants in order to get more perspectives on the process.


What are the risks in this meeting and how will we address them? – Risks can be laptops or smartphones that distract participants, lousy facilities (e.g. beamers, sound equipment, flip charts,…), a large number of participants, or personal issues between participants. Create rules (e.g. “no laptops/smartphones”) and check all possible pitfalls upfront to minimize bad surprises.


What would be useful to do in advance? – Tell your participants what they must prepare for the meeting (e.g. if you expect them to have ideas or concepts prepared tell them your concrete expectations) and prepare yourself carefully (e.g. hand-outs, slides, room, speech,…).

Practical Concerns

These are the logistics of the meeting – Where and when is the meeting? Does the room have sufficient equipment (e.g. video calling equipment for a remote session)? When is the best time for the meeting? (e.g. after lunch people are often less energized, time zone constraints,…) Who is bringing lunch?

James Macanufo provides the following strategies on applying the framework:

  • Each of the 7Ps can influence or change one of the others, and developing a good plan will take this into account
  • Get others involved in the design of the meeting
  • Revisit the question “Why are we having this meeting?” for recurring meetings regularly
  • Make the 7Ps visible during the meeting
  • Have a plan and expect it to change

How do you plan your meetings?

Agile Coach Camp Austria 2014

From Friday, 12th to Sunday, 14th of September a small group of highly motivated agilists from Austria (and other European countries) met at Hotel Krainerhütte for the first Agile Coach Camp in Austria. Starting from Friday evening till Sunday afternoon we spend an energized time together in workshops, games, presentations, discussions and plenty of other fun activities (like guitar playing, singing, swimming, power point karaoke, beer drinking,…). Having the event happening on a weekend I expected to meet only enthusiastic professionals, but the richness of our discussions and the experience everyone had, was more than I expected. The participants made it a real invigoration and enriching experience for me. Admittedly after the weekend I felt kind of overcharged with information, I was clearly exhausted and my brain needed some rest and time to process all the new experiences that we were able to share. Nevertheless the time to rest was short and Monday came too early, I felt inspired and happy. Agile Coach Camp 2014 was a great event made by great people! Thanks to all participants making the Agile Coach Camp 2014 such an experience and hope seeing you next year again!

Agile Coach Camp 2014 Austria - Krainerhütte

Foto by Alfred Karner

Certification is Just a Start


Two weeks ago I received my SAFe Program Consultant (SPC) certificate. I did a 4-day training and I passed an online questionnaire in order to receive it. Due to the training I gained a good understanding of the SAFe framework, most of my questions could be clarified, and it helped me to reduce my skepticism about SAFe (finally I believe that it is a quite good compromise for large enterprises with a long waterfall and command-and-control history). Further as SPC I am allowed to teach an official 2-day SAFe training and certify people as SAFe Practitioner and SAFe Agilist on my own. Cool!

Regarind SAFe I am in Shu now! Now it’s time to gain experience on applying SAFe in the real world, read Dean Leffingswell’s book (and many more – have a look at my reading list), be active in the LinkeIn group for SPC’s and other online communities, exchange opinions on local and global gatherings, etc to reach Ha and maybe someday I will be one of the few who reach Ri (cf. Shu-Ha-Ri). That is how I see certification – it’s a start.

I have met people, who believe that a certificate (CSM, CSPO, CSD, SAFe SPC, CSD, PSM I, PSM II,…) means they are already in Ri – at least they behave like that. What is the value of a CSM, who never led a scrum team? Well, I would say it is rather low, because without experience he would do (almost) everything wrong when applying his knowledge in practice for the first time. Experience is, what distinguishes someone in Ha or Ri to someone in Shu. While most certificates can be bought, experience can’t. It needs to be gained truth experiments that sometimes succeed and sometimes fail (according to D. Reinertsen we learn most at a 50% failing rate). Respectively it is up to you to find your way to Ha and Ri with or without certificate.

The Scrum Master Maturity Model

This blog post is dedicated to Angel Medinilla‘s awesome “Scrum Master Maturity Model”, which describes three levels of maturity a scrum master can reach (before Agile nirvana is reached 🙂 ):

  • The Scrum Dude: Scrum Dudes have rudimentary scrum master skills and little experience with scrum, which results into low-performing and mostly disoriented teams. Scrum Dudes are more like secretaries for their teams.
  • The Scrum Mom: Scrum Moms are solicitous and protective to their teams like a mother for her children. Teams with a Scrum Mum can be well functional, but Scrum Moms miss to challenge their teams, which often leads to stagnation.
  • The True Scrum Master: The true scrum master coaches, leads and develops high-performance teams that are able to self-reflect, learn and continuously improve. She addresses conflicts, keeps the team challenged, encouraged and motivated.

Scrum master maturity model


Angel’s model is of high practical value, because it gives us a visual representation of the actual scrum master role we find in the industry. In fact I have met many so-called “scrum masters” who later turned out to be Scrum Dudes or Scrum Moms, but very little who were actually true Scrum Masters. Let’s improve this! We need true Scrum Master to improve our organizations!


Yet Another Sprint Retrospective With “Moving Motivators”

In this blog post I want to share my experience with another great tool from the Management 3.0 workshop, called the “Moving Motivators” game. But first, let’s have a quick look into the science behind intrinsic and extrinsic motivation:


Daniel Pink tells us in this video that science has proven that extrinsic motivators don’t work for knowledge workers, which is a fact that has been ignored by most organizations for the last decades. The “Moving Motivators” game is a great tool to reveal what really motivates us to do our jobs.

Recently I decided to play the “Moving Motivators” game with one of my agile teams in our sprint retrospective.  Even if we shared an open team culture and we knew each other quite well we never talked about our intrinsic motivators inside the team. So I expected to get some new insights into that blind spot.

Preparing the game for our retrospective took me about 2 hours of time. This is what you need to do:

  1. Print the Moving Motivator cards: I used a bit heavier paper (e.g. 100g) than usual office paper and a color laser printer that produces good quality prints, because I think it is essential that the cards look nice and professional.
  2. Laminate the cards: The printed cards look great but laminating them makes them awesome 🙂 It also protects the cards, makes them reusable, gives them a professional look and a nice touch. Your team will love them!
  3. Cut the cards and prepare the card decks for handing them out to your team



During the retrospective we followed the 3 steps through the exercise, which took us about 45 minutes. And, yes, the team loved the nicely crafted cards 🙂

In conclusion the “Moving Motivators” game was a welcome variation to our usual retrospectives that helped us to talk about our motivations for our jobs. Personally it revealed that I have had badly misjudged some of the team member’s in respect to their intrinsic motivators. The “Moving Motivators” game helped me to correct the view on my colleagues and made me start respond more accurately to their actions and behaviour.

If you would like to play the game with your team I can leave you some tips here. The exercise requires a high level of trust and an open culture. It is also crucial to talk to your team before you do the exercise with them – everyone must agree. Take your time to prepare the cards nicely. It will be much more fun! If your team fulfills the prerequisites the exercise is a great opportunity to get to know each other better and bring you one step further as a team.

Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)

My Management 3.0 Prezi (German slides)

From 12th to 13th of March I participated in a Management 3.0 workshop by Jürgen Dittmar in Munich. To present the highlights of the workshop to my workmates I decided to craft a Prezi. And here is the result of my first Prezi that finally made it onto a presentation screen (German slides):



The presentation went well (at least there was positive feedback). However I am still a novice Prezi craftsman and I welcome your feedback on my slides. Also feel free to reuse it for your purposes.