We've committed to iteration-less pull based software development starting on Monday for one of my teams. A number of factors led up to this decision, not to mention the vast amount of discussion I had with my project managers.

The factors:

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• I am looking for a good departmental metric for the rest of the company to see how development is doing and Velocity is always too abstract.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
• There was invisible work being performed.
• We had a tool (Rally) that wasn't really being used as intended.
• The scheduling process seemed overly complicated.
• We didn't have a great way to express the result of adding "one more thing" to the release.
• We are just about to get a true single backlog per product line.

What we are ending up with:

• A kanban board currently in the PM office, to be moved to the team space as soon as physical re-org is complete (~2 weeks). The kanban will have 4 columns: pending, blocked, in process and complete.
• A single department metric: throughput expressed as average days to complete a story.
• Limited work in process (WIP). We are starting with a maximum of 5 stories WIP and will experiment from there.
• Differentiating stories from support requests.

Our current kanban board.

What we're not sure of yet (that we know of):

• How many support requests in process (RIP) makes sense? 1? 5? 10?
• How the blocked state will get (mis)used.
• If we need to track the amount of time a story spends in the blocked state.

The kind of output I'd like to track.

Casie is one of my project managers who has a blog but doesn't post much. I'm hoping this change will cause her to comment more often about what she is thinking and experiencing as we move through the process.

References:

Lean Software

• Amit Rathore: Estimation considered harmful
• Amit Rathore: If estimation is harmful… then, what’s not?
• Peter Seibel: Software estimation considered harmful?
• The Poppendiecks: Managing the Pipeline
• David Anderson: Stop Estimating
• David Anderson: Agile Estimating
• Corey Ladas: Time-boxed iteration: an idea whose time has come and gone
• Alistair Cockburn: Are iterations hazardous to your project?

Estimation

• Mike Griffiths: Agile Estimation – Upfront Estimates