Moving Demotivators

A demotivator is like an unwanted load on a sinking ship. With it, the ship will sink. Without it, the ship will not sink but it will not help the ship to move forward. To move the ship forward, we need motivators.

So what is Moving Demotivators? Moving Demotivators is a retrospective that you can run with your Scrum team to identify what are the current demotivators that are having a negative impact on the team. With the results from this retrospective, the organization can work on removing these demotivators and then move on to identify what will motivate the team.

Moving Demotivators is inspired by Management 3.0 Practice: Moving Motivators and based on Herzberg’s Motivators and Hygiene Factors. For more details on Moving Motivators, you can follow this link

What is Herzberg’s Motivators and Hygiene Factors

According to Herzberg’s Motivators and Hygiene Factors, job satisfaction and job dissatisfaction are not opposites.

  • The opposite of Satisfaction is No Satisfaction.
  • The opposite of Dissatisfaction is No Dissatisfaction

Remedying the causes of dissatisfaction will not create satisfaction. Nor will adding the factors of satisfaction eliminate dissatisfaction. If you have a hostile work environment, giving someone a promotion will not make him or her satisfied. If you create a healthy work environment but do not provide members of your team with any of the satisfaction factors, the work they’re doing will still not be satisfying.



How to use Moving Demotivators to identify the demotivators

Step One (5 mins)

Which demotivators are important to you? Place the cards in the order from Left (least demotivating) to Right (most demotivating.)

List of demotivators

  • Boredom
  • Poor communication
  • Job insecurity
  • Micromanagement
  • Disrespectful treatment
  • Lack of material and tool availability
  • Lack of recognition
  • Ineffective utilization of skills
  • Productivity Salary Disparity
  • No follow through on commitments

Step Two (5 mins)

How is the current demotivation level of each demotivator for you? Everybody on his own: Think about the question and assign a demotivation level and frequency to each motivator.

Demotivation Level

  1. Completely not demotivated
  2. Moderately demotivated
  3. Demotivated
  4. Demotivated over average
  5. Very highly demotivated


  1. Never
  2. Rarely
  3. Occasionally
  4. Frequently
  5. Very Frequently

Step Three (30 mins depending on group size)

Then one by one everybody talks about the order and demotivation levels he/she chose. The other team-mates standing around the one who’s talking and ask questions, if clarifications are required. If there are more than 7 persons in the team, split the team in two groups.

Step Four (20 mins)

Reflection phase with the whole group.

  • What did you observe?
  • What was interesting?
  • What was surprising?

Evaluation (after the retrospective)

Based on the evaluation sheet the scrum master prepares an evaluation diagram and prints it. This can be used to work on demotivators that are important for the team but have a low level or the make shifts in the demotivation levels after changes visible.

Sample ChartsScreenshot_2.png

Continue reading

Defect Retrospective (Experiment)

A separate event from the regular retrospective targeting on defects. The idea of this retrospective is to review the defects identified and fixed by the development team, allowing the team to identify ways to prevent similar defects from re-occurring and improving the quality of the product being developed.

  • Frequency: Once per week (Friday)
  • Duration: 1 hour

To ensure that this event run smoothly, the backlog containing the defects need to have the following information filled up by the development team

  1. Root Cause Category
  2. Detailed Root Cause Analysis
  3. Solution

Category for Root Cause has been set up as followed:

  • Back End – This defect is due to back end
  • Configuration – The defect was caused by incorrect static data setup
  • Environment – The defect has occurred due to a code base lining issue, server level configuration, etc
  • Existing bug – This is an existing defect in the system which is probably also present on the live environment
  • Impact Analysis – Thorough impact analysis has not been done and implicit requirements have been missed out
  • Injected defect – This defect has been injected due to a different defect fix.
  • Requirement – The requirement has not been clearly understood, the team’s assumption does not match with the business user’s expectations.
  • Testing Error – The test case was incorrect effectively resulting in an invalid defect getting logged
  • Wrong Implementation – The defect was caused due to an incorrect coding implementation
  • Others – Please reach out to Scrum Master to create the necessary category

Continue reading

Retrospective – Three Little Pigs


A retrospective that uses the famous 3 little pigs story. This retrospective is useful for reviewing processes and behaviors.

  • The STRAW house denotes processes and behaviors that are weak and should be dropped or changed.
  • The STICK house denotes processes and behaviors that seem to be working in the short term but will probably not last the weather.
  • The BRICK house denotes processes and behaviors that are strong and should encourage the team to continue to practice these processes.

This retrospective was used on a new team after 4 sprints (2 weeks each). This new team comprised of members from 2 different scrum team previously. At the start of the formation of this new team, the team agreed on a new set of processes.

Retrospective – Six Thinking Hats


Six Thinking Hats is a system designed by Edward de Bono which describes a tool for group discussion and individual thinking involving six colored hats. “Six Thinking Hats” and the associated idea parallel thinking provide a means for groups to plan thinking processes in a detailed and cohesive way, and in doing so to think together more effectively.

There are a total of six colored hats. Each hat help us focus on our thinking direction. I used the hats in the following sequence – White, Red, Yellow, Black, Green and Blue. I got the team to spend about 5 minutes of silent brainstorming and post-it writing before another 5 mins of going through the post-it notes.

White Hat – Fact and information about the iteration that has just passed. Similar to gathering data stage. Defects and stories delivered not delivered are part of the white hat. Planned leave and unplanned leave can also be part of the white hats.

Red Hat – How each of the team member feel during the iteration. The feeling does not need to be justified nor explained. We will not go into details on why and who wrote it for this hat.

Yellow Hat – What went well for the iteration. What are the good practices that we should continue to practice.

Black Hat – What did not go well for the iteration. What are the areas that the team should take note of for subsequent iterations.

Green Hat – What are the new idea/practices that the team can consider to adopt. Any proposal to change existing practices.

Blue Hat – What are the action items pertaining to Yellow Hat, Black Hat and Green Hat and who should own it with a timeline.