top of page
Articles: Blog2


The other day I was re-reading Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. I was looking for a metaphor for quality used in the book that I remembered reading long ago. I found myself sucked into the book almost immediately and I stumbled across a quote that caught my attention.

Mountains should be climbed with as little effort as possible and without desire. The reality of your own nature should determine the speed. If you become restless, speed up. If you become winded, slow down. You climb the mountain in an equilibrium between restlessness and exhaustion. Then, when you are no longer thinking ahead, each footstep isn’t a means to an end but a unique event in itself.

This gave me pause. You see in software development, this kind of thinking is completely alien. Maybe that’s too broad a generalization, so let me refine that statement a bit: for me, that notion of equilibrium and balance is foreign. You could say it’s all the same. I’ve grown up in the software business. I know how to work all night to hit a deadline, to “sprint” toward a goal. I’ve been doing it for 20 years.

And boy, sometimes I get tired. Really tired.

I once told someone that I have no right to preach the merits of sustainable pace to anyone – because I can’t seem to do it myself. Recently, in a rather dramatic turn of events, I collapsed just prior to a speaking engagement. The pace, the pressure, and the travel just added up to too much. Fortunately, that’s all it appears to have been – stress. Thank God.

But I was left with a compelling desire to…sit still for a while.

It occurred to me that the mountain wasn’t going to go anywhere, so I might as well take a break.

The really curious thing was that I was still restless. I had just been delivered one of life’s little telegrams with the message, “Slow down or die.” I figured most rational people would pay some heed to a message like this. Apparently I’m not a member of that clique (the rational ones). Now this doesn’t come as a remarkable surprise to me, but I did face this revelation with some curiosity.

The question is, why the hell can’t I slow down? Maybe its the business I’m in. Let’s face it: software development is all about going faster. Call it Scrum, call it XP, shucks I really don’t care what you call it. The bottom line is that it’s all about delivering value faster. Of course value is also what Pirsig’s book is about, the subtitle being, an Inquiry into Values. So what are my values? Is delivering fast one of them?

If I look at the agile manifesto, a document that can be fairly said to have influenced my work life quite substantially, I read the following:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Well, there is no reference to going faster that I can read into that. Now you might argue that the principles might state otherwise, but on the face of it, the values don’t have anything to say about how fast we delivery software.

Of course with all the running about that I tend to do, it may just be that I’m a lot lower down on this metaphorical mountain than I had previously thought. You see, I’m not sure I’ve had much practice at this stopping game.

Maybe it’s like this: when you learn how to ride a bike, the first thing you learn to do is learn how to get going. How to get started. How to initiate the process. Once we do that then we need to learn how to keep it going. How to sustain our progress and navigate through unexpected turns. Finally, we need to learn how to stop. It could be a gentle glide or a power slide, but stopping is just as important as starting.

Frequently I see teams that in some very important ways seem to have mastered the first two steps, but seem to struggle when it’s time to stop. There are all kinds of reasons to stop when working on a team. For instance:

1) at the end of the release

2) at the end of the day

3) at the end of the sprint

4) when something goes wrong or breaks

5) when someone notices something out of the ordinary

6) when the team is done

The funny thing is, like a lot of things that I observe on teams, I see these reasons for stopping in myself too (I have a list of things to stop that is very nearly ten times that long). So I have become very curious about this “stopping” thing. Frankly, I find it all a bit terrifying. It feels risky to think about stopping. So I’m approaching it with due caution. Dipping my toe in the slow pool – starting with some meditation.

So, I take the time to stop and do nothing a few times a day. I just sit there and listen to the hum of the world whizzing by. I’ll be honest, I can’t tolerate it very long before I am sucked back into the frenetic pace of “the game”. It’s an experiment. An attempt to practice that crazy stopping thing. I have to admit it’s kind of nice…sometimes.

So, that’s where I’m at. This post has meandered and digressed and gone nowhere in particular. That feels about right. This is probably a good place to stop.

1 view0 comments

Recent Posts

See All
bottom of page