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
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?
Pain Chain
by
Mike Bria
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).
Cheers
MB
Re: Pain Chain
by
Kevin E. Schlabach
Re: Pain Chain
by
Ted Naleid
Re: Pain Chain
by
Mike Bria
Re: Pain Chain
by
Mike Bria
Jeez, even writing about ClearCase makes one unable to think coherently! ;-)
Re: Pain Chain
by
Mike Brocious
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.
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013





Hello stranger!
You need to Register an InfoQ account 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