Agile Teams: When is an Impediment Just a Complaint?


Agile Teams: When is an Impediment Just a Complaint?


In Scrum we often talk about impediments: Scrum Masters should remove impediments; team members should raise impediments at the daily scrum; and everyone should make impediments visible, to help get them solved.

Physical impediments are easy to notice and quick to solve. Things like getting hardware for a build server, or getting a whiteboard in the team area.

Other complex impediments like regular production stability issues, or long automated build times are more difficult to solve. They require root cause analysis and a multipronged approach. Often, they are even difficult to identify because people have become so accustomed to them, they no longer even see them as a problem.

What about an organization's cultural impediments?

Recently, we brainstormed impediments with a group of new Scrum Masters at a large corporate organization. Here are some of the things they listed as major impediments:

  • Some stakeholders are resistant to agile
  • There is a lack of support of agile from management
  • The team lacks the authority to get other departments to work with them
  • The Product Owner tries to control the team too much
  • At first these might look like reasonable impediments. But take another look. Imagine you are the team’s manager or Product Owner, and read them again.

Don’t they sound like the team is complaining? Every one of these "impediments" is about how someone else is the problem.

Can you imagine what might happen if the team made these impediments visible on a whiteboard? Most likely it would create conflict and damage some relationships.

So what can you do instead, if these sound like impediments you have?

  • Make sure you understand if there is a real impediment to the team, or if people are just complaining
  • Phrase the problem neutrally, without blaming anyone
  • Gather concrete examples and data about how this problem impacts the team
  • Look for solutions for what the team can do to reduce the impact, and ask for help from others to solve the problem together
  • Let’s take the following impediment as an example: “There is a lack of support of agile from management.”

In this case, the team felt this way because the Scrum Master role was not considered a full-time job by management.

The real impediment here is that the Scrum Master role is new in the organization, and therefore not well understood or full time.

The impact to the team is that they skipped their last retrospective because the Scrum Master was too busy with other work to prepare for the retrospective.

As a result, the team did not have an opportunity to discuss a process that was not working for them, and they continued to use this process, causing delays, miscommunication and rework.

Given this impediment, there are a number of actions that can help. For example:

  • Have the Scrum Master keep a journal of everything they do for a week, and share that in a learning session with others to spread awareness about the role
  • Agree as a team that if the Scrum Master is too busy, someone else on the team will prepare and run the retrospective
  • Run an agile training session for managers to explain the roles in Scrum and why they are important
  • Ask management to try an experiment of allowing one person to be a full-time Scrum Master for 3 months, and assess at the end how it worked
  • Google the problem to see how other companies have solved this
  • Now imagine if I made this impediment and the action ideas visible? Do you think I am more likely to get support?

Going forward, when talking about impediments, and making them visible, focus on the problem and the impact, rather than blaming someone for them. You might be surprised how much easier that makes them to solve.

Remember that there is always something within the the team's control that can be done to help remove the impediment.



 

My personal motto is ‘be brave’, and I embody this by taking on challenges one small step at a time. Most of my career has been in the IT industry, specifically Software Development. I co-founded Growing Agile and spend most of my time guiding and mentoring others with a passion for agile. I love that online training allows me to spread this passion world wide.

Learn More
comments powered by Disqus