Getting to Done: Encouraging Team Ownership

DZone 's Guide to

Getting to Done: Encouraging Team Ownership

Among the problems that prevent a sense of team ownership are a lack of trust within the team and team members being split across too many teams.

· Agile Zone ·
Free Resource

In a previous post describing challenges to creating a Done Increment, I identified a lack of team ownership a challenge. The Development Team is accountable as a whole to create a Done Increment by the end of the Sprint. When team members do not feel team ownership, individuals focus on getting their product backlog item done.

There is not a focus on the outcome of the Sprint.

In order to use Scrum effectively and have transparency over our progress and quality, we must create an environment that encourages and enables team ownership. This is easier said than done. It often involves people changing both their mindsets and behaviors. There is not a recipe to follow that will guarantee team ownership. So, how can we influence team ownership?

Here are five problems that prevent a sense of team ownership.

1. We Do Not Have Trust Within the Team

When we do not have trust, team members are not comfortable being vulnerable with each other about their weaknesses, mistakes, or fears. Team members are afraid to admit when they are stuck on a problem and to ask for help.

The solution is to build trust. In the agile community, we talk a lot about building trust. But how do we do that? This is a big topic. Here are a few ways to get started on the path to building trust.

Help team members get to know each other’s histories, behaviors, and interests.

  • Using a tool like MBTI or DiSC can help team members become more aware of how they perceive and behave in the world, and this opens the door to discussing strengths and weaknesses as a team.
  • Create a team activity for people to share their personal histories.
  • Facilitate a team discussion where each individual shares strengths they bring to the team, strengths they appreciate in others, and what area they want to personally grow.

Set the example by relying on your team members.

  • Demonstrate curiosity. Ask open-ended questions of the team to encourage them to share their own ideas.
  • Be vulnerable. Ask for help. Admit mistakes. Ask for feedback. You may say, “Can you take a look at this? I might have missed something and would appreciate your perspective.” By demonstrating vulnerability, you are showing others that it is okay.
  • Make explicit that there are a lot of unknowns with complex software development. We need to have everyone’s unique perspectives, knowledge, and skills in order to succeed.

The more we learn about each other, the more comfortable we get being vulnerable. We feel safe. As we get more comfortable being vulnerable with our team members, trust will grow. This often takes time, so we need to be patient and continue to demonstrate.

2. Team Members Aren't Aware of the Team’s Overall Progress

We need to make information transparent so that the team can easily discuss progress, identify problems, and determine solutions together.

  • Help the team use a visual Scrum Board to see their progress. Reference the visual Scrum Board whenever discussing work with other team members.
  • Track impediments brought up by the team over time. The team can inspect the impediments in a Sprint Retrospective and look for recurring themes.
  • Understanding WIP (work-in-progress) or how much time is spent waiting on others can help a team identify where they see waste and bottlenecks.

Regularly bring up the shared accountability of creating a Done Increment.

  • Change the language to “we.” We succeed as a team, and we fail as a team.
  • If somebody brings a challenging issue to your attention, encourage taking it to the team for discussion.
  • Ask questions such as, “How do we feel about our progress towards the Sprint Goal?” or, “What do we think is the most important thing for us to focus on and achieve today?”

3. Teams Are Not Empowered

It is difficult to feel ownership if you do not have the power to make decisions about how to best achieve desired outcomes or goals. Management needs to empower teams, yet simply declaring, “teams are empowered,” does not usually make them feel empowered. This empowerment must be demonstrated by management. This is another big topic. I will focus on helping managers identify behaviors that help or undermine their desire to empower teams.

  • If a manager provides solutions when individuals bring him or her problems that are best solved by the team, this will continue to reinforce the manager’s role as “expert” or “decision maker.” Coach the manager on how to use open questions to help the person identify possible solutions or approaches.
  • Demonstrate trust and confidence in the team. This can be directly stated as, “This sounds like a difficult decision. You are the ones closest to the work, and I trust your judgment.”
  • Be okay when outcomes are not as expected or desired. This can often require standing up for and protecting a team when they fail. Failure (done right) is another word for learning.
  • Do not commit to dates or deliverables on behalf of the team. This completely undermines team ownership. Do not succumb to this pressure. Let the team own their forecasts, and appreciate the unpredictability of their work.

4. Individuals Are Rewarded Instead of Teams

Many organizations have performance review processes and ingrained management behaviors that reward and recognize individuals. There is not always a comparable effort to reward and recognize team success. Here are some ways toencourage the team to focus on team outcomes without changing the entire organization.

  • Recognize individual behaviors that cultivate team ownership. When you see a team member helping someone with an issue or peer reviewing his or her work, recognize that positive team behavior. Maybe write your appreciation on a sticky note and silently hand it to the team member. Consider creating a “kudos” tradition after the Daily Scrum or at the beginning of the Sprint Retrospective.
  • Celebrate team successes. When a team achieves the sprint goal and creates potentially releasable software, celebrate it. When a team implements a major retrospective improvement action, make it a big deal. Do the wave. Go to happy hour. Create a chart in your team space to visualize these successes. Make it fun and meaningful.
  • Coach managers to recognize team successes. It can be as simple as stopping by the team space occasionally to pass along positive feedback or to ask what the team needs.

If you are interested, read more about how annual performance reviews are dead.

5. Team Members Are Split Across Multiple Teams

This situation often arises when we have created bottlenecks of knowledge or skills.

  • Create action plans to share knowledge and skills with the teams that need it in order to create a Done Increment. Yes, this will take time and effort. This will also reduce the costs and effects of context switching over time.
  • If we must do it, limit it. Reduce the number of teams an individual is assigned to (no more than two). Plan work to prevent context switching. Create blocks of time that allow focus. Yes, this will limit each team’s ability to plan their own work and may create some waiting times.  That is the reality of accepting this impediment.
  • Make the waste transparent. Track the number of times a team is blocked and for how long when they are waiting for the shared team member to be available. Track the number of times a shared team member has to switch focus during a day. This factual information can help make the case to management to invest in fixing this impediment.

In summary, team ownership is an important factor for enabling the shared accountability necessary in order to create a Done Increment every Sprint. We can help our teams get past this challenge by taking steps to address the common problems presented in this article.

agile, agile implementation, scrum, sprint, teamwork

Published at DZone with permission of Stephanie Ockerman , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}