What Decision Are We Supporting?

In business, we’re often asked for estimates with too little context to understand the request. When that happens, we’re likely to expect the worst–that our estimate will be treated as a “guarantee not to exceed” and we’ll likely be in trouble at some time in the future. Of course we think that; we’ve been burned too many times in the past. Our fear of the consequences will encourage us to spend far too much time and effort trying to get the estimate “right” so we won’t be blamed.

If an estimate is really an estimate, then we know that it’s “wrong” in the sense that the subsequent actual reality is unlikely to equal it. The estimate is a guess, perhaps an educated guess, predicting the future. Predictions are hard, especially about the future.

Given these problems with estimates, why do we bother to make them at all? (Continued)

Rough Cut

A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. (Continued)

Agile Fluency

Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.

Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. (Continued)

Bad Scrum, but Pretty Good RUP

Most metals have a bit of springiness to them. If you want to bend them to a certain shape, you have to bend them further than that. When they spring back a bit, they’ll take the shape you want.

Today, I was looking at a milestone chart for a project transitioning from a serial lifecycle to an Agile one in a large organization. At first, I despaired at the picture it painted. There are Requirements and Design phases for the release, and a “hardening sprint” before release. Don’t get me wrong. Things are much better than they were before the transition started, but there is quite a way to go before this effort reaches what I would call truly Agile.

Then it struck me. (Continued)

Technical debt comes in various varieties

Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

In this, Ward was not referring to poor programming practices, (Continued)

Errors in Project Management

An article in USA Today (December 12, 2012) about highway projects in New York has the sub-head, “Design errors, planning lapses drove up costs more than 14%.” Among the things listed that “drove up costs” are

  • More asphalt than projected due to a math error
  • More temporary concrete dividers than planned, as plans called for only half what was needed
  • Unanticipated excavation costs.

It’s true that no one likes for costs to exceed estimates, (Continued)

Invest in yourself

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.

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.

Do Not Drive Beyond Your Headlights

I’ve heard stories where organizations have “tried Agile” and the results were so bad that they’ll never make that mistake again. In some of these stories the blame is laid at the feet of bad coaches. In some it’s blamed on lack of coaching. In some, the blame is placed on clients who aren’t ready for Agile . If blame is to be lodged, then any of these will do.

The more interesting question, to my mind, is how can we achieve a better result. (Continued)