Continuous Improvement vs. Continuous Change

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.

Failing Fast

 

 

 

 

 

 

 

 

 

“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.

Using Mistakes to Build Team Cohesion

So I’m working with this team and it’s a really daunting situation. There is every reason for things to fail big time. So I play it safe. I work really hard to make sure that I don’t make any mistakes (social, political, you name it). And I feel like I can’t build up any relationship with the team. Nothing. Nada.

So I scratch my head and wonder, “What’s wrong with these people?”

There seems to be this invisible barrier – they accept me because they have to, but they really don’t want me around. Me? I’m going nuts. Every day feels a little bit more aggravating than the next. Nothing seems to get through to them. Finally, there comes a meeting where I totally screw the proverbial pooch. Nothing major, no fights, no cursing, but something I say really pisses off the whole team. And they are mad, really mad.

So I get the team together, I apologize to everyone involved – take full responsibility for being a jerk (pick myself up off the floor, dust myself off) and we move on. Funny thing happens though…the barrier is gone. That’s right, the quality and tenor of the conversation immediately takes a jump toward the positive.

It wasn’t until I tripped and fell that the team started to show some signs of accepting me. It took me three months. Note to self: I’ve got to remember to fall flat on my face faster next time. I think they were waiting for me to show some signs of being human (and not some sort of Agile Superman) before they were willing to accept me on the team.

Or I could be over analyzing the whole thing. Who knows? All I know is that I feel a whole lot better working with that team since then.

How to Fail Without Really Trying

Having been working on software projects now for more than a few years I feel as though I have explored many of the most common (and a few of the not-so-common) ways of failing on a project. The good news is that you can do it with any project. It really doesn’t matter which methodology you choose to use: waterfall, scrum, XP, Kanban – you can fail spectacularly with them all. It’s deceptively easy to do and in fact, in my experience teams do it all the time. According to the people who measure these things, like in the 2004 Standish CHAOS report, we seem to be getting better at failing projects over time. I like to think that somehow, in my own small way, I’ve helped to contribute to those statistics. The good news is that you too can contribute to our long and not-so-distinguished history of software project failures. For those who are just starting out at failing software projects I have a few tips to help you along.

First things first, you have to pick or become part of a project that you really don’t have much passion or interest in. Nothing beats raw, unadulterated apathy to guarantee the failure of a project. There are all sorts of clever ways to justify our presence on projects that we really don’t care much about:

1. It’s a down economy and I’ll do whatever it takes to keep a job. No, really – anything.
2. It’s too hard to do the work required to find something we’re really passionate about that pays the bills
3. Let someone else make the decisions about what we work on. This has the added benefit of enabling us to point the finger of blame for our situation at someone else!
4. Adopt a strategy of learned helplessness. This isn’t as easy as it sounds – it takes literally years of really hard work to completely stifle a person’s initiative and will to fight. But hang in there, I’m here to tell you it can be done. Persistence matters.
5. Join a team of people you really don’t particularly like or admire. If you have trouble with this, try taking on a superior attitude. That way they won’t like you even if you don’t find them particularly offensive.

If you are unfortunate enough to come across a project that perhaps your team does have some interest in, don’t despair – there are some things you can do to fix it so that nobody will want to be a part of the project in short order. First, you need to cultivate a very selfish attitude. Try the following:

1. Just go through the motions. Show up at the daily team meeting and avoid sharing anything of any use to others on the team. Make it all about you. Just like show and tell in first grade. As far as I can tell, this seems to be the natural state of affairs for most standup meetings, so it should be easy to manage.
2. Avoid the elephant in the room. Elephant dodging is truly an art form. I’ve witnessed teams go through contortions similar to dancing the “Limbo dance” in order to avoid tangling with the team pachyderm.
3. When in meetings, be sure that you attend without making any significant contribution or preparation. I find sitting quietly with my arms crossed and occasionally nodding off during a meeting tends to discourage people from inviting me to more meetings – and that’s generally a good thing – for me.
4. If someone solicits your input, give it grudgingly if at all. If people have a hard time getting your contribution, they’ll see it as a rare commodity and value it more highly.
5. Whatever you do, don’t make the classic mistake of getting frustrated and asking more of others – otherwise they’ll start to do it too, and then eventually they might do it to you!
6. Be very quiet. Don’t speak up unless asked, and when that happens, be sure to answer using monosyllables. “No” is always a good start. Even better – just shake your head.
7. Don’t *ever* rock the boat.

Oh, one more thing: I know people are going to need help with some of this, so I want to offer my services as a consultant. If you really want to fail the easy way, give me a call – my services are available for a very high price. In fact the steep price alone may be enough to guarantee project failure. Of course as far as I can tell the competition is pretty fierce these days. There are a lot of people out there who will cheerfully escort you down the well trodden path to failure while taking your money and spouting meaningless managerial advice.