How to increase and maintain team motivation

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 that knowledge, however, we can free up their 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

Motivation starts with paying attention to the team and letting them know that you are paying attention. Both as individuals and as a team, they want you to listen to them, celebrate their achievements, and take what they say seriously. Attention is also the first thing a busy manager drops, so schedule it instead of leaving it to chance.

Meetings, meetings, and more meetings

I've never seen an engineer who wants to participate in multiple meetings that keep them 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.

The mix of engineering work has changed since this article was first published. AI coding assistants now absorb much of the routine implementation that used to fill a sprint. The 2025 DORA report on AI-assisted software development found that 90 percent of the developers surveyed use AI at work, and that 30 percent have little or no trust in the code it generates. Engineers therefore spend less time writing boilerplate and more time reviewing generated output, checking edge cases, and deciding what to build. Assign that judgment work on purpose instead of leaving it to whoever picks up the next ticket. A team that only reviews machine output, with no say in the design, loses interest quickly.

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.

For most teams that environment is now partly remote. Teams practicing agile in distributed development lose the informal signals a shared office provides, such as noticing that someone has been stuck on a problem for two days, or that a new joiner has stopped asking questions. Replace those signals on purpose. Keep work in progress visible in a shared channel, hold short one to one calls on a fixed schedule, and write decisions down so that people in other time zones can follow them. A manager who cannot see what the team is doing cannot recognize what the team achieved, and recognition is one of the strongest motivators available.

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 carrying substantial technical debt in agile projects, which 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 project goal 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.

Key Takeaway: Team motivation in an agile team rises when a manager knows each member's strengths, keeps every meeting purposeful, hands out challenging work, and sets measurable goals the team can realistically reach.

What does motivation research say about software teams?

Motivation research gives software teams three levers to work with: autonomy, competence, and relatedness. Self-Determination Theory, developed by Edward Deci and Richard Ryan, names these three as basic psychological needs and holds that supporting them produces the highest quality motivation and engagement. The rules above map onto them. Freedom to choose the approach is autonomy. Learning days and challenging tasks build competence. Showing interest in each team member builds relatedness.

The DORA research program has measured the same ideas inside engineering organizations. Its guidance on organizational culture uses Ron Westrum's three culture types, pathological, bureaucratic, and generative, and reports that a high trust culture that emphasizes information flow predicts software delivery performance and organizational performance. It also reports that a culture of psychological safety predicts software delivery performance, organizational performance, and productivity. In a generative culture, failure leads to inquiry instead of scapegoating, which is the working version of making room for mistakes.

DORA's guidance on job satisfaction is more concrete than a yearly engagement survey. It says satisfaction comes from work that is challenging and meaningful, and from being empowered to exercise skills and judgment, and it notes that employees rate meaningful work as highly as salary. It also treats tool choice as part of the same question, on the grounds that no one knows better than practitioners what they need to be effective.

Burnout points at the environment rather than the person. DORA's well-being guidance uses Christina Maslach's six organizational risk factors: work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, and value conflicts. Each one describes the work, not the engineer. DORA adds that most organizations try to fix the person and ignore the work environment, even though the data shows that fixing the environment has a higher likelihood of success. Slack time, covered next, is one way to reduce work overload directly.

Key Takeaway: Motivation research points software teams at the work environment rather than the individual, naming autonomy, competence, and relatedness as basic psychological needs and linking psychological safety to software delivery performance.

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. The core principles of Scrum have the team work 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.

Key Takeaway: Slack time is a deliberate gap between the sprint retrospective and the next sprint planning meeting that lets a Scrum team rest, absorb lessons learned, and arrive at planning prepared.

How does AI change motivation in engineering teams?

AI changes what the work feels like day to day, but it does not create motivation on its own. The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, reports that 90 percent of respondents use AI at work and more than 80 percent believe it has increased their productivity. The same report finds that 30 percent have little or no trust in the code AI generates. Its central conclusion is blunt: AI does not fix a team, it amplifies what is already there. A team with clear goals and psychological safety gets faster. A team with unclear priorities and an unrealistic sprint plan gets the same problems at higher speed.

Three practical effects follow for a manager. First, the balance of work shifts from writing code to code review of generated output, which is less visible and harder to recognize, so make review work explicit in planning instead of leaving it invisible. Second, unclear rules about what may be sent to a model add friction, which is why the DORA AI Capabilities Model puts clarifying and socializing AI policy first among the capabilities it names. Third, autonomy still matters. A team that only checks machine output, with no say in the design, loses interest quickly, which is the same competence and autonomy problem described earlier in this article.

Treat AI adoption as a change to the working environment, not a productivity switch. The measurable goals, slack time, and honest prioritization described above matter more once the team is moving faster, not less.

Key Takeaway: AI amplifies an engineering team existing conditions rather than replacing them, so a clear AI policy, recognized review work, and real design autonomy are what keep motivation intact as adoption grows.