Three Tips for Removing Impediments the Agile Way

Impediments will occur on any project; agile projects are no exception to risks. Agile succeeds because you are more likely to see the problem before it becomes a disaster.

Two developers got the flu. Your tester has jury duty. The team can't figure out what the design should be for a specific feature and it's a week late. You have automated test technical debt. Your product owner can't make time to work with the team.

So then, has Murphy (1) arrived on your agile project? What can you do about the impediments? Yes, the simple answer is “remove them.” That can be more difficult than it sounds. Here are three tips for removing those impediments…

1. Learn who can solve the impediments. What are the impediments? In one six-person team, the members realized during one week of their two-week iteration that three people would be out. Yes, they had two developers out with the flu and the tester on jury duty. Not what they planned.

First, they explained the problem to the product owner. The UX designer said, “We can’t finish anything this iteration. It will all be in progress if we decide to continue with what we thought we could do. As a team, we developed these options:

  • We can work on writing small stories.
  • We can use a kanban board to show what we are doing and the state that everything is in.
  • We can swarm on what we have on the board and see how far we get.
  • We can fix outstanding problems and not develop anything new. We have enough people for that.”

The product owner liked the idea of fixing things. He worked with the team to develop a new set of work. The team swarmed over the work and was able to fix more than it anticipated. The team managed to solve this problem with no need for additional support. The problem was internal to the team.

Another team discovered it was stuck on a design. It needed more help from other people across the organization. It had sent emails to people who might help, and all those people said, “We can’t take the day or two needed to work with you, sorry.”

The agile project manager needed to help resolve this impediment because it was a cross-organization problem. Was it possible to ask other people to work with this team? Where was this team’s project in the overall project portfolio?

The project manager discovered that yes, this team’s project was more important than some of the others. Those projects changed their deliverables so some people could work with this specific team and help it understand its possibilities for design.

2. Track your progress (or the team's progress) toward impediment removal. Once you know who can solve the problem, track the progress toward impediment removal. I like a kanban board for this. I use these columns

  • Impediment Backlog
  • Investigate Problem
  • Develop Solution Criteria
  • Candidate Solution
  • Implement Fix
  • Done

You might prefer an action planning board instead. Here’s a picture of that kanban board:

Resist the urge to put the impediments in a tool, at least at the beginning. In my experience, the tool becomes a write-only tool. With some form of a board, people are more likely to look at the board and work on the impediment.

This is even more important when you are the one removing impediments. The more you show transparency in your work, the more transparent your team will be. Physical boards help with transparency.

One of the problems with removing impediments is that you might not be able to resolve the impediment the way you want to. That’s why I use the “Develop Solution Criteria” and “Candidate Solution” columns. As an agile project manager, you can help the team develop several candidate solutions. If you know what result you want, you might be able to develop several solutions.

3. Define what “done” means for removal. What might “done” look like for a given problem? If your team wants a team room so it can work together, solution criteria might be:

  1. Find a spot where we can work together.
  2. That area needs sufficient wall space for our boards (backlog board, design candidate boards, whatever other boards you need).
  3. That area needs enough room for us to work together in pairs (or swarms or as a mob, depending on how your team wants to work together).

Your organization might not have a room large enough for your team. Maybe your team is too large for the available rooms. Maybe you just don’t have any meeting room space at all. If you had to think of other solutions, maybe they could be:

  1. Find a place for people to pair together; that might be at someone’s desk. What do we need to make that happen? (Your people might need an extra keyboard per person, maybe an extra monitor in each cubicle.)
  2. Would it work to have a common area to post boards? Would it work to have a conference dedicated to your team once a day at a certain time so people can collaborate on design?
  3. Maybe your team would accept the ability to swarm or mob at one person’s desk for a while. In that case, what would you need to outfit each person’s work area so the team could swarm or mob?
  4. I often see teams that are larger than seven people. The more people you have, the more communication paths you have and the more difficult it can be for a team to decide anything. Maybe the first thing you do is split the team into two smaller teams. (With the team’s approval.)

I bet you see more options here. When you think about the possible criteria for removing this impediment, you move from one alternative (a team room) to more possibilities. Those possibilities might not be as good as a team room. And the more you explore possibilities starting from the results you want, the more likely you are to develop great possibilities.

Use agile principles to solve agile problems
The more you ask people to solve problems they can solve—and escalate the problems they can’t solve—to you, the more you exhibit servant leadership. You don’t have to have all the answers. You can help by monitoring the project for risks and impediments, helping people solve what they can, visualizing the problems and thinking about what “done” could mean for the problems.

I have yet to meet a project that didn’t have problems. Some projects had Murphy as a team member. Use these ideas and adapt them so you can solve your project problems in an agile way.

(1) Murphy's law is an adage that is typically stated as: Anything that can go wrong, will go wrong, and usually at the worst possible time.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: