Impediments – What’s Getting in the Team’s Way?

Every system – particular a complex one like a cross-functional development team – has constraints. Somewhere along the way from “Ready” to “Done” something impedes productivity and flow, be it drag or turbulence, viscosity, or excessive effort.

Some folks call these issue bottlenecks, blockers, setbacks, obstacles, impediments, obstructions or waste. Regardless of whatcha call ‘em, they get in the way of a team:

  • Delivering value sooner
  • Getting customer feedback sooner
  • Learning sooner
  • Experiencing high levels of happiness

Sources of Impediments

Impediments can come from a number of different sources:

Internal to the team

  • Communication, practices, relationships, mindsets, skill sets, busted equipment, interruptions

External to the team

  • Reliance on external subject matter experts, deployment infrastructure, distractions
  • Organizational – e.g., leadership “sign off,” culture clash, rules, red tape,
  • Environmental – e.g., weather, riots and business, legal or regulatory constraints, or the Pope coming to town

And while sometimes impediments may seem small, they are rarely inconsequential. “Interactions in complex systems are non-linear: small changes in inputs… can cause large effects…in outputs” (Paul Cilliers: Understanding Complex Systems) – or “It’s the little things that make life such a big deal…” (Timbuk 3)

Detect

Every system – particular a complex one like a cross-functional development team – has constraints. Share on X

To complicate matters, the detection of impediments is not always as straight forward as one might think. Yes, the daily stand up of Scrum has a simple formula:

  • Yesterday
  • Today
  • In My Way

And while the “In my way” element has the potential of bringing things to light, impediments are easily disguised or not clearly called out…

Here’s an idea: at your next stand up, listen for the following key words:


Guess
Waiting
Wish
Hopefully
Try
Not available


Busy
Still
Expected
Thought
Should
Tried to…

Examples in context:

  • “I hope to finish it this by…”
  • “I thought I’d be done by…”
  • “I’ll try to …
  • “We should take care of…”

Each instance points to a potential impediment and highlights anti-patterns for commitment and completion. (See: Say mean do)

Inspect

As a dev-team member, if you hear any of the above, don’t just move on. Ask questions to clarify if there’s an impediment lurking. At first it might fall on to the shoulders of the scrum master to hit the pause button during stand up if a team member doesn’t. But eventually after modeling the behavior, the scrum master / team lead should allow for some space for a team member to say “wait a sec…”… The team will be much stronger in the long run.

Circumvent

When an impediment has been detected by the team at stand up, the discussion around what is necessary to get unblocked needs to be productive and quick. If “the path forward” can’t be clearly identified within a minute or so, or requires input from someone external to the Dev-Team, a post-stand up sidebar or later discussion is appropriate.

In any event, whomever is “blocked” has the opportunity to tap into the support of their team. And it absolutely should be a team effort to collectively and creativity solve the problem – as the success of the sprint is a shared fate.

Team actions might include deciding to pair to work thru head banging legacy code, or to take look at tests that someone’s been struggling with that just won’t pass. It’s amazing what a fresh set of eyes might just find.

Yes, most “Scrum Guides” say that it is the scrum master’s job to remove impediments. But I think it’s a judgement call. If it’s always up to the SM to “solve the problem” won’t that just become another bottleneck to the team growing and getting better as a whole? (One exception might be external/organizational impediments. Might make sense for SM/TL to deal w those…)

Retrospect

The team should keep track of the impediments they experience during a sprint. Keep a team gist, start a “snake on the board,” or create a separate “impediment” backlog in their issue tracker.

The point is visibility: bringing the team’s history of impediments to light. So they can see if any patterns emerge. And then at the retro, dig into root causes. And then develop actions that the team could take to remove or reduce the likelihood of a reoccurrence.

Rinse and Repeat

There is no such thing as a team without impediments. Accept as a matter of fact that the team’s “backlog of impediments” will never be empty. (If it is, the team is not continuously improving, and is likely underperforming. On the other hand if the backlog of impediments is either never changing or forever growing, you’ve got a larger problem.)

What’s important is how teams raise up and ultimately deal with those obstacles. Clearing the meaningful ones on a regular and continual basis will have a dramatic impact on the quality of their inner work life. And it will help the team move on to a new level of performance.

For more, see:

No products found.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top