| « Continuous Production - Production-ready software…any time | Geek Marketing 101 » |
No More Iterations
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
Trackback address for this post
Trackback URL (right click and copy shortcut/link location)
7 comments, 1 trackback
Comment from: Mike Cottmeyer [Visitor] · http://www.leadingagile.com
Hi Wayne, glad I found your blog.
It sounds to me like you are replacing velocity with throughput (represented as days per story). You must be driving your project manager nutty :-)
First, I understand the desire to go to throughput but it seems you would lose any ability to predict what you will deliver when? At least velocity allows me to measure what I am delivering and adjust of velocity is not what I thought.
Second, for throughput to be useful, you would almost have to assume that stories are similarly sized or that the average would be useful over time?
Have you guys given up on estimating and planning all together, even using Agile techniques?
I may be missing something here, help me understand. Thanks!
Mike
02/06/08 @ 08:28
Comment from: wayne [Member] 
Hi Mike,
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)
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)
02/06/08 @ 13:22
Comment from: Mike Cottmeyer [Visitor] · http://www.leadingagile.com
Thanks for the quick reply. I think i see where you are headed. I will keep my eyes out for future posts.
BTW - I mistyped my blog's url in my previous post. Is is corrected on this one.
Mike
BTW - I mistyped my blog's url in my previous post. Is is corrected on this one.
Mike
02/07/08 @ 04:58
I like that you are trying new things. That's at the core of any agile approach. This post creates food for thoughts. :-)
You use average days to complete a story as the metric for throughput. Questions on that: Who writes the stories? Who is the gate keeper in terms of what goes onto the kanban board? In that process how do you get involved different subject matter experts, e.g. user interface or performance experts?
Manfred.
You use average days to complete a story as the metric for throughput. Questions on that: Who writes the stories? Who is the gate keeper in terms of what goes onto the kanban board? In that process how do you get involved different subject matter experts, e.g. user interface or performance experts?
Manfred.
02/23/08 @ 01:46
Our team is still estimating size in story points, and then measuring story point throughput. I am thinking of making the fixed queue in front of WIP to be fixed on points, instead of number of work items.
02/23/08 @ 09:46
Trackback from: NO OPeration: Complexity of Software Projects [Visitor]
To Iterate or Not to Iterate
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
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
02/25/08 @ 14:02
Comment from: wayne [Member]
Manfred,
>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.
>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.
02/25/08 @ 15:30
Comment from: wayne [Member]
Aaron,
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.
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.
02/25/08 @ 15:33
Comment feed for this post