Author: neopragma

An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
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