On Failure, Success, and Learning

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)

Hire a Coach, Not a Crutch

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.

Home, again, from Agile 2011

It’s been a wonderful, busy week in Salt Lake City at the Agile 2011 Conference. It was great to see so many friends and to make new ones. I had an incredible number of fascinating conversations.

This weekend I was saddened, though not surprised, by the number of tweets with complaints about the conference, often tweeted by people who didn’t go. To paraphrase Yogi Berra

Nobody goes to the Agile Conference anymore. It’s too crowded. (Continued)

Specialized Skills

Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. (Continued)