Once upon a time I had to work with a project team that was supposed to use Scrum. The very first thing I discovered was their motivation, or rather their lack of it. Some developers left the project team upon my arrival, and a few others were getting ready to think of new career opportunities. Motivation is a critical part of a successful Scrum Team. It has to be in place if both management and customers are to receive sustainable and predictable results. Motivation can be compared to a car that’s designed to move the project team from point A to point B. In order to have the project team’s car in proper condition, we have to fuel it and maintain the engine. Willpower is fuel for motivation and its engine can create the required driving force. Given this metaphor, I would then ask some questions. What are the main parts of the motivation engine, and what’s the best way to maintain it?


What is the source of the willpower, and how do we get it?

Main Components of the Motivation Engine

Intrinsic motivation consists of Purpose, Autonomy and Mastery. All these parts are critical for the motivation engine to create a driving force, and the process usually starts inside the brain. It sends a signal to move forward so that the anticipated result can be achieved.

The brain needs to understand the real purpose of why my efforts are directed on a specific task. Usually it sorts the list of tasks depending on the importance of the purpose. For many reasons, protecting the life of children is interpreted as a more important task than sitting and playing guitar. The importance of the purpose is usually defined by its perceived impact on the life of other people. If I want a developer to think of his tasks with some enthusiasm I need to give his brain a good reason. If I want a developer to go further and be more effective, I need to extend the reason to new horizons. A passion to work smart can grow as the purpose is becoming closer and I can see positive impact on the lives of other people. Shared purpose in the project team can create huge synergy to collaborate and improve our ways of working. The shared purpose should be stronger than any other personal agendas. A team that lacks a shared purpose dissolves into a group of individuals, and when that is the case we risk seeing some other purposes go ahead and motivation being expressed in other things.

My brain requires some space for experimentation. I want my ideas to be accepted by others, or at least to be heard and challenged in a good way. The sense of freedom is defining the level of my motivation to work on specific tasks. In my “list to do” I would rather prefer to work on something that gives me the freedom to experiment. When a developer is lacking the autonomy to act, he may be cheating with predefined tasks so that he can save some time to experiment with his personal ideas. After some time, a developer typically looks for other places to work in order try the results of his secret experiments.

My brain is passionate about facing new challenges. I like to solve puzzles and in my personal “list to do” I would prefer tasks which push my intelligence to work harder. Solved puzzles are collected as achievements which I can express in conversation with other people. Improved mastery is a key for smart workers, as it gives a sense of security and confidence. On the other hand, if the specific task is getting boring I can interpret it as I stopped to improve and most likely I lost interest to continue working on it.

You can find these motivational elements in Daniel Pink’s Drive. An important lesson to take away is that motivation has to be understood not simply as a skill we can develop or something we can train - it is something which is tightly coupled with the external environment. A motivated Scrum Team requires all these components to be in place. Project tasks should be articulated the way they would appear in someone’s “list to do” higher than anything else. This can be achieved if the project task is expressed as a great problem to solve, allowing for the freedom to choose how to solve it and developing the competence to complete it in a more effective way than before. This is the engine part of our motivation.

Maintain Willpower

The engine cannot work properly without fuel, which is the willpower to move forward. Luckily, we were created in such a way that willpower is recreated once per 24 hours for free.

During the day we have a normal eight-hour sound sleep. This is the main source of our willpower, but not the ultimate. A healthy style of life is explained by many studies as eight hours of work, eight hours of rest and eight hours of sleep. It should include some physical activities, time spent in fresh air, and a good diet. This brings the required amount of fuel for our motivation engine during the day, but not more, as it is a limited resource. Short sleep, overtime, and a bad diet can cut the willpower fuel tank in half at the beginning of the next day.

No Stress
Stress, unresolved conflicts, miscommunications, blame games, personal attacks and all other kinds of threats are like holes in the fuel tank of our motivation. All that stuff easily eats on the willpower tank and then we don’t have any additional resources to work on complex intellectual tasks.

Repeatable habits
Good habits help to save willpower. We don’t spend any fuel when we do some things unconsciously, like brushing our teeth in the morning or washing our hands before eating. In Scrum we have some repeatable rituals that can turn into good habits. The Scrum Framework is built the way it is to save a good amount of the willpower of the individual members of the Scrum Team. Saved willpower is the source of team growth, healthy projects, effective knowledge acquisition, optimized creativity, and productivity.

Motivation Diagnosis

As a first step to work with a team’s motivation I would recommend to assessing their current state. I like to speak with different people in the project team and ask some questions to check if they have the purpose, motivation, and mastery components. Examples of good questions can be found below:
  • Purpose: Who are the end-users of your application? How are they going to use it? What is the purpose of the application/product? How will your organization save or earn funds thanks to your application? What business problems can be fixed by the task you are working on? How do you measure that?
  • Autonomy: How do you prepare designs for new features? What were some ideas you have recently promoted? What worked well among your ideas? Not so well?
  • Mastery: What is the most interesting thing you have learned in this project? What is the most interesting development practice you have tried? What was the most interesting technology you investigated in the current project?


Depending on their answers, I can easily identify the level of motivation in a team. I can also identify the broken parts of the motivation engine. This gives me a very good picture of how to use Scrum to fix problems with motivation.

Scrum as a Tool for Increasing Motivation

If the Scrum Team doesn’t understand their purpose, I can restore it in several ways. I can ask the Product Owner to visit the team and run a Product Discovery workshop, collaborate on personal profiles, rewrite a Product Backlog with User Stories, or ask the Product Owner to avoid technical details on PBR meetings and share only business context. I can ask stakeholders to participate in Sprint Review meetings to inspect current increments and provide constructive feedback to the Development Team, possibly by sharing some success stories of business growth.

If the Scrum Team doesn’t make technical decisions, I would find a way to transfer required knowledge or skill, whatever is missing from the customer perspective. We can probably run design workshops with external people, institute remote pair programming, begin interactive code reviews, improve the self-organization of the team, and remove managers from the Scrum meetings.

If the Scrum Team doesn’t have enough challenging tasks in their Product Backlog we can always find some creative ways to improve the craft of the software developer. Test-driven development, refactoring applying design patterns, finding new ways to automate the manual work, optimization of the work, and code dojos should all result in better performance, higher quality, and fewer defects.


I hope this article can help you start working on motivation with your development teams. We’ve been exploring motivation from the developers’ standpoint, but what about motivation of the Scrum Master? I think that the purpose of the Scrum Master should be the same as the Development Team – a focus on product, end-users, and business. The autonomy of the Scrum Master can be expressed, as he has the freedom to try new ways of leading the Scrum Team. I work to change the context and environment for my Development Team so that it feeds a ton of motivation – and I enjoy it!

Good luck and Scrum On!