Enrollment for the April 16 live virtual mini-workshop Creative vs Reactive Leadership is open . GET THE DETAILS

Getting to Done: Tackle Impediments

Published January 22, 2024
by Stephanie Ockerman

In a previous post describing challenges to creating a Done Increment, I identified impediments as one of those challenges.  More specifically, NOT removing the impediments makes it difficult to create a Done Increment.  Scrum Teams will always face impediments because the work is complex and dynamic.  The question is whether we tackle those impediments or live with them.

impediments

An impediment is anything that is slowing down or blocking a team from delivering working software.  Impediments could be related to technology, process, or interactions.  It is easy to get overwhelmed by the expectations of delivering more product features faster and feel like there is no time for implementing improvements.  However, removing impediments helps improve workflow and can result in higher quality and easier delivery of enhancements in the long-term.

In my experience, there are five common problems preventing teams from tackling impediments.

1 – The team is not empowered.

I talked about team empowerment related to the challenge of team ownership.  Empowerment comes into play again here.  When a team cannot make decisions about how they do their work, their ability to improve is limited.  Their ability to adapt to challenges is limited.  Their ability to take advantage of opportunities is limited.

  • Make the Development Team’s accountability explicit. They turn the Product Backlog into working software.  And as professionals, they are expected to do this to the best of their ability.  This means they must manage and improve upon their processes, tools, and interactions to be more effective in delivery.
  • Coach management on how to create an environment of empowerment.
  • Question how we do things.  This could be processes or practices that the team owns or something that exists in the organization.  Asking bold and outrageous questions can help your team start to take their power.
  • Ask for forgiveness, not permission.  A Scrum Master can be the one to show courage first in “taking power” if the team does not yet feel their own empowerment.  A Scrum Master should be prepared to protect the team when they do exercise empowerment.

2 – We confuse constraints and assumptions.

I have seen people assume they have to follow certain processes or use specific tools because it is a constraint in the organization.  When I teach Scrum Training Courses, I explain that constraints help maximize self-organization.  However, the majority of “constraints” I have come across are usually not constraints but rather recommendations or best practices.  People assume they are constraints and don’t question it.

Some constraints have exception processes if you have good reasons for doing something differently or not at all.  For example, an organization I coached required the use of a specific testing tool.  But if you did not think it was the best tool for your team and your product, all you had to do was document an exception and explain how your team was doing testing and capturing results.

I recently heard an example at a conference of a team who actually worked with regulators to influence policies that they saw as impediments to software delivery.  How awesome is that!

Question everything.

Help your teams come up with bold and wild ideas.  What if we could do anything we want to solve this problem?  What would that look like? 

You might actually be able to try out those crazy ideas.

3 – Impacts of impediments are not understood.

Does your team have recurring impediments?  Do the impacts of those impediments seem small or large?

For example, you have to fill out a form to get permission to access a database.  This need arises about every other Sprint.  It takes 10 minutes to fill out the form, and there is 24-hour turnaround.  Not a big deal, right?  What if you sometimes have to follow up to clarify the permissions needed because the form isn’t that clear.  Whoever has to deal with this usually gets frustrated and vents to the team while trying to resolve it.  But at least they take turns having to deal with it, and it only happens about once a month.

Is your team putting off process or tooling improvements because they are a large effort?  Or maybe there is a price tag that we are worried won’t get approved?

For example, the team is manually regression testing every Sprint.  As the product grows, it seems this activity takes up more time.  Defects are being discovered at the last minute, and they don’t usually get fixed until the next Sprint.  Yet, implementing test automation is a huge undertaking.  The team doesn’t feel they can do that now because delivering business value is most important.

Is your team putting off knowledge sharing or training because there isn’t enough time?  Or maybe they don’t want to be perceived as less productive.

I have two suggestions to help clarify the impacts of impediments:

  • Look beyond the “blocking” impediments.   Many impediments are not stopping us from working but rather slowing us down and preventing us from delivering the most value.  I call these “anchors.”  We may be able to push on, moving forward while continuing to drag them behind us.  Eventually we get tired, and they slow us down further.
  • Quantify impacts in terms of cost and business impact.  Make it visible.  Put it on a chart.  Show the trend.
    • How much time are we spending dealing with an impediment? How frequently is this impediment occurring? A technique I have used in the past is the Waste Snake.
    • What is the quality impact? For example, are the number of defects discovered in production increasing or decreasing? What is the cost of fixing a defect in production versus fixing a defect found during development?
    • How is the impediment affecting morale? Are people leaving because they are unhappy with the impediments? What is the cost of hiring someone new? (I’m taking this to the extreme, but it’s a valid situation. I know people who have left dysfunctional organizations. Tolerating impediments is a dysfunction.)

Waiting until an impediment becomes urgent (i.e. all forward progress is  blocked) will typically be a huge impact.  Try not to do this.

4 – Planning too much in the Sprint.

If we schedule every working hour of every Development Team member during a Sprint, we are almost guaranteed to fall short.  Furthermore, the team will likely feel there is no time to resolve impediments.  We must recognize that improvement is part of the work.  Removing impediments is part of the work.  Here are a few ideas to acknowledge this and encourage this.

  • Stop creating arbitrary deadlines and fixing scope.  The pressure to deliver specific functionality by a certain date can cause teams to fill a Sprint with Product Backlog Items and push off the improvements they needed to improve their effectiveness.  Scrum Masters and Product Owners can help protect the Development Team from this pressure and work with those outside the team who may be creating this pressure.
  • Make impediments visible and an input to Sprint Planning.  Sometimes the Development Team and Product Owner need to actually see impediments (and Retrospective Action Items) to keep them in mind during Sprint Planning.  If the impacts of the impediments are understood, the next step is to make them visible and consider them inputs to Sprint Planning.
  • Get your Product Owner on board.  The Product Owner’s accountability is to maximize the value of the product.  If the product is not scalable, enhance-able, or maintainable, the Product Owner is not going to get much more value out of the product (or it will come at great expense).  I have worked with Product Owners who are fierce advocates for removing impediments to the Development Team’s continuous improvement.
  • Don’t be afraid to talk about some impediments in the Sprint Review.  Some things are best to handle with the Scrum Team only in the Sprint Retrospective.  However, organizational impediments or impediments that require investing in the Scrum Team may make sense to bring up in the Sprint Review.  You have a wide range of stakeholders in attendance, and they may have influence to assist with these impediments.

5 – Management is not engaged in removing organizational impediments.

A Scrum Master’s responsibility is to help the Development Team remove impediments they cannot resolve themselves.  However, a Scrum Master should not feel they have to do this on their own.  Sometimes the Scrum Master just needs the Manager to provide cover or support for their efforts.   It is also important to recognize that a Manager can often provide knowledge, insights, and influence the Scrum Master does not have.

The role of an Agile Manager is a big topic.  All I will say here is that helping remove organizational impediments when a team needs support is one of their responsibilities.  The Scrum Master and Agile Manager should be working closely together on the impediments that will require organizational involvement and support.

In summary, a Scrum Team tackles impediments in order to improve effectiveness in delivering valuable software.  Teams must be empowered to resolve impediments.  The impacts of impediments should be made transparent.   Teams must take the time to resolve impediments.  A self-organizing Development Team will know which impediments they need to address, when to address them, and when they need support from outside the team.

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:

More recent posts

Productivity: creative versus reactive leadership

photo of computer monitor with the words

5 ways productivity culture kills business agility

The difference between Scrum and traditional project management

Quick Links
Proud to be