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

7 Comments

  • A whiteboard with paper post-its... Isn't it great how far software engineer has progressed in the last couple of years, that we can now store this essential data digitally? ;)

    It's also so easy to backup... just take a picture with your 1megapixel cellphone! ;)

  • Sounds like you're one step away from using the agile method scrum.

  • I wonder if it would be beneficial to measure total of business points (like story points, except a measure of business value) completed in a given time period?

  • Hi Max. In fact we were using scrum and have modified it to the point where we are now.

  • Hi Hank,

    We thought about using story points to limit the WIP, but we are no longer doing any significant estimating. Look for more detail in a future post.

  • One question: If you do not make any estimates, how can the Product Owner prioritize the backlog. When I am prioritizing development work, I always try to get the most bang for the bucks. I can often guesstimate the bang, the value of a particulare feature or bug fix, but how would I know the development team's best guess for the bucks, how much getting the feature or fix would cost, if you do not estimate any work?

  • Hi Gustaf,

    We didn't stop estimating completely, we just simplified greatly. See my post on 30 Second Estimating. 

Comments have been disabled for this content.