Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Impediment Busting: Designing an Impediment Removal Process for Your Organization

Impediment Busting: Designing an Impediment Removal Process for Your Organization


Many proponents of Lean advocate starting with a focus on waste and eliminating waste. This presents at least two challenges 1. First, in the Lean software literature, the definition of waste has remained largely unchallenged and unchanged from its roots in 20th-century manufacturing. Second, the waste metaphor does not translate comfortably from its origins in automobile manufacturing to modern knowledge work. When implementing an Agile-Lean approach to work in teams and organizations it is more helpful to focus on two fundamental questions:

  1. How does work flow through your teams and organization?
  2. What impedes the flow of work?

The focus of this article is that second question, and how we manage impediments to the flow of work.

Do any of these sound familiar in your teams or organization?

  • You find yourself discovering the same problems over and over again
  • You find that you are solving the same problems repeatedly
  • You discover that the problem you thought you had was just a symptom
  • The velocity of your team is very unpredictable
  • Things just seem to take too long to get done
  • There is a lot of churn
  • Defect rates are climbing, despite best efforts
  • Feature velocity is falling over successive releases
  • People are feeling a general dissatisfaction and lack of fulfillment

All of these can be indicators of the presence of impediments in your teams and organization.

Lean Product Development takes an end-to-end focus on the flow of work through a system. Rather than focus on traditional measures such as capacity utilization, it proves more effective to focus on how work is moving through the system. It is common to read or hear about removing impediments to an agile transformation. I find this to be not the most helpful focus. First, because there is an inherent and incorrect assumption that transition has an end state. Second, it puts the focus on agile (or lean, or both), rather than on the goal of the business, i.e., shipping products and providing services that satisfy customers. I prefer instead to focus more generally on removing impediments to the flow of value. Being intentional and deliberate about the design of the process for removing impediments is a necessary step to making this work.

1. Introduction

The Merriam Webster dictionary defines an impediment simply as anything that makes it difficult to do or complete something; something that interferes with movement or progress. In other words, an impediment is something that interferes with flow.

We start by looking at how work flows through our systems of teams and organizations. When I first started to look at lean, and apply lean principles, one thing that didn’t feel quite right was the way in which the lean concept of waste has been translated to the world of software development. Its not that removing waste is not important; the challenge is that agreeing what is waste in modern knowledge work like software development is not as clear cut as it is in manufacturing production lines or other domains.

Instead of trying to find and eliminate waste as a means of improving efficiency, I find it more natural to focus on the flow of work as a means of improving effectiveness. From that perspective, two questions become central. The first questions is “how does work flow through our system”? It can be very revealing for people to see the end-to-end picture of how work flows through the entire system, and not just their nominal area of functional responsibility. Managers and leaders from across the organization need to work together to create this picture. The second question is “what impedes the flow of work through the system”? Or, asked a different way, “what opportunities exist to improve the flow of work through the system?

I have been understanding and developing approaches to impediment removal through my work with teams and organizations around the world since at least early 2010, primarily in North America, Europe, Israel, India and China. As well as being a fulltime employee of a global company, I am also completing a PhD, where my research focuses on understanding flow and impediments in teams and organizations. I am fortunate in that I have a direct feedback loop between my research and its practical application in the teams and organizations I work with. I have been refining the material here based on feedback from papers and conferences where I have written about and presented my research.

2. Managing Impediments

2.1 Recognizing impediments

Agile teams have a particular advantage here because the rituals of communicating frequently, and reflecting often, are built in to the approach.

Daily stand-ups. Daily stand-ups are a great forum to prompt for impediments. The familiar “3 questions” of the Daily Scrum, for example, can be tailored to explicitly ask about impediments.

Scrum-of-Scrums. A focus on impediments is useful when working to coordinate the work of multiple teams across a large program.

Retrospectives. Retrospectives are good forums, and it helps to mix up the format. Teams often get stuck in using the same format for retrospectives. This repetition of form (as distinct from repetition of the event on a regular cadence) can hinder our ability to scan the environment and detect patterns: if we’re always looking at the system the same way then our awareness suffers and we’re less likely to pick up on those weak signals before they become problems. Our brains are wired for novelty and stimulation. We can take advantage of that to help detect impediments early.

Self-assessments. Self-assessments are useful to help teams identify sources of impediments. They won’t always identify the impediment directly, but they can serve as a useful reminder of practices that teams should be considering. They can use that information to correlate gaps in practice with noted problems.

Surveys. Surveys are another useful tool. We use surveys to explicitly look for impediments and causes of impediments in the organization.

Self-assessments tend to be more quantitative in nature, and focus on specific agile and lean practices and behaviors. We tend to run these quarterly. We use surveys to gain deeper insights through qualitative information. Both are useful for identifying impediments.

Observation. Observing a team in action can show up many impediments. A skilled observer can often see patterns to which teams have become blind.

2.2 Difficulties dealing with impediments

The first is simply recognizing the impediments – getting past lack of awareness, and moving beyond the feeling that something is not right, to the point where our sensory input is more finely attuned to detecting impediments. Flow and impediments provide a language and a context for bringing into focus those things that slow down our work, or get in the way of our progress. I often start with focusing on symptoms because they can be easier to detect and describe.

Understanding the impact can be difficult. The impact is likely one or more of time, money, quality or morale. I developed Impediment Impact Diagrams to help teams and organizations articulate the impact of their impediments, and to understand whom they need to influence or seek help from in order to resolve the impediment. I published a paper as part of the Agile 2014 conference, available via the IEEE digital library, that describes the concept in much more detail 2. The diagram in Figure 2 shows an example of an Impediment Impact Diagram.

Figure 1 Impediment Impact Diagram

The Impediment Impact Diagram is also particularly useful when teams have identified lots of impediments – potentially dozens or hundreds – and they quickly need to make sense of that large amount of data so they can decide where to focus their attention.

2.3 Responsibility for addressing impediments

For teams using Scrum, Scrum Masters play a vital and visible role in helping to address impediments. They have a number of responsibilities,. They educate the team in learning to see and resolve impediments. In a servant leader sense, they own the impediment at the team level, and advocate for it with management where necessary. There is a fine balance here between owning the process of impediment removal, and fostering an environment where team members take accountability of impediments. They promote impediments to the management boards, and, where necessary to the director boards.

Managers also play a role. One of the most important things a manager does is support the team by removing or helping to remove impediments.

Individual team members also play a role. It is important to strike a balance between removing impediments for a team so that they can focus on their work, and helping people to develop their problem solving capabilities.

Depending on the nature of the impediment the team might need help from senior leadership or people outside the immediate organization. So, I like to distinguish between who is responsible for resolving the impediment and who will make sure it gets resolved. Scrum Masters should generally own the process of making sure it gets resolved, and hold people accountable. The person or people who will actually resolve the impediment will vary.

2.4 Visualizing and addressing impediments

Visualizing impediments and the actions that are taken can help to address them more effectively.

It starts with the team. Teams have an impediment board alongside their Kanban or Scrum board. For teams starting out with this we generally use a separate board. Later, they might incorporate impediments into their existing boards. The main thing is that we want impediments to be visible.

Managers have impediment boards too. The impediments that appear on the management board come from the teams. Directors and executives also have impediments boards. Some examples are shown in Figure 2.

Figure 2 Team, Management and Director Impediment Boards

I like Karl Scotland’s set of heuristics that he calls “Visualization TIP” and uses to help create shared understanding 3. TIP stands for Token, Inscription, Placement. In the context of impediments, it is a useful reminder to consider the token that we will use to represent the impediment, the inscription on that token that describes the impediment, and the what the placement of the token signifies or communicates about the state of the impediment.

The dynamics are important. Impediments flow from the team boards to the management boards to the executive boards. Organizations agree what policies they will use to move impediments between the team boards, management boards and executive boards. Examples of these policies include:

  • As the owner of the process, only the Scrum Master can move an impediment between boards.
  • WIP limits in In-Progress impediments, e.g., no more than 5 impediments in progress on the management team board, otherwise we are creating a bottleneck.
  • Time limit for moving impediments between boards, e.g., if an impediment is on the team board for more than a given duration (it might be a week, or three days, whatever is appropriate) then the Scrum Master automatically moves it to the management team board.

These are flexible constraints rather than hard rules, and we have teams that experiment with creating their own policies.

2.5 Impediment Boards

Impediment boards play a central role in managing impediments. They are essentially just Kanban boards, visualizing the defined workflow for impediments. Each team has its own impediment board. It usually works out that a single management team will support multiple development teams, so a management team will also have an impediment board.

Figure 3 A management team supports multiple development teams; each has their own impediment board

2.6 Metrics

Metrics are useful too. Tracking the cycle time of impediments can provide insights into what’s going on in an organization. How quickly are we resolving impediments? What kinds of impediments are not getting resolved? Or not getting resolved quickly enough? What does this tell us about how we solve problems? What can this teach us about how we’re working and what we’re prioritizing?

2.6.1 Metrics for identifying impediments

We use a core set of metrics to help understand flow and identify impediments. I describe these in a lot more detail in an Agile Alliance experience report 4. Figure 4 shows examples of a throughput analysis, cumulative flow diagram, cycle time, and release burnup.

Figure 4 Metrics for understanding flow and seeing impediments

The throughput analysis in Figure 4 (a) shows throughput growing to a steady rate, but shows that failure demand (shown in red) starts to grow for a time. The presence of failure demand can be an indicator of impediments. The cumulative Flow Diagram (CFD) in Figure 4 (b) shows work-in-process (WIP) increases at periods (the yellow band) and also shows an observable delay in ‘done’ work getting accepted (the transition from blue to green). The later parts of the Cycle Time report in Figure 4 (c) shows average cycle time increasing significantly for a time. The release burn up in Figure 4 (d) shows a subset of the information contained in the CFD, but clearly highlights the rate of acceptance against the growing backlog. All of these are not necessarily problems, but they are indicators of potential impediments.

2.6.2 Metrics for Managing Impediments

We also use some metrics for managing the impediments.

Queue size is a good indicator that shows how many impediments are currently open for a given development team or management team. Tracking trends over time is a rich source of information that shows how many impediments we are finding and dealing with. We don’t worry about teams that raise lots of impediments; we worry about teams that raise no impediments.

Cycle time shows us how quickly we are resolving impediments. We encounter some impediments that can be resolved in hours or days. Others can take weeks or months.

It can help to classify the impediments so that we can get a more accurate picture of the types of impediments we are encountering. This can also serve as an indicator of how long it will take to resolve the impediments.

We want impediments to filter up the organization chain so that we can be alert to spotting systemic issues that are impacting multiple teams across the organization.

3 Scaling the process for handling impediments across an organization

First understand how and why the process works in the small, before trying to expand or scale it across the organization. The first step is to understand how responsibility flows through the organization. Make it visible. I often do this by drawing a simple map from teams to executive management. The emphasis differs from a value stream map where we’re looking for the flow of value to the customer. Here, we’re looking to visualize who is responsible for helping teams remove impediments. Get the flow working smoothly for one team and one management team. This will uncover all sorts of learning – not just about how work gets done, but about how we deal with trust, transparency, accountability, risk, problem solving and other things we might take for granted or not otherwise talk about. It also reveals a lot about how teams and management work together, and about how managers work with each other. Managers must really act as a coherent team in support of the engineering teams and the wider organization.

Then add more teams, more management teams once you understand how and why it works.

Sharing the details of impediments and how they are resolved can contribute to organization learning. We ask ourselves several questions about this. What patterns are we seeing across the organization? What sorts of things are coming up as systemic issues versus isolated incidents? There might sometimes be issues where teams would not like other teams to hear about their impediments, but this is rare. When it comes to managing impediments, it is best to have a culture of total transparency. I talk about this more in the section below on visibility and transparency.

4 Encouraging the right culture

This sort of approach demands the right sort of culture in which to thrive. Of course, teams and organizations can’t simply create a new culture. However, we can create the right conditions for an effective culture to emerge and thrive. We can encourage a culture that makes it easier to deal with impediments and supports developing people’s problem solving abilities. This section talks about some of the ways of doing that.

Build Trust. Trust is essential to making the process work. It can be scary at first to make all of your impediments visible. Scarier still to admit that we need help resolving them. This will be difficult if a culture of blame exists. For a number of reasons, some people and teams are reluctant to raise impediments. There may be trust issues, or other cultural factors. In the beginning, managers may need to encourage the teams to raise impediments. Managers emphasize their role as being one that supports the work of the teams. Resolving impediments on behalf of the team is one of their core responsibilities. Coaches can play an important role here in helping to establish safety.

Accountability. We need a culture where people hold each other accountable. It needs to be clear who is taking responsibility for the impediment, what they are going do, and by when. Accountability combined with visibility and transparency makes it easier to deal with impediments, and provides positive reinforcement.

Be Consistent. Be deliberate and consistent in your approach to managing the end-to-end flow of work, and in wanting to find and remove impediments. This applies particularly to management teams.

Visibility and Transparency. Keep a focus on visibility and transparency. Keep the impediments visible. Be transparent about their cause, status and impact. These things might be uncomfortable at first, but they force you to confront the causes of the discomfort early. It helps if a foundation of trust exists, or can be achieved, within the organization. If not, then there are challenges the organization needs to deal with first before thinking about using an impediment removal process, or perhaps even before using agile approaches.

Disintermediation. Reduce the communication and organizational distance between the executives and teams. That does not mean we need to do away with manager roles, but it is worth examining whether there are too many layers of middle management sitting between teams and executives. It is possible to reduce the degrees of separation on projects and programs even without touching the org chart.

Solve Difficult Problems As A Team. A percentage of impediments need some detailed analysis and discussion. For those we use A3 problem solving reports and other approaches. These approaches tend to bring together people from across the organization to solve impediments. These are also great opportunities for more senior people in the organization to coach and develop others. This area is where I see huge value, and potential for growth of people, teams and organizations. Using A3 or other approach managers can actively coach people and help develop their problem-solving capability. This has the additional benefit of bring managers and team members closer together and strengthening that relationship. Also, the impediments that make it to this level tend to require some level of ability to navigate the organization. This can increase the perspective and awareness of people being coached.

Develop New Habits. An impediment that keeps resurfacing in different guises is often a sign of an unhelpful habit that has developed in the organization. Rather than unlearn old habits it is often easier to learn new, more beneficial ones. Removing impediments provides us with opportunities to develop new habits. In “The Power Of Habit: Why we do what we do and how to change”, Charles Duhigg talks about the idea of keystone habits 5. He notes that “keystone habits transform us by creating cultures that make clear the values that, in the heat of a difficult decision or a moment of uncertainty, we might otherwise forget.

Culture First, Tools Later. Start with a simple Kanban board on a wall. Get the process right first before attempting to use an electronic tool, no matter how tempting. Later, software tools can add some value by making impediments visible across the organization. This can be particularly useful in multi-site organizations. But using tools too soon can inhibit the cultural changes we’re trying to make by inhibiting or replacing the communication that needs to take place between people. I sometimes see teams fall into the trap of moving to a tool before the new culture and habits have had a chance to embed themselves in the organization.

5 Relationship to Methods

An impediment removal process compliments whatever approach to agility you are already taking. With Kanban, for example, it compliments and supports the key values of transparency, collaboration, flow, evolutionary change, and improving collaboratively, evolving experimentally 6.

  • Transparency: We make impediments visible, make the impacts visible, and show how impediments are being managed.
  • Collaboration: Teams and management collaborate to resolve impediments.
  • Flow: Removing impediments to the flow of value is the primary focus of an impediment removal process.
  • Evolutionary change: Removing impediments leads to continuous change, and the development of new habits in the organization.
  • Improving collaboratively, evolving experimentally: An impediment removal process provides a structure for identifying and removing impediments. Having lots of teams work on impediments leads to many small experiments that help to evolve and improve the organization.

An impediment removal process also supports the three pillars of Scrum 7:

  • Transparency. Similar to Kanban, Scrum requires all work to be visible and transparent.
  • Inspection. “Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances”. Such undesirable variances are often caused by impediments. A deliberate focus on seeking out and managing impediments supports the Scrum pillar of frequent inspection.
  • Adoption. Removing impediments involves making changes. An impediment removal process supports making process and environment changes to help teams stay on course.

6 Conclusions

Here is a summary of the steps to establish your own impediment removal process:

  • Start by making impediments visible.
  • Create dedicated Impediment Boards. These are essentially just Kanban boards for impediments. Later, teams might choose to incorporate impediments into their main Kanban board.
  • Establish explicit policies that govern how and when impediments move states, and how and when they move between boards.
  • Take action to remove impediments.
  • Review impediment status on a daily basis in teams. Make it part of your daily standup.
  • Review organization impediments regularly as a management team, at least weekly. Take action to remove impediments. Look out for and discuss systemic issues. Take counter measures to tackle systemic issues.
  • Review program impediments at least weekly, preferably twice per week. If using a Scrum of Scrums for cross-program coordination, add a focus on program impediments.

7 References

1 K. Power and K. Conboy, "Impediments to Flow: Rethinking the Lean Concept of ‘Waste’ in Modern Software Development," presented at the Agile Processes in Software Engineering and Extreme Programming, 15th International Conference (XP2014) May 26-30, MMXIV, Rome, Italy, 2014.

2 K. Power, "Impediment Impact Diagrams: Understanding the impact of impediments in agile teams and organizations," presented at the Agile Software Development Conference (Agile 2014), Orlando, FL, USA, 2014.

3 K. Scotland. (2013). Kanban - Isn’t It Just Common Sense? Available:

4 K. Power, "Metrics for Understanding Flow," presented at the Agile Software Development Conference (Agile 2014), Orlando, FL, USA, 2014.

5 C. Duhigg, The Power of Habit: William Heinnemann, 2012.

6 M. Burrows, Kanban from the Inside. Sequim, WA: Blue Hole Press, 2014.

7 J. Sutherland and K. Schwaber, "The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game," Scrum.orgOctober 2013.

About the Author

Ken Power is a Principal Engineer and internal coach and consultant with Cisco Systems, Inc. He lives in Galway, Ireland and works with teams and organizations around the world. His responsibilities include leading the agile transformation for Cisco’s largest software group. He also works with universities and research groups in agile, lean and software engineering research. He is currently completing a PhD in Lean Flow and understanding impediments in teams and organizations. He is a frequent speaker at the major international agile, lean and software engineering conferences, and has published numerous papers on agile and lean development, and software engineering management.

Rate this Article