Smaller Batch Sizes = Higher Quality

From the pmStudent Blog
Ranting and raving about project management and systems engineering.

About this Blog


Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Categories: Agile

small toad

I've recently experienced an epiphany.

I should have seen it earlier.  I mean, duh!

I have been using kanban with my teams for some time now, and up until now we have been mostly focused on limiting work in progress (WIP) and evolving our value stream.  Only recently did we start trying to reduce the batch sizes of code being worked through the system.

The Changes Have Been Dramatic

Rather than trying to peer review a whole slew of code, the team is engaged in more frequent, shorter peer reviews that are highly focused on just a small bit of code, individual features in most cases.

As a direct result, I believe we are producing higher quality software.

Mind you, I can't prove it quite yet.  In our waterfall paradigm, it's going to be a little while before we get to a full release where we go through formal acceptance testing.  Because this is the way it's always been, defects in code are going to have to be measured against the previous benchmark established in previous releases.

It Makes Sense

I mean really, this is a no-brainer.

If someone has to spend 4 hours scouring through hundreds of lines of code, it's going to get glossed over and things will be missed.

If someone knows they will get through a peer review in 10 minutes, it's a lot different.  Easier to focus.  Higher scrunity on the code.  Better solutions are developed and collaborated on.  Awesomeness ensues.

Not to mention, there is a shorter turnaround time from when the developer codes to when they receive feedback, and when they can disposition comments and make it better.  Less knowledge lost, more value gained.

Now the nagging question is....why didn't we start doing this earlier?

Like this? Share it!
Posted on: April 11, 2011 11:06 PM | Permalink

Comments (4)

Please login or join to subscribe to this item
Josh, focusing on smaller piece makes sense. However, how can we ensure we are not losing sight or missing anything in the bigger picture?

Wai Mun Koo, that should be no problem. Your backlog still contains all of the scope necessary for the larger release (whether that's user stories, deliverables, tasks, etc.) - or even if you are not working from a backlog as with scrum or kanban, it could be from your WBS and basis of estimates / activity breakdown. (Or PBS/WBS if you are using that approach)

Many times with our process, items will start out as larger chunks and then before they get pulled into the "on deck" state in our kanban process, they may be split into smaller that split user stories, smaller tasks, or features.

Josh Nankivel

Josh, we split big projects into phases, so it makes complete sense that it's more effective to split chunks of work down into smaller component parts to make them more manageable. I'm glad you've found that it has been successful so far - let us know if the awesomeness continues!

Thanks Elizabeth, will do. Getting the batch sizes down to a week or less has been working pretty darn good so far, I'll be providing updates as we go along!

Please Login/Register to leave a comment.


"There are three kinds of lies: lies, damned lies and statistics."

- Mark Twain