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.
- 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.
- 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?
Trackback address for this post
8 comments, 1 trackback
I'll be writing more about these topics shortly, but I'll give you a little taste.
We are replacing velocity with throughput. I find it a much more understandable metric for all the non-agilists (99.999% of the population).
I don't believe I have lost any ability to predict delivery at the level of precision that I need. After all isn't velocity just a form of story point throughput?
Obviously the throughput of the very smallest and very largest stories could be radically different and I do want story size to be as small as possible. It is my belief that over time I will get an average and a standard deviation that will give me the information I need to know.
We haven't totally rejected estimating because cost is a factor the business needs to consider. However, we've greatly simplified our estimating process. (more soon)
BTW - I mistyped my blog's url in my previous post. Is is corrected on this one.
I love it when the experts don't agree. It makes me feel smarter. Because, by not agreeing with any of the experts, I actually feel like I am one of them. This is the notion I got today when starting
>Who writes the stories?
We haven't changed anything to do with the product owner/customer. They still write the stories and they still accept the stories. Nothing goes off the kanban until the PO takes it off. Then he puts the highest priority story into the WIP and a planning meeting is held.
We thought about using story points instead of stories to limit WIP, but that is what iterations already do if you are using velocity. Additionally I wanted to get away from anything more than the briefest amount of time estimating stories - I just don't think there is much value added.
I understand the reasoning behind abandoning iterations. How about retrospectives? Will you still take time to reflect as a team and consider process improvements? If so, how often?
We still do retrospectives from time to time (no regular schedule). We don't really wait for a retrospective to think about and implement process improvements.
This post has 226 feedbacks awaiting moderation...