How Do You Motivate Agile Teams to Become High-Performing Teams?

How Do You Motivate Agile Teams to Become High-Performing Teams?

Most people have no idea how to motivate agile teams or create high performing teams. And even if you tell them, they don’t seem to remember or care.

I’ve had more than a few conversations over the last few years that led me to this conclusion, and I have heard some pretty outlandish and offensive things.

  • “the teams are lazy”
  • “I know I would treat this with more urgency than they do”
  • “can we tell who is working on what?”
  • “for what they are paid, they should work a lot harder”

In each case, it started with someone outside the Development Team who was frustrated at the Team’s pace of delivery. They talked about ways to somehow motivate the team.

I even had a Product Owner demand that a development team work overtime and weekends to hit a key delivery date that was promised by someone outside the team. That product Owner didn’t see that the lack of team autonomy directly impacted their motivation.

In all cases, there was a lack of trust and a desire to push or motivate the team in some way. These people viewed the team as unmotivated and they believed that they needed to do something to motivate the team. They wanted to either offer a reward or threaten a punishment. These efforts work to create high-performing teams, right?

Can You Motivate Someone Else?

Traditional thinking is that you need to use a combination of rewards and punishments to motivate people who would otherwise be unmotivated. People are generally lazy and unwilling to work, that is how this theory goes.

We need to offer them a bonus to get their discretionary effort. Maybe we buy them pizza. Maybe we circle around to check up on them and see what they are working on. Or we can threaten layoffs to light a fire under their asses!

There is another more modern line of thought that says that the carrot and stick approach may work on menial tasks, but it doesn’t work at all with knowledge workers (that is, almost everybody these days).

This approach says that knowledge workers are intrinsically motivated and that efforts to use rewards and punishments will only backfire. This line of thought, popularized by Frederick Herzberg and more recently by Daniel Pink, encourages leaders to create the conditions that tap into team members intrinsic motivation.

This includes giving people control over their work, providing opportunities for challenge and mastery, and aligning their work with a higher purpose.

This is actually really exciting news. We can avoid throwing money, corner offices or inflated but meaningless titles at someone. Instead, we can just hope they are internally motivated.

But wait, how do we do that? It turns out, we need to set the stage by creating the conditions for high performing teams.

Creating the Conditions for High Performing Teams

Rather than trying to motivate people, another approach is to take people that are already motivated, put them on teams, and then create the conditions for them to do their best work.

Forget the carrot and stick. Instead, set the context and environment. Focus on creating the conditions favorable to self-motivation, creativity, and productivity.

In an Agile environment, whose job is it to create the context and environment? Is it the managers or leaders? Scrum Master? Product Owner? Or the team themselves?

It turns out it is everyone’s job. Creating an environment for people to do their best work works best when everyone helps.

Leaders and Managers Set Up Conditions for High Performing Teams

Leaders and managers play a big part in setting the context for success. Some of the ways that they do this include:

  1. Get the right people on the teams, based on the work to be performed.
  2. Train the teams on the technology, the business domain, Agile and Scrum and anything else that will help them perform well.
  3. Align the team with a product, backlog and product owner.
  4. Give people time and opportunities to learn and grow, to develop mastery of their craft.
  5. Empower the team – truly empower – so that they make as many of their own decisions as possible.
  6. Continuously remove organizational impediments from the team.
  7. Cast a vision for the work and how what the team is doing connects with the purpose of the organization.

Scrum Masters Coach and Protect the Team

Scrum Masters usually work directly with the teams, coaching them to self-organize and protecting them.

  1. The Scrum Master should teach Scrum and foster Team Self-Organization. The Scrum Master Holds a mirror up to the team to help them inspect and adapt. They ask thoughtful questions and provide their own observations. [See Succeed with Scrum, Don’t Break these 7 Rules]
  2. The Scrum Master protects the team. Sometimes this means creating a buffer to protect the team from outside distractions, including questions about productivity.
  3. The Scrum Master may need to Coach Stakeholders on their interactions with the team to make sure they are productive.
  4. The Coach and Scrum Master can find ways to foster Servant Leadership in the Product Owner, Leaders, and Managers. What are the obstacles to the team that they can remove? What needs of the team can the PO or leaders support? This shift in mindset can help reduce the focus on ‘fixing’ or controlling the team.
  5. Educate – The Scrum Masters can help to educate leaders, managers and product owners on motivation, and support them to create the conditions for high productivity.

For more about the Scrum Master Role, see Puzzled About the Scrum Master Role.

Everyone Should Do This

Managers, leaders, Scrum Masters and even Product Owners should be willing to do what they can to help the team.

  • Serve The Team’s Needs

    The team may not need much, but having the attitude and willingness to serve them sends a strong message. Be observant, and look for needs that are not being met for the team and ways that you can meet them. Ask “What can I do to help?”.

  • Hold the Team in High Positive Regard

    I wrote about the concept of positive regard in the 2nd edition of my book, Emotional Intelligence for Project Managers. Positive regard is assuming that individuals are whole and complete and have the ability to figure things out for themselves.

    It is based on the field of humanistic psychology pioneered by Carl Rogers. Rogers believed that all people are inherently good and that they have all the internal resources required to grow as individuals. Coaches and SMs need to expect the team can perform at high levels and solve their own problems.

  • Continually Foster the Team to become a High Performing Team

The managers, leaders and Scrum Masters should expect high performance from the team and do all in their power to encourage it.

What do you think? Do you think that we can create the conditions for teams to be self-motivated?

Anthony Mersino

Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.

This Post Has 3 Comments

  1. A very good article as it
    A very good article as it shares lot of insights. Saying that, a similar trust or environment is not created or not appreciated when teams supporting product/project development is a vendor

  2. Happy New Year to you, your
    Happy New Year to you, your readers and everyone’s families.

    Your article has great tips. You and your readers might find the October 11, 2014 WISN (1130 AM) radio broadcast of interest. I was on the broadcast with Don Rheem (CEO, E3 Solutions) and George Satula (TEC Chair, The Executive Committee, A Vistage Company). A link to my post with a link to the recorded broadcast is provided below:

    You can also access with the broadcast from the following short link:

    I wish you the very best in 2018!

  3. Good to hear from you and thanks for sharing the link. Anthony

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu