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. Read More

6 Comments

Categories: Responding to Change

Tags:

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. Read More

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. Read More

A Virtue of Imprecise Measurements

I’ve talked about The Importance of Precise Estimates. In that post, I said,

My advice is to

  • measure your progress
  • watch the trends
  • project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success.  Alex summarizes,

Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.

It’s something to think about.

 

Process Metrics

My good friend Jack Ganssle commented over at EETimes (also available on the TechOnline India site, with different comments) about my recent post on process standards.  In it, Jack cautions against relying on “a strong feeling that ‘things are better.'” He recommends using measurements to bring it back to the realm of engineering.

Bob Pease, analog engineer at National Semiconductor and writer at EDN Magazine, used to say, “when something seems funny, measure the amount of funny.” That’s easier done in the engineering domain than the people domain, of course.

These two simple guidelines will help: Read More

What is an Agile Coach?

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. Read More

Process Standards

There’s been a long discussion on one of the mailing lists about software development process standards. Someone quoted Robert Glass from his essay “A New Way of Looking at Software Productivity” in Software Conflict 2.0: The Art and Science of Software Engineering

Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?

Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context.  But it was introduced to me with the question

This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way.  Does anybody disagree with this as the goal?

That sounds so logical, doesn’t it. Read More

Losing Customer Focus

Southwest Airlines has long been known for two things: low prices and attention to customer service. Since they instituted the “reserved place in line” so I wouldn’t have to stand for a long period of time, I have come to check their website first, and only rarely look for alternative flights. Sadly, they’ve taken their eye off the ball. I suspect that the focus on customer service has been replaced by a focus on growth (given their in-progress takeover of Airtran).

Some months back, I noticed that their website had become bandwidth greedy with javascript doodads. This made it painfully slow on many hotel internet connections. They seem to have backed off from that a bit, but have now broken it in a way that prevents me from buying the ticket I want. (In addition, when I call the “Southwest Airlines Customer Representative for assistance” as prompted on the website, I find they no longer have enough to handle the call volume. I wonder if they’ve reduced the support, or if the call volume has increased, or both.)  There’s a lesson here about considering all of the important user stories when implementing new functionality, so it bears describing. Read More