George Dinwiddie’s blog

I write this post from Loveland Colorado, the current location of Consultants Camp. This is an international gathering of consultants who share information and lessons with each other. It’s part of my practice of self-improvement.

I invest a lot in my own professional development every year. I attend conferences such as this one. I read. I converse with colleagues.

My career has spanned a number of decades, and I expect to continue to do so indefinitely. I gave a talk at XPDay Manhattan in 2007 on Sustainable Career where I explored this topic. To do so, you not only need to continue learning, you need to learn things that have a long half-life. Learning specific technologies may be valuable, but those technologies quickly become obsolete. Be sure to also learn things with lasting value, such as the principles behind specific techniques.

You need for your career to last a lifetime. Invest in yourself.

When I was a kid, I decided to invent a new kind of battery. I had a pretty good idea of what was required, having cut open my share of batteries and even built them with a lemon, copper, and zinc. It’s just a matter of two metals (or one metal plus carbon) and a corrosive liquid. How hard could it be to create the battery of the future?

I mentioned my aspirations to my father, who was a chemistry professor. “What do you know about valence?” he asked.

“What’s ‘valence’?”

He proceeded to explain about electron clouds and the tendency of atoms to fill or empty their outer ring of electrons.

“So the valence of oxygen is 2.”

“Yes, except when it’s 1 or 4 or 6 or some other value. It’s not always simple.”

I’ve been thinking about that conversation since the end of the Agile 2011 Conference. (Continued)

More and more, I see advertisements and hear people asking for a Coach to come for a period of time and help their organization on a full-time basis. They seem to assume that it’s necessary to Coach the team 5 days a week, every week. This makes little sense to me.

Teams need time to acclimate to new knowledge. They need to try it on their own, making decisions without immediate help. Otherwise they come to depend on the coach making the decisions, and they don’t learn how to make them, themselves. I’ve seen this happen when I’ve been working too steadily with one team.

It’s also important to limit the presentation of new information to the rate at which it can be absorbed. Time the team spends practicing without the presence of the coach is an important part of this absorption. Without such “soak time,” the team will get lost in the details, trying to climb the proficiency ladder without learning to practice the simple things fluently.

If you try to go faster than you can, you’ll only end up going slower.

Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.

I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.

This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.

I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?

This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. (Continued)

I’ve just spent the past week at Junior Sailing Camp, helping kids circa age 10 become better sailors. At this age, they’ve learned many of the basic concepts: that pushing the tiller to starboard turns the boat to port, that they need to pull the sail in when going upwind, and let it out when going down.  Yet they often struggle to get the boat going in varied conditions.  They steer too vigorously  in light air or choppy waters, killing the delicate momentum they’ve achieved.  They position the sail inefficiently–sufficient for a moderate breeze, but insufficient for zephyrs. And in heavier air, the wrong sail trim may result in an impromptu capsize drill.

Much of my coaching depends on helping them observe these varied conditions and how the results of their actions are affected by them. Their current skills work fine when the conditions match the way they practice them. When conditions change, the same actions fail. Without keen observation, the cause of that failure is a puzzle.

I’m teaching them to see the wind. (Continued)

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. (Continued)

The term Spike Solution is associated in my mind with the early days of Extreme Programming.  I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term.  I’m sure there are predecessors, even if not expressed as distinctly.

The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem.  It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus. (Continued)

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

(Continued)

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  (Continued)

Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question.  And so I answer,

That people could ask for, and could accept, the help they need and want. (Continued)