Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Using a "Snake On The Wall" To Quantify Impediments

Using a "Snake On The Wall" To Quantify Impediments


Kevin Schlabach posted recently on his Agile Commentary blog about using a "Snake On The Wall", a lightweight approach he's used to help his team get a handle on the things that are slowing their development process.

Hanging index cards or sticky notes on the wall to track a team's current work queue is arguably one of the simplest yet most consistently effective techniques of agile development. Kevin Schlabach suggests using a similar technique to keep track of the impediments your team encounters during daily development; ultimately a technique to help reduce the mysterious "drag" that the team senses but can't quite pinpoint.

The "Snake on the wall" technique, as he calls it, specifies that team members add a sticky note to the wall every time they feel they are notably delayed:

Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn't have the delay), the thing affected, the cause, and their initials. They take the note and add it to the "end of the snake" which is a growing row of notes on the wall.

The snake then represents an explicit information radiator for the team and managers to use to better understand, quantify, and remove the things that are getting in their way. Impediments are recorded when they happen giving the team greater opportunity to note things when they're fresh in their mind and with more information than might otherwise be available.

As Schlabach states, the snake can be prioritized similar to a typical iteration backlog, and can be used as input for the iteration retrospective. The size of the snake can be used as a quick and constant indicator to the team and management as to how effective (or, rather, ineffective) their processes are.

Schablach's take on the benefits of doing this:

What does this accomplish?
  • it validates real issues
  • it kills false beliefs and misdirected complaints
  • it quantifies the impact of impediments
  • it creates transparency for managers who don't believe what you say
  • it empowers the team
  • it is immediate
  • it self-prioritizes
  • it uncovers surprises

How many times have you gotten into a retrospective not quite remembering all the little things that got in your way throughout the iteration, but knowing they were there? Do you have trouble quantifying how much time your team is really spending on these things, which ones are the real problems?

Do you think a "Snake on the Wall" could help?

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Pain Chain

    by Mike Bria,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've also used this technique in the past, with success. I call it a "Pain Chain" though, but hey, whatever ;-)

    Please note, this is NOT a *replacement* in any way for a retrospective - it will just make the retrospective smoother and more effective.

    It's also a good "vent" throughout the week for those times one is frustrated with being delayed by something stupid - taking the 2 minutes to scratch it out on a sticky then add it to the chain just feels good.

    You'd surprised at how much this helps to improve transparency into what's really getting in your way all day, particularly those things that are the repeat offenders (eg, "Argh, ClearCase screwed me again!!!"). And, having the numbers always helps to actually get better attention by others (especially important when bureaucracy is a factor).


  • Re: Pain Chain

    by Kevin E. Schlabach,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I feel as though our recent retrospective was more effective because the snake led our conversations to be focused on impediments causing real time losses or frequent issues instead of what our memories might have told us.

  • Re: Pain Chain

    by Ted Naleid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Clear Case? Mike, you have my sympathies. By itself, Clear Case formed a python sized "snake on the wall" at a place I worked previously. Entire days were lost to Clear Case.

  • Re: Pain Chain

    by Mike Bria,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Oh, trust me, that was a previous left I left behind. But thanks anyway!

  • Re: Pain Chain

    by Mike Bria,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "previous life I left behind", that is!

    Jeez, even writing about ClearCase makes one unable to think coherently! ;-)

  • Re: Pain Chain

    by Mike Brocious,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    And the ClearCase python continues to grow and slither misses you ;-)

    I've been on a couple of teams that have tried a "drag box" as a way to capture drag. Just like the snake, except we would simply drop the notes into a small box on the team table. Near the end of the sprint we would categorize the common items and tally up the drag time...makes great input for the retrospective and managers/scrum masters.

    But the drag box faded away after a sprint or two on both teams. Everyone just stopped tracking drag time, I think mainly because we would forget about it, or the time lost didn't strike you as drag until later. Also, the definition of 'drag' is so subjective, that I think it would take several sprints to get a good list of items that people can agree should be categorized as drag.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.