How Do You Motivate Agile Teams?

Anthony Mersino
February 20, 2015

Two conversations in two days have concerned me in my role of agile coach. In the first, I had a product owner and his assistant expressing frustration at the current pace of development for 3 scrum teams. In the second conversation, an person assisting another product owner, similarly concerned, asked the scrum master for the team to begin to track who on the team was working. In both cases, the product owners for the teams lacked trust and wanted to push or motivate the team in some way.

Which led to my question, how do you motivate agile teams? Traditional thinking is that you need to use a combination of rewards and punishments to motivate people who would otherwise remain unmotivated. People are generally lazy and unwilling to work, that is how this theory goes. Maybe we buy them pizza. Maybe we circle around to check up on them and see what they are working on.

There is another line of thought that says that the carrot and stick approach doesn't work, except with the most menial tasks. 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 conditions where people will be motivated. This includes giving people control over their work, providing opportunities for challenge and mastery, and aligning their work with a higher purpose. How does an agile coach go about encouraging the product owners to let go of their carrot and stick thinking, and instead create the conditions where teams flourish? I'm not sure! Here are some thoughts:

  1. Create a Buffer - The Agile Coach and Scrum Master need to create a buffer between the PO and the team to protect the team from distraction. The buffer needs to be selective because frankly the PO and the Team should generally be in close communication. We want to protect the teams from the distraction of questions about productivity, and channel those questions to the Coach or Scrum Master. The concerns might be valid, and in that case it is up to the Coach or SM to figure out a way to bring it to the team so that they can solve it.

  2. Model and Teach Servant Leadership - The Coach and SM can find ways to foster Servant Leadership in the PO. What are the obstacles to the team that they can remove? What needs of the team can the PO support? This shift in mindset can help reduce the focus on 'fixing' or controlling the team.

  3. Address the Underlying Concern - Talk to the PO and really work to understand exactly what they are concerned about. Validate their concern, or at least validate that you hear and understand the PO. Explore ways to translate his concern into something productive.What is he concerned about, what is he trying to accomplish?

  4. Educate the Product Owner - I usually flinch when a team member says we need to teach the PO something. Generally I find that efforts to educate anyone is an uphill battle, especially if the target of my efforts isn't interested in being educated. That said, I do think that we have to do our best to help POs understand what motivates, and how to create the conditions for high productivity.

Though it sounds passive, the focus of the Coach and SM need not be on motivating the team. The focus should be on creating the conditions where self-motivation, creativity, and productivity flourish. Agile is a change in Culture! Possible actions to affect culture change include:

  1. Fostering Self-Organization - Holding a mirror up for the team to help them inspect and adapt. Ask thoughtful questions. Provide your observations.

  2. 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?".

  3. 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.

  4. Hold the PO in Positive Regard - Product Owners are human beings too! Like all humans, they have their own fears and self-interest in mind, and they attack, blame, and justify when they feel their interests are threatened. We ALL do it! It helps me to hold them in positive regard and to trust that they are generally acting in the best interest of the organization and their needs have value.

What do you think?  What kinds of relationship exists between your Product Owner and Scrum Teams?

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.

Comments

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

Do you feel the PO able to objectively compare and contrast the "... current pace of development for 3 scrum teams."?