Continuous Improvement vs. Continuous Change

October 14, 2014

Evolution-des-wissens

I’m a little down on the notion of continuous improvement these days. It’s not that it doesn’t happen – it does…sometimes. I simply fear that it promises too much. I think part of it is the terminology. You see in the real world continuous improvement is neither truly continuous or necessarily an improvement.

To begin with, I’ve critiqued the notion of continuously improving before from the point of view that keeping any process happening full time is ludicrous. Certainly once every sprint is nowhere near continuous. I guess maybe it is continuous when you compare it to other more plan driven methods, but that’s far from continuous in my book.

No, the part that I find most objectionable is the improving part. You see, it’s misleading. It suggests to me that every change is an improvement. That every effort is a step forward, not back. And that is simply not how it works. It would be better labelled periodic experimentation, or punctuated mutation. You see, in the real world, when we change something, we never really know if it’s going to work out or not. There are 50/50 odds that the change will actually make things worse! 

Of course that’s a good thing. We learn a little either way. Hopefully.

The problem I have with continuous improvement is that it sets up an unreasonable expectation in those we sell it to. To restate the sales pitch: every change will be an improvement and they happen all the time.

If every change were really an improvement, I would be worried that I had been transported to an alternative universe. That I was being monitored by aliens. That there was a black helicopter hovering over my house. I’d be making a tin foil bunny suit. Fortunately I know what universe I’m in, that there aren’t any black helicopters over my house, and tin foil tends to chafe in the damnedest places. Not too sure about the aliens…

Fortunately, many of my efforts at improvement fail. And that’s the way it should be.


How to Slow Down Your Team (and Deliver Faster)

September 23, 2014

Is your team in need of a little improvement? Are they getting a little stale? Are you looking for a way to bring their performance “to the next level?” Well, maybe you should slow it down.

Oh I know, those other consultants will tell you that they can speed up your team. It’s the siren song of the wishful manager, “Speed my team up: faster!” But I’m here to tell you they’ve got it all wrong.

let me ask you this:

When you get a flat tire in your car, do you speed up? No!
If there is a burning smell coming from the oven, do you heat it up? No!
So if you see your teams start to slow down, why on earth would you try to make them go faster?

Let’s face it, when teams slow down there is usually a damn good reason. So rather than speeding up, perhaps it’s time to slow down, pull over, and take a look under the hood.

How do you slow down? Nobody really teaches that. Everybody is so focused on speeding up they seem to have forgotten how to slow down. Here are my top 10 ways to slow down your team (and hopefully address your problem):

  1. Apply a WIP Limit
  2. 1 piece flow
  3. A more rigorous definition of done
  4. Pair programming
  5. Promiscuous programming
  6. Continuous Integration
  7. Continuous Delivery
  8. Acceptance Test Driven Development
  9. Spend more time on impediments
  10. Hack the org

Taking time to implement any one of these things is almost guaranteed to slow you down. That’s a good thing, because your team probably needs to pull over to the side of the metaphorical road and repair a few things.


Failing Fast

August 6, 2014

IMG_2037

 

 

 

 

 

 

 

 

 

“Forget your perfect offering. There is a crack, a crack in everything. That’s how the light gets in.”
-Leonard Cohen

How’s that for a weird quote? I heard it the other day on the radio and it stuck in my head. It has a resonance for me that I just can’t seem to shake. You see, like most folks, I’m intimately familiar with imperfection. I’m faced with it in many of the projects I’m most passionate about: My writing, my career, my boat…

Yeah, I’m building a boat. Technically, it’s my second boat. I think just admitting that qualifies one as insane. The first boat was a mere 9 foot skiff I made for my daughters. It took me almost 3 years to complete it. I should probably mention that I have absolutely no woodworking skills. So after I finished the first one, I decided to build another. This second boat is just for me. Well, me and my brother actually. We’re building it together in his garage. We’re about a year into it so far and it’s coming along pretty well.

OK, honestly it’s a little early to tell. We make a lot of mistakes.

I don’t know what it is about working with wood, but any mistakes you make tend to jump right out at you. Of course, the bigger the project the more room there seems to be for error. I’m discovering that a 17 foot boat leaves lots of room for error. Cutting parts to shape is hard. Getting screws to bite and not strip. Glue everywhere. One false move with a power tool and there are splinters galore. The whole project really is just a glorious catastrophe waiting to happen.

If ever there were a case study in failure, this boat is it for me. Now that might sound terribly defeatist, but it’s not meant to. You see, I’ll finish this boat too, one way or another. It’s just that I’ve got a whole lot of failing to do in between now and the day I finally launch her.

Of course, given all this failing, it’s still pretty astonishing how slowly I manage to learn. For instance, I’m noticing that I don’t seem to give up my standard ways of learning, even in the face of overwhelming evidence that they are not paying dividends. I’m fairly sure I’m not alone in this behavior.

First there is my innate impatience to see quick results. This whole measure twice, cut once thing just doesn’t seem to come naturally. For some reason I’m always in a rush. I find it extraordinarily difficult to slow down and just take my time. Maybe it’s some american thing where we are just impatient with anything that impedes progress…No, I don’t buy that either. I think slowing down is really hard work. It takes discipline to slow down and treat things in a very thoughtful and conscientious manner.

Savoring the moment and appreciating how things feel in the moment is not something that just happens to you. You have to make time for it. I can show you all of the places on the boat where I rushed the job. The places where I tried to drive the screws in with a power drill (I drove them right through the panels – genius!). The areas where the wood split because I didn’t take the time to test the bend first. The evidence of my own impatience is writ large in the construction of this boat.

Do you want to know the really amazing part? I still keep rushing!

Scary. Did I mention that slowing down is hard?

Another area where I struggle to learn: working as a team. Working as a team is hard too. First you have to keep those you are working with in mind all the time.  That doesn’t come naturally at all for me. I’ve never really been a good team player. I grew up participating in individual sports like running, wrestling and weightlifting. I operate very well solo. Working as a team has been an alien experience. For example, when my brother and I are working on the boat, I often struggle to figure out what he can do to help. I’ve seen this on software development teams too. Ask a developer what needs to be done, and you will get a detailed list of all of the work that remains. No problem. Ask that same developer how someone else can help them get that work done, and often you will get a blank look. When you are not accustomed to working on a team, it’s hard to picture what teamwork looks like.

To make matters worse, my brother and I have different skill levels when it comes to woodworking. This means that sometimes I need to take the time to show my brother how to do things (or vice versa). I find that hard to do when I’m rushing to get things done (see above). But without taking that time to show him how to do things, I lose the benefit of his help. I lose the teamwork. I’m finding that teamwork takes some serious patience. Ultimately I know I will go faster if both my brother and I can work at the same level, but that means initially I will have to slow down to achieve that goal. Slowing down to go faster.

I’m very lucky to have someone to like my brother to put up with all my mistakes. In a peculiar way, building a boat with him is teaching me a lot about software development. That’s probably good, because God knows if we’re ever going to finish that boat.