I’ve seen many comments on the topic of estimation in the past year, and I’m starting to notice some trends and assumptions in them. One of the common assumptions is that, given a particular team and amount of resources, there is a correct length to a project. A twin to this one is that there is a correct estimate that contains the same end date as the subsequent actual project performance. Read More
Used with care, software development estimates can help you manage project risks. They let you peer into the future, though only as well as your current understanding allows. Estimating based on what you know is easy. Estimating based on what you know you don’t know is possible. Allowing for what you don’t know you don’t know is prudent.
Managing risk is a dynamic process. I’ve seen people document a risk in a “Risk Register” document and promptly ignore it. That’s not management. Instead, consider different ways a risk might be reduced in likelihood or consequence. When time or cost is of the essence, think about how you’ll determine what you can afford, and when you need to take a second-choice approach. Read More
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? Read More
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. Read More
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. Read More
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. Read More
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, Read More
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, Read More
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.
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