How to increase and maintain team motivation

The best agile teams are built from people who work together as one unit, where each team member has both the technical and the personal skills to allow the team to become self-organized, cross-functional, and self-motivated. These are all big words that I hear in almost every agile project. Still, the criteria to make a fantastic agile team are practically impossible to achieve without one major factor: motivation towards a common goal.

So how can we improve team motivation and sustain it throughout the project? Before answering this question, I want to review the two types of motivation we must encourage within the team to promote success: Intrinsic and extrinsic.

Intrinsic motivation refers to behavior driven by personal internal rewards, without the need for an external boost to increase motivation. This motivation is related to the desire to succeed and achieve a specific goal. The primary key for this type of motivation is that we must ensure that each team member has the chance to meet expectations as a member of a team and accomplish their personal goals that will most likely increase both their own and the team’s results.

On the other hand, extrinsic motivation refers to an external motivating factor such as vacations, bonuses, salary increases, or just getting a paycheck at the end of the month. We can treat this type of motivation as a desire to do something to achieve a specific reward. To allow the team to become self-organized, cross-functional, and self-motivated, we must cover both motivation types while searching for a balance between organizational and personal goals. One thing that I learned throughout the years is that there are no shortcuts. We must know our employees and the factors that motivate them. This is the only way to achieve both personal and team success.

The path to creating a highly motivated agile team

Here I will share the most effective rules and principles to increase individual and team motivation. I know that there are many other methods that you can use in one situation or another. Still, I never had a motivation problem that I could not resolve by using one of the following approaches.

Treat all team members as equals but know their differences.

A scrum team is built of different people assembled to achieve a common goal. It is nice to say that all team members are equal, but not. We always need to remember that each team member has skills, knowledge, and experience. Although we need to ensure that each member works under the same set of rules, guidelines, and goals, as they are equal within the team, the next level is to understand which team members are more suitable for accomplishing specific goals that may arise during a challenging development project.

A great example of this issue is a technical lead who is part of the team with vast knowledge of a specific technology that the team will use throughout the project. This technological lead will still work under all other team members’ exact rules and boundaries. Thanks to his knowledge, however, we can free up his time to focus on a single area and move all other activities (activities which may be less prestigious in the eyes of other team members, such as bugs, dealing with customers, and closing technical debt) to other team members.

Show interest in the team and its members

You learn that motivation starts with just paying attention to the team and letting them know it throughout the years. Think about them as your child who wishes for a good word once you return from work, or how important it is for him to hear your appreciation for what he achieved today in school. They, like your child (as a team and as individuals), want you to listen to them, celebrate their achievements, and pay attention to what they have to say.

Meetings, meetings, and more meetings

I’ve never seen an engineer who wants to participate in multiple meetings that keep him from working. The scrum framework contains various events, which can be a motivation killer for those engineers who do not understand why they need so many meetings that interfere with their ability to remain focused. This is especially true for new teams that just started working this way. It is essential that each added meeting makes sense to the team; otherwise, it is just one more meeting that’s holding them back. If you add meetings, make sure they have a clear plan, so the team does not feel like wasting their time in an already busy environment.

Increase interest in challenging tasks

Some people prefer to have some changes in their day-to-day work that allow them to regain their excitement and interest in what they are doing. There is some sense of excitement at the start of the project, and when starting agile, there are massive changes in all aspects of the team’s work, which is enough to keep their interest. After this period, the team will already have gained most of the knowledge needed to work in this framework. They will focus their attention on the ongoing daily activities that are part of every sprint (meetings, handling defects, etc.).

Team members may start to lose interest due to the repetition of activities without any new challenges. The best solution, in this case, is to break the routine by adding challenging tasks that will help the team regain their motivation and interest.

Supportive working environment

The working environment plays an essential factor in determining team motivation. Remember that the team will spend most of their effective hours at work. Therefore, it is necessary to ensure that they have a supportive and pleasant working environment where they feel comfortable working and developing as a team.

Set goals that will not fail the team to begin with

Think about a leader who sets unrealistic goals for the team, such as delivering features at the end of a sprint that the team has neither the knowledge nor the experience to handle nor asking the team to complete an integration with another team. However, the second team will not be ready on time or ask the team to deliver a feature during a sprint that involves multiple external interruptions that will consume most of their time.

Setting a goal that a team does not have a real chance to meet is probably one of the most significant grounds for reducing team motivation. Will you have the right motivation after you need to present a demo of your work at the end of the sprint but fail to do it because you have been given an unrealistic goal? I guess not. To make sure we allow the team to see success, the team must work with clear, visible, and above all measurable goals that will enable them to succeed with a smaller chance of failure right from the beginning.

One classic example is a team with substantial technical debt that affects their ability to deliver real value to the customer. In such a case, we can reduce this technical debt by five to ten percent per sprint. By setting such a goal, we can ensure that the team understands what is expected of them and measure it from sprint to sprint. In addition, the team will have the opportunity to create a plan and add all relevant stories related to this goal, increasing transparency for external stakeholders.

Creativity that comes from absolute freedom

There is a reason why you hire intelligent people, and there is a better reason why we need to provide them with the freedom to use their creativity while working on tasks. My rule is that you need to set guidelines for any task but allow the team to use their imagination in deciding how they want to reach the objective. Following this simple rule will enable the team to find superior solutions to problems based on what they thought was the best solution instead of just giving them some strict guidelines that will kill room for innovation.

Make room for mistakes

Mistakes are part of every solution and cannot be avoided. Team members will make mistakes no matter how talented and committed they are. The key here is to set clear boundaries that allow them the freedom to work and use their skills but reduce the percentage of mistakes that will severely impact the organization. In addition, we must make sure that each member has the confidence to make mistakes because there are no “punishments” that will keep them from trying again.

Be clear about the prioritization

You all know that the product owner is responsible for ensuring that the stories are prioritized to provide the best ROI for the customer. How is prioritization related to team motivation? Think about a planning meeting where the team must decide which stories will take place in the next sprint but with a product owner who fails to perform his job and does not prioritize the product backlog. Will it increase motivation? Probably not, because it will lead to an inefficient, long, and less-focused meeting. If the team had a prioritized backlog, it would maintain focus without losing time on other stories that the PO later decides are less critical because he failed to determine them earlier.

What is slack time and why is it important for your team?

As in real life, you can’t sprint all the time. If you’re not a robot, you need to rest between sprints. What’s true for the best athletes is also true for the Scrum team. In Scrum, the team works in short intensive sprints of 1-4 weeks. This is different from traditional software methodologies which are more like running a marathon.

Scrum sprints are intensive because their primary purpose is to provide value to the customer waiting at the end of the sprint. At the start of the Sprint, the team creates the sprint backlog reflecting their commitments and needs to work very fast in a constantly changing environment. Each team member works in an intensive environment that does not usually allow time to relax and put off their tasks (the customer is waiting…).

“Slack time” provides the rest time the team needs to regain their strength. But that’s not all; it also helps increase team motivation and morale (essential factors for creating self-organized teams).

The common practice in the industry is that the Scrum team starts the planning meeting right after the retrospective is over to begin the next sprint on the first day of the following week. The problem with this approach is that the majority of the team will not be focused enough to conduct an effective meeting. They didn’t have time to stop and think about all the information and lessons learned from the previous sprint. In addition, the PO will not have time to prepare the backlog (based on the feedback received during the retro/review meetings), and so on.

Give the team some slack.

The solution to the problem identified in the previous section is introducing some slack before the team starts a Sprint. It would help if you gave the team time to rest and think about the last retrospective before the next planning meeting.

Here are some examples of using slack time in your environment:
Without slack time:
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 13:00-17:00: Sprint planning (Sprint 2)

With slack time (option 1):
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 12:00: slack time.
Monday 09:00-13:00: Sprint planning (Sprint 2)

With slack time (option 2):
Thursday 08:00-09:00: Sprint review (Sprint 1)
Thursday 10:00-11:00: Sprint retro (Sprint 1)
Thursday 11:00: slack time.
*Friday: Learning time
Monday 08:00-12:00: Sprint Review (Sprint 2)

*Note: in option 2, I added another day (Friday) the team can use for learning activities or do whatever they think is best for the team effort.

If you decide to use the slack time as learning days, these tips can help:

Learning days should be added per month and not after each sprint so that we will add one learning day at the end of the second sprint in the case of two-week sprints.
Try to make this day company-wide; it becomes less effective when some teams work and others rest.
Although this time is dedicated to the team, you still need to see that it adds real value. There is no reason to use these days without adding real value to the team, process, or business.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile