Agile Coach Journal

This is an old post that got lost in a technology shuffle. I was reminded of it recently while reading Tom DeMarco’s great book Slack.

One of the things I do when I am not working is play guitar. I also study guitar, though I have made slow progress over the years. It is still fun. One of my favorite teachers is Ronnie Earle. I have an old VHS tape of his in which he shares his philosophy of playing. And he makes this statement that has stuck with me for years: ”Sometimes, you have to leave some space between the notes.”

His message is that the music has more soul, is more meaningful when you let it breathe. I never cared for punk music and shred guitar. The typical song starts out with a crescendo and never lets up. There is no chance for it to sink in. My brain just can’t process it in real time. Ronnie knows better. Holding a note, keeping a silence for a beat or two adds emphasis and richness to the melody. He is a foot tapper, too. On his great solos, you can sometimes hear nothing but his foot. Check out “Blues for Bone”.

What has that got to do with agile software development? You may see it already. I will provide another clue.

Have you ever heard of “being in the flow”, that state of coding nirvana in which code flows like a river and the clock stops ticking? That is where a hero coder saves the day. I have been there. It can be fun, especially during that first week that the deadline starts to breathe down your neck. It is not so much fun in the second week. By the fourth week, after the deadline has passed, the flow starts to resemble something coming out of a polluted pond. And your SO has no sympathy. This is silo flow, by the way. TDD flow is quite different.

Sometimes that flow gets perturbed by an especially sticky problem. It is as if a dam goes up in front of you. You see the problem but you can’t find a solution. So you bang up against it over and over, like a fish trying to jump the dam without a ladder. Have you ever been there? I was lucky to work with some really great people who learned before me and helped to me realize that the best thing to do in such is case is to walk away. Go to the gym. Get some lunch. Coffee might help, but it might just get you to knock against the dam harder. Either do something else and let your inner brain solve the problem, or talk to someone.

Telling your troubles to someone else can be a great help in solving them, even if that person has no idea what you are talking about. Just stating your problem to another person can help unlock the secret of its solution. Your brain switches from visual to verbal and new kinds of thoughts are born. I often offer this to people as a reason for doing code reviews and pair programming. (Yes, there are still engineers out there who do not do code reviews.)

I encountered a variation of this, I can’t recall where. Some fellow had a toy monkey in his cube. If he had a problem, before bothering anyone else he would “tell it to the monkey”. (Who was that?)

Ken Schwaber, Guru of Scrum, describes it this way. I paraphrase what he said at one of my trainings about the “sustainable pace” component of agile development. “That 40 hour week rule is a trick. When a team is committed to the goal and working together all week long, their brains continue to work on the project in the background when they are not in the office.” I am not sure how much that happened for me as a practitioner, but I know it did in some ways. Monday standup often had statements like “I have no idea what I did on Friday” but the other days often had statements like “I was thinking about this problem last night and I would like to discuss it after the meeting.”

At another level of magnitude, I saw an interesting answer to the question “When doing TDD, how long is it reasonable to have a continuous red light?” This was in a discussion thread at Microsoft where Ward Cunningham was a frequent contributor. His answer, and I paraphrase again, was “Often an experienced developer will go 5 to 10 minutes between greens lights. If you see red for 45 minutes, that is a signal that you are thinking about it in the wrong way. You should stop, back out your changes to the last green point and try another approach.” I would add this is a good time to go for a walk. Give your brain a rest.

So those are some micro tips for your teams. Trust your subconscious mind to be a smart partner. If you get stuck, don’t keep slamming against the dam. Do something else for a while. Then consult someone else. Do some lateral thinking. Get outside the box. Maybe do no thinking at all. And even when things are going well, give your brain a break. Leave some space between the notes.