Using a "Snake On The Wall" To Quantify Impediments

| by Mike Bria Follow 0 Followers on Dec 10, 2008. Estimated reading time: 2 minutes |

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?

Rate this Article

Adoption Stage

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.

Tell us what you think

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

Email me replies to any of my messages in this thread

Pain Chain by Mike Bria

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

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

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

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

Re: Pain Chain by Mike Bria

"previous life I left behind", that is!

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

Re: Pain Chain by Mike Brocious

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

6 Discuss