Tag: words

Posted on by — 1 Comment

Thor’s hammer had a name, so why can’t mine?

Mjölnir.

Thor’s hammer was called Mjölnir. Cool name for a problem-solving device.

Liza Wood commented on a recent post of mine in which I lamented the overuse of the word, "agile," and the ill effects of that overuse. She wrote, in part:

I completely understand why you have become disenchanted with word "Agile", but I am sticking with it for now. For the majority it’s still at least a starting point to have a pragmatic conversation about product development (not just software).

I wonder about that. Is the word really a starting point for pragmatic conversation? Different people have had different experiences with that. My experience has been that people already have some pretty firm ideas about the implications of the word, "agile." A recurring pattern is that a change agent goes into an organization and happily proclaims, "Oh, boy! We’re going Agile!" To his/her surprise, the people in the organization do not react to the proposition joyfully. The word "agile" connotes Happy Things to the change agent. What does it connote to other people? Why are they not happy to hear it?

Ron Jeffries’ classic article, We Tried Baseball and It Didn’t Work, suggests an answer.

Continue reading Thor’s hammer had a name, so why can’t mine?

Posted on by — 4 Comments

Words don’t mean what they don’t mean

<rant>

Words don’t have firm, unambiguous, unchanging meanings. This is a source of some frustration for me. The same word can have multiple meanings. Sometimes there are context-dependent meanings. Sometimes there are shades of meaning conveyed by tone of voice. People can have multiple interpretations of the same basic meaning of any given word. Clear communication is more challenging than it might appear to be.

In the field of software development, we have an unfortunate habit of re-using old words to represent new concepts. Maybe it’s because we value re-use (whatever that means). The English word, agile already had a meaning before software developers came along and started using it for something else. A ballerina is agile. A faun is agile. That’s easy to understand. Now, software development can be agile, too (whatever that means).
Continue reading Words don’t mean what they don’t mean

Posted on by — 3 Comments

The problem with success (and failure)

This morning I noticed a copy of the good old Cone of Uncertainty on the wall of a cubicle at a client’s office. It reminded me of Laurent Bossavit’s ebook-in-progress, The Leprechauns of Software Engineering, in which he challenges several of the myths or assumptions that have become traditional lore in the software industry, including that one.

Laurent writes,

What is odd, to any experienced software engineer, is that the Cone diagram is symmetrical, meaning that it is equally possible for an early estimate to be an over-estimate or an underestimate. This does not really square with widespread experience of software projects, which are much more often late than they are early.

Er…wait a second. Isn’t that very assertion an example of “anecdotal evidence?” Is it another Leprechaun? Who says projects are more often late than early?

Silly Dave! Everyone knows who said that. It was the Standish Group, in their famous Chaos Report of 1994. Slightly more than 70% of IT projects fail. That’s why every office building in the industrialized world is on fire, and white-collar refugees are streaming from the cities, leaving their belongings behind except for whatever personal electronic devices they can carry.

Only…they aren’t.
Continue reading The problem with success (and failure)

Posted on by — 16 Comments

“Agile” considered harmful

At the time the term “agile software development” was coined, it filled a need. Different people had come up with different responses to the endemic problems in IT. Most of these innovations were ad hoc, localized, and not widely shared. A few had been published in book form and were better known than others. But there was no single flag around which people interested in improving the state of the art of software development could rally.

After the Snowbird meeting, we had such a flag. “Agile” was loosely enough defined, and yet clearly enough focused, to serve as a basis for people to innovate in the areas of process, practices, and human factors to achieve better results than were seen with traditional methods, as indicated by the many industry studies and surveys carried out in the 1990s and early 2000s. The loose definition of “agile” was, in the early years of the movement, its main strength. The very looseness of the definition enabled innovation. But every strength is also a weakness, when it is taken beyond the point of diminishing returns.

Now, more than ten years later, the word “agile” has suffered from the inherent downside of its loose definition. The word has been co-opted by every pundit, author, consultant, trainer, and coach in the IT field. For them, “agile” means “whatever we sell.” For people in IT organizations, the perception is that they had better embrace “agile” or they will be marginalized and their careers will stall. For them, “agile” means whatever it has to mean to qualify them to sit with the cool kids in the school lunchroom. They are more concerned with achieving a high score on the latest “agile” assessment than they are with software quality, consistent delivery, and sustainable performance. Form trumps substance.
Continue reading “Agile” considered harmful