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

Estimation

Posted Under Management, Agile on 02.1.2008

Trackback address for this post

Trackback URL (right click and copy shortcut/link location)

8 comments, 1 trackback

Comment from: Mike Cottmeyer [Visitor]
****-
Mike CottmeyerHi 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] Email
WayneHi 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)

02/06/08 @ 13:22
Comment from: Mike Cottmeyer [Visitor]
****-
Mike CottmeyerThanks 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

02/07/08 @ 04:58
Comment from: Aaron Sanders [Visitor] Email
*****
Aaron SandersOur 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]
NO OPeration: Complexity of Software ProjectsTo 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
02/25/08 @ 14:02
Comment from: Wayne [Member] Email
WayneManfred,

>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] Email
WayneAaron,

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 from: Jeff Y [Visitor] Email
Jeff YHi Wayne,
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?

Jeff
02/28/09 @ 09:57
Comment from: iclemartin [Member] Email
iclemartinJeff,

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.
02/28/09 @ 15:47

This post has 6 feedbacks awaiting moderation...