29 May 2012

Systems Thinking in the Back Yard

A few years ago I wrote a post called Rounding the Corners, which discussed my early foray into process improvement, disguised as my teenage desire to spend as little time as possible doing yard work!

Last fall my (now favourite) uncle was given a new riding lawn mower for his birthday, and he asked if I'd like his old one.  We have a pretty big yard so I jumped at the chance!  I only had one opportunity to use it last year before winter, but have been consistently mowing the lawn (and almost enjoying it!) this year.

This past weekend I noticed something interesting.  Since the riding mower doesn't have the ability to make the precision turns that a push mower can, I did spend time going over areas that I had already cut in order to turn.  At first glance this could be considered wasteful - after all it's rework is it not?  It is indeed rework, but in the grand scheme of things I'm still done cutting the grass much faster using the riding mower and able to do as much of nothing as I want afterwards.

Could I improve further by reducing the rework and tightening up my grass-cutting pattern?  Probably.  Right now, though, the pain caused by the inefficiency of the rework is insignificant compared to the system-level improvement provided by the riding mower.  At some point my time may become even more expensive such that I will want to save the few minutes currently wasted by driving over areas already cut.  For now, I'm satisfied with the large improvement!

This is an approach that we should take when working with teams, whether they're new to agile or seasoned practitioners.  What are the improvements at the system level that are going to make some of the current inefficiencies seem trivial?  Ask yourself questions like these:
  • Do we really need to force-fit 2 or 3-week iterations onto a group who is constantly interrupted by work coming in from the outside?
  • Do we really need to improve testing performance to enable TDD when the real improvement needed is with feature identification and prioritization in Product Management?
  • Do we really need to create cross-functional teams across a 500-person business unit when the real need is for a core group of about 50 to focus on the most important work?
There are always small wastes that can be removed in order to provide some improvement.  Sometimes these are referred to as "low-hanging fruit".  However, they often aren't the issues that need to be solved right now, and attempting to solve them diverts people's attention and the resources they use away from the problems that do need to be addressed right now!

So, when faced with what looks like some waste in a team's or an organization's process, stop and ask if that waste is really causing pain.  Is there something else that needs to be addressed first?  If so, work on that.  If not, then figure out how to make that riding mower even more efficient!

1 comment:

Doug McMillan said...

Better tools gives a better return on efficiency than the low-hanging small problems. I just had my ancient XP desktop replaced with an i7 with an SSD. The productivity gains are far larger than eliminating small, easier to solve problems.