Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Using a "Snake On The Wall" To Quantify Impediments
Posted by Mike Bria on Dec 10, 2008
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?
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Pain Chain
by
Mike Bria
Posted
Re: Pain Chain
by
Kevin E. Schlabach
Posted
Re: Pain Chain
by
Ted Naleid
Posted
Re: Pain Chain
by
Mike Bria
Posted
Re: Pain Chain
by
Mike Bria
Posted
Re: Pain Chain
by
Mike Brocious
Posted
-
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).
Cheers
MB -
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.
-
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.
-
Oh, trust me, that was a previous left I left behind. But thanks anyway!
-
"previous life I left behind", that is!
Jeez, even writing about ClearCase makes one unable to think coherently! ;-) -
And the ClearCase python continues to grow and slither there...it 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.
6 comments
Watch Thread Reply