In a previous post describing challenges to creating a done Increment, I identified a lack of team ownership as one of those challenges. 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?
In my experience, there are five common problems that prevent a Development Team from feeling 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. An example is to have each person draw a timeline of their lives with respect to family, education, work, interests, geography, and peak experiences. This allows people to realize connections with each other. The team will learn what experiences have shaped each person over time.
- 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 a lot of 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 are not 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. Here are some examples of what this might look like. “Just to clarify, is this the product backlog item you’re talking about?” and point to the card on the Scrum Board. “Should we break this down into more granular tasks so our progress is clear and others can jump in to help?”
- 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. Use this technique in both team and individuals discussions to continue to reinforce that we are in this together.
- 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?” After asking a question like this, you may have to stay silent… for a really long time. Someone will eventually fill the silence.
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. Don’t 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 to encourage 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.
- Stop doing this. 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. This will also create more capable, happier employees.
- If we must do it, limit it. Reduce the number of teams an individuals 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.
If you think one of these problems is affecting your team, pick a technique and try it. Let us know how it goes.
Check out the rest of the series on Getting to Done:
