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?

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

Better Feedback with a Happiness Door

My work as Agile coach includes regular training lessons with agile teams, product owners and other staff. Usually after a training or workshop I kindly ask the participants for their verbal feedback about the workshop, my moderation, the exercises, etc. A common practice that I just adapted from other trainers with the aim to improve my own training and moderation skills. Unfortunately the results of the verbal feedback rounds were not satisfying for me due to various problems:

  • Giving honest verbal feedback strait in the face seemed to be hard for my participants and therefore it was often omitted
  • Participants seemed to feel a barrier exposing their individual thoughts about the training in front of the group
  • Participants gave pseudo feedback by just repeating other’s feedback or giving hollow feedback
  • Only a few participants gave feedback at all
  • I hardly received constructive improvements (which is most interesting for me)
  • If there was plenty of verbal feedback after the training I often forgot most of it until I had time to reflect on it
  • Participants didn’t know how to express appropriate feedback

As a result I thought about alternative feedback mechanisms. I expected less problems with written feedback, which led to the idea to use a happiness door, a feedback mechanism created by Jurgen Appelo that I already knew from the management 3.0 workshop I attended some months ago.



Could the happiness door address my problems I had with verbal feedback rounds?

Yes. What has changed is that my participants felt safe to express their feedback semi-anonymously on sticky notes, which was not the case with the verbal feedback rounds. As a result I received more valuable feedback on my training lesson. Also everyone was willing to write at least one sticky note and because of less mutual influencing there was more individual feedback on the door. Finally seeing the feedback visually in front of me on the happiness scale was just great, because it gave me an instant feeling about my training performance and also helped me to remember a feeling of the training lesson. After the training I spent another 15 minutes to carefully read, interpret and summarize the feedback, which helped me to reflect. Last but not least due to sticky notes I didn’t miss any feedback, which happened quite often when doing verbal feedback rounds.

The only drawback I identified so far is that the written feedback can be easily misinterpreted and that there is no possibility to ask questions back. And of course you need to ask for a nice handwriting if you want to apply a happiness door.

Anyway, to put it in a nutshell the happiness door turned out to be a good feedback mechanism for me and there will be more happiness doors in my future training lessons for sure.

User Story KATA

Um die Qualität der User Stories in unseren mittlerweile 25 Scrum Teams bei Infonova weiter zu verbessern und anzugleichen führe ich gerade eine User Story KATA in unsere Entwicklungsabteilung durch. Ich habe die KATA mit Kollegen gestaltet und möchte die Idee dahinter gerne vorstellen:


Ausschlaggebend für einen erfolgreichen Sprint ist die Vorbereitung der User Stories. User Stories zu strukturieren ist einfach (siehe BDD), wie jedoch Product Owner und Team zu einem gemeinsamen Verständnis der Requirements kommen ist eine Herausforderung, die es zu jedes Mal aufs Neue zu meistern gilt. Als Check, ob ein gemeinsames Verständnis gegeben ist dient uns die Schätzung des Teams und die Definition of Ready. Wird eine User Story ohne ausreichendem gemeinsamen Verständnis commitet, passiert es nicht selten, dass das Commitment nicht gehalten werden kann, was die Planbarkeit eines Projektes schwierig macht. Bisher ist die Verwendung der DoR noch nicht über alle Teams etabliert. Mit Hilfe der KATA soll die Ausrollungen der DoR unterstützt werden und zu einer Qualitätssteigerung der Arbeitsweise führen.


  • Die Planbarkeit durch die Richtige Handhabung einer DoR und die daraus resultierenden geringeren Unterbrechungen und Scope-Changes im Sprint steigern.
  • Das kollaborative Erarbeiten der Requirements mit Product Owner und Team, sowie die Handhabung der Definition of Ready erlebbar machen und bewusst üben.


Die Grundlage der KATA ist ein fiktives Business Szenario und eine dazu definierte User Story, jedoch ohne Akzeptanzkriterien, die in der KATA von den Teilnehmern ausgearbeitet werden sollen. Das Beispiel erscheint auf den ersten Blick bewusst trivial, enthält jedoch eine gewisse Komplexität, die nur durch genauere Beschäftigung mit der User Story zum Vorschein kommt.


Es nimmt jeweils ein Entwicklerteam (4-6 Entwickler) + Scrum Master + Product Owner and der KATA teil. Alle Teilnehmer sind in der KATA in der Rolle des Entwicklerteams. Ich spiele in der KATA den Product Owner und stelle dem Team die vorbereitete User Story vor. In den folgenden 60 Minuten ist es die Aufgabe des Teams die User Story durch geschickte Fragen zu erforschen und die Akzeptanzkriterien in Form von Szenarien (siehe BDD) zu definieren. Nach und nach zeigt sich dem Team die wahre Komplexität der User Story. Nach einer Stunde breche ich diesen Prozess ab und lasse das Team das Ergebnis mit einer DoR auf die Erfüllung Dieser prüfen und schließlich die User Story zu schätzen.


Nachdem ich nun mit 5 Teams die KATA durchgeführt habe kann ich ein erstes Zwischenresüme ziehen. Was den Teilnehmern der KATA meist zum ersten mal bewusst wird ist, wie wenig Zeit sie eigentlich für die Vorbereitung von User Stories investieren (meist weniger als 5% eines Sprints). Zum Anderen ist vielen die Bedeutung der DoR auf den Sprinterfolg noch nicht klar und wird durch die KATA erst richtig verstanden. Die teilgenommenen Teams können in der täglichen Arbeit auf die KATA als gemeinsames Erlebnis zurückblicken und so den sich langsam einschleichenden Prozess-Schlendrian entgegenwirken. Die Teilnehmer haben Spass an der KATA, was die wichtigste Grundlage ist, damit das transportierte Wissen auch weiterhin im Arbeitsalltag Anwendung findet.


Zur Einführung von zentralen Prozess-Veränderungen, wie einer DoR scheint eine KATA hervorragend geeignet zu sein. Die aktive Einbindung der Mitarbeiter, der Spass-Faktor und das gemeinsame Erlebnis sind wesentliche Erfolgskriterien für nachhaltige Veränderung. Vermutlich wird jedoch die KATA nach einer gewissen Zeit wiederholt werden müssen um einen erneuten Impuls zu geben.

Wer an Details interessiert ist, bitte direkt an mich wenden.

3 Konzepte aus den Martial Arts in der Softwareentwicklung

Die Softwareentwicklung hat schon länger erkannt, dass wir uns von den traditionellen asiatischen Kampfkünsten (z.B. Karate) einige Praktiken und Tugenden abschauen können um unsere Fähigkeiten als Entwickler zu steigern. Disziplin, Fokus, ständige Verbesserung durch Lernen, ein gesunder Geist, Professionalität, Meisterlichkeit, usw. sind Schlagworte, die man heute mehr als je zuvor im Zusammenhang mit “Software Crafmanship” hört.



Die Kata bezeichnet im Karate eine abgeschlossene Übung, bei der exakt definierte Bewegungsabfolgen durch häufige Wiederholung bis zur Perfektion trainiert werden. Selbes Prinzip findet sich in der Softwareentwicklung als Code Kata wieder, wo Entwickler-Skills wie Clean Code, Test Driven Development (TDD) oder Pair Programming anhand von einfachen Code Beispielen trainiert werden. Die Regeln einer KATA müssen dabei genau beachetet werden. Der Weg zur Lösung erfolgt bewusst in “Baby-Steps” die auftretenden Probleme und die einzelnen Lösungsschritte die notwendig sind bewusst zu machen. Die Lösung ist dabei nicht im Fokus der Code Kata sondern der Weg zur Lösung steht im Vordergrund der Übung. In agilen Unternehmen werden Katas regelmässig zur Weiterbildung der Entwickler durchgeführt. Eine Liste von populären Code Katas findet ihr hier:


Als Dojo wird im Karate der Übungsraum bezeichnet, in dem Katas durchgeführt werden. Das Prinzip der Coding Dojo bezeichnet demnach das Zusammenkommen mehrerer Entwickler in einem Raum um eine Code Kata gemeinsam durchzuführen. Es gibt unterschiedliche Durchführungsarten einer Coding Dojo. Die Teilnehmer können in wechselnden Paaren (Pair-Programming) an der Kata arbeiten (Randori Kata). Es kann jedoch auch von einem Teilnehmer die Lösung auf einem Beamer vorzeigen (Prepared Kata). Letztlich ist es jeodoch jedem Frei mit Durchführungsarten zu experimentieren. Auf findet ihr mehr Infos zu Coding Dojos.


Shuhari ist ein Lern-Konzept, das bei den traditionellen Martial Arts angewendet wird um eine Kampfkunst bis zur höchsten Stufe ( dem Meistergrad) zu erlernen. Die folgende Erläuterung stammt von Wikipedia:

  • shu (守?) “protect”, “obey” — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
  • ha (破?) “detach”, “digress” — breaking with tradition — detachment from the illusions of self
  • ri (離?) “leave”, “separate” — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical

Stellen wir uns vor, wir möchten Scrum nach den drei Shu-ha-ri Schritten erlernen: Im ersten Schritt wird streng das Lehrbuch (die Tradition) befolgt, bis dieses verstanden wurde. Erst wenn wir Scrum nach Lehrbuch anwenden können entfernen wir uns langsam von der Tradition um  zu experimentieren (z.B. Individuelles Anpassen des Prozesses an das eigene Unternehmen). Hat man den Umgang mit allen agilen Methoden und Techniken, als auch die eigenen Adaptionen zu einem Schlüssigen Gesamtkonzept vereinheitlicht und kann die Techniken, Werte und Methoden  jederzeit anwenden, so hat man den dritten Lern-Schritt (“ri”)erreicht.