Thursday, March 17, 2011

"If it ain't broke, don't fix it" vs. "Continuous improvement"

I don’t really remember when I first heard the phrase, “If it ain’t broke, don’t fix it,” but I’ve used it plenty. Upon reflection I’ve mostly used it to avoid doing boring or unappealing work – endeavoring to cast undesirable requests as wasteful and unnecessary changes.

Thinking about it though, there is a fair bit of wisdom in the saying. Researching its origins turns up a surprisingly recent (to me anyway) provenance. Apparently one T. Bert (Thomas Bertram) Lance, Director of the Office of Management and Budget in US president Jimmy Carter’s 1977 administration is often accorded recognition for first use (although there appears to be a reasonable case for it already being in circulation in the Southern United States). He is quoted in a newsletter as follows:
Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: “If it ain’t broke, don’t fix it.” He explains: “That’s the trouble with government: Fixing things that aren’t broken and not fixing things that are broken.”
Hard to argue with that, eh?

Having used (and possibly abused) this phrase for years, I was given pause for thought yesterday when it was tossed my way. It’s not like it’s the first time that’s occurred, but it was one of the less regular occasions where I thought , “OK, maybe what I’m trying to change isn’t broken per se, but it could be better.”

For the last few years my work has involved a lot of change. My organization has transitioned (indeed continues to transition) from a very rigid, waterfall style process of software development to an agile one. When we started out we had a pretty naïve idea of what this entailed. We were already doing work in iterations – kinda – by providing a new build to our QA/testing people every two weeks. We made a series of small changes over a relatively short period of time (I wrote about those here, here and here) and ultimately we settled upon Scrum as our specific flavor of agile.

You don’t have to spend long with Scrum to realize that one large facet of it is pushing for something a bit different to the idea of “If it ain’t broke, don’t fix it” (which henceforth I’m shortening to IIABDFI.) It’s pushing continuous improvement, or Kaizen to borrow the rather snazzy Japanese word for it. This notion is baked right in to Scrum, with every sprint having a retrospective at the end where the team looks for ways in which they might improve things.

As much as I latched onto and used the IIABDFI idea, I find Kaizen considerably more appealing. IIABDFI is mostly a crutch for me to skirt doing boring work. But Kaizen appeals to my inner perfectionist. Anyone who’s worked with me can probably tell you that I have tendency (likely somewhat annoying) to always critique the status quo. I can’t seem to help seeing things that we could change that I think would make everything just a little bit better. This characteristic hasn’t served me too badly in the past, and when I’ve worked with people of a similar bent it’s created quite a good dynamic with people all interested in continuous improvement bringing in great new ideas and accepting them from others. There can be moments of trouble if two well meaning people hold strongly differing views on what constitutes "better", but mostly things are obvious enough as improvements that a little debate is all it takes to agree upon trying them out.

I’d never really thought about these two ideas juxtaposed though, until today. Kaizen really resonates with me. But, as IIABDFI says, changing things that aren’t broken is indeed wasteful. So, how to reconcile the two?

Well, I think its all about degree. If there’s a potentially worthwhile pay off, if it’s reasonably cheap to try, maybe it is well worth changing things that aren’t especially broken. You might learn through trying your new approach that what seemed reasonable before was, if not broken, ripe for substantial improvement. And if it doesn’t pan out? That should be OK. Trying new things involves some risk. Sometimes things don’t work and you need to revert to the original way of doing things. Unless you’re drastically affecting quality or productivity or some other key facet of software development then I’d argue that trying new things should be encouraged.

If, on the other hand you’re thinking of a disruptive or expensive change, and the outcome is uncertain, and what you’re already doing is seemingly OK, perhaps that’s a red flag. Perhaps that’s when you need a slap around the head from IIABDFI to remind you not to get carried away.

What do you think?

3 comments:

  1. Jon,

    This reminds me of another quote, 'Good is the enemy of great'. Scrum is about continuous improvement and achieving greatness. IIABDFI is about being good or average.

    The biggest problem with just being good enough is you never get better you just keep going along being average. In some ways average is worse than below average. If a team is below average there are obvious issues and change is easier. IIABDFI will get the individual, team and organization in a rut.

    ReplyDelete
  2. I think the challenge is that there are various degree of being broken. The perfectionist in me would want to keep on improving the software , but the rationalist me stops me form getting carried away.

    I think... when its my "own creation" e.g. a module or a framework that I created, its generally the perfectionist that wins and when its something that I "inherited" , the rationalist wins.
    Pretty lame- eh ?
    In other words I think it matters (among other factors) how emotionally involved are you with the subject.

    ReplyDelete
  3. This topic makes me think back to chemistry class. Reactions are constant with the collisions of molecules, but some will rarely if ever happen without a catalyst. Broken/not-broken situations are high activation energy reactions.

    Constant collision, continuous improvement, must be pursued, it isn't forced. Even though some efforts will always perhaps require a catalyst, continuous improvement must be intentionally pursued. It's products are important even if they aren't catalyzed by "broken".

    ReplyDelete