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?
