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
