Year: 2012

Posted on by — 2 Comments

Can a new dog learn old tricks?

[This was originally published on my old blog on 18 September, 2007. A friend recovered the post from Time Machine. There were some good comments on the original posting, but those were not saved by Time Machine. Unfortunately, the attitude I observed 5, 15, and 25 years ago hasn’t changed much. Enjoy.]

A few months ago, I used the phrase “the collective experience of the industry” in an online discussion about good practices in software development. I got slammed. We have no “collective experience,” I was told, we just have “a bunch of individual experiences.”

At the time, I thought it was incorrect to say that we have no collective experience. Software developers encounter many of the same situations and solve many of the same problems over and over again, in different domains and in different technical contexts. At the time, it seemed to me that the common aspects of these experiences could form the basis of a corpus of shared professional knowledge.
Continue reading Can a new dog learn old tricks?

Posted on by

Beware the golden hammer

Change agents and coaches often ask me how to overcome resistance. The coach wants a team to adopt a practice or technique that he/she “knows” is good. Why won’t the team members consider his/her suggestions? It’s possible that they just don’t see any pressing need to change the way they work.

It turns out that experienced professionals aren’t slumped in their offices in a puddle of their own drool, dazed and defeated, surrounded by the smouldering remains of failed projects, hoping a savior will appear and teach them a magic trick that will make them better at their jobs. Notwithstanding industry studies that highlight general problems in software delivery, development teams aren’t “failing” left and right. Software development organizations do deliver results. Few of them deliver results as effectively as they could do, but they aren’t necessarily aware of this, or they don’t see it as especially important because it isn’t causing them any real headaches. People have settled into a comfort zone where they are respected, they feel successful, and they are well paid. When a change agent comes charging at them with golden hammer in hand as if they were in need of rescue, insisting that they change the way they think about and approach their work, why should they listen? The truth is they shouldn’t listen. They’re doing exactly the right thing when they “resist.”
Continue reading Beware the golden hammer

Posted on by — 4 Comments

Warning signs of client dependency

When we function in the role of coach, our primary goal is to bring the client to the point of self-sufficiency with respect to some aspect of their work. Whether we are engaged as a technical coach or process coach, we want the client to internalize some set of values and practices that are presently unfamiliar to them, to shift their mindset in some way, and then to carry the new approach or new skills forward independently. We want to make ourselves unnecessary.

The same can be true when we are engaged as management consultants. In that role, our function is usually to advise and consent. We will be one source of information among several, or many. We may not be privileged to know all the details of the decisions the client needs to make. We are only asked to apply our best professional judgment to the situations the client wants us to address. The advise and consent function is different from the coaching function.
Continue reading Warning signs of client dependency

Posted on by — 1 Comment

The Blackbird Effect

This is a re-issue of a post from my old blog that people have asked for.



SR-71 Blackbird. Photo from Wikimedia Commons.

The SR-71 Blackbird, a global reconnaissance aircraft developed by the United States Air Force, first flew in 1964, and was in service from 1968 to 2001. Even at the time of its retirement, it represented relatively advanced technology as compared with most aircraft. In 1976, a Blackbird set the speed record between New York and London at just under 2 hours. The Blackbird’s speed record for manned air-breathing aircraft still stands, although manned rocket-powered aircraft and at least one unmanned air-breather have gone faster.

Continue reading The Blackbird Effect

Posted on by

Ethics vs. morality

In one of the most bizarre misunderstandings of the code of ethics I proposed the other day, a reader suggested that by adopting a professional code of ethics, a consultant or technical coach was somehow trying to impose Western morality on people in remote parts of the world. Because this is such a strange reaction, it’s difficult to know how to respond. Yet, if the code of ethics as currently written can result in such an extreme misunderstanding, then I feel I must try. Continue reading Ethics vs. morality

Posted on by

Ethics vs. technique

Some of the comments on “A code of ethics for consultants, trainers, and coaches” suggest that the statements in the list may not be self-explanatory. Some of thes points might be worth a longer explanation than will fit into a response to a comment. One example is the apparent confusion between professional ethics and professional technique. Continue reading Ethics vs. technique

Posted on by — 11 Comments

All evidence is anecdotal

It’s a commonplace for people to disparage the direct experience of practitioners and to favor the indirect observations of researchers. This has always struck me as a rather strange attitude. A person who does a thing every day, and whose livelihood depends on doing it well, surely knows what has worked and what has not worked well in practice, at least in his/her own experience. Someone who takes the work seriously will naturally remain open-minded about learning new techniques and methods throughout his/her career, building up a deep and reality-based understanding of the work over time. People working in different domains will have had different experiences and will have solved different problems, so if you listen to several experienced individuals representing different industry sectors you will end up with a pretty good cross-section of practical knowledge.

A practitioner who explains what he/she has found useful in the field is giving you an anecdotal report of his/her experience. Is a researcher giving you any better information when he/she publishes the findings of a study? Isn’t the researcher giving you, for all practical purposes, an anecdotal report of his/her experiences in preparing a research paper? Both forms of evidence are anecdotal, are they not? Would you really dismiss the opinions of a 35-year veteran of software development in favor of a report prepared by a couple of graduate students who had never written a line of code in anger, and whose main purpose in doing the study had been to learn how to “do a study?” Are the hundred-odd real-world projects the veteran has completed really less informative than the two or three sets of apples-and-oranges observations the graduate students made in their study? Anecdotal evidence is still anecdotal, even after someone publishes it. The question is whose anecdotes carry more weight.
Continue reading All evidence is anecdotal

Posted on by — 10 Comments

A code of ethics for consultants, trainers, and coaches

In November of last year, Dan Mezick initiated a discussion about the need for a formal code of ethics for “agile” coaches. He was especially interested in the idea that coaches should explicitly avoid creating a dependent relationship with clients. After all, the main goal of a coach is to help the coachee become self-sufficient and independent. A subsequent article on InfoQ, “Should Agile Coaches Have a Code of Ethics?”, spurred further discussion by additional people.

I found the discussion compelling, and subsequently Dan and I had a few email exchanges about the topic. Although the original discussion centered just on coaching services, and specifically “agile” coaching services, it struck me that the prohibition on making clients dependent on their external helpers applied equally to consulting and training services.

I decided to revisit the code of ethics that I have been using. Although not a member, I learned about the code of ethics of the Institute of Management Consultants (USA) in the mid-1980s. It seemed to be relevant to the kind of work I was doing at the time, and have done most of the time since then. On re-reading the IMC code closely, I found it lacking in a few respects that I hadn’t noticed way back in the 1980s. For one thing, the sentences aren’t crafted very well. For another, some of the statements are redundant. Thirdly, the subdivisions in the list seem unnecessary. Finally, the list doesn’t address issues of social consciousness that have become important in our society since the time it was written.
Continue reading A code of ethics for consultants, trainers, and coaches

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