It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we are going to take a look at what I consider the first book in Jerry’s seminal series on managing quality software: Quality Software Management Volume 4 – Anticipating Change published by Dorset House Publishing in 1997.

Review on Amazon

A while back, I reviewed this book on Amazon:

Introduction to Change Artistry and how to reach it

In the fourth and last volume, Jerry introduces the Satir Change Model. Since an anticipating culture relies heavily on change artists, this model comes in handy in forming such an organizational culture. Weinberg explains in great detail how people react to foreign elements in the organization, and that too many threatening external influences may result in people hiding in their basements. In addition, he walks the reader along with the change model and explains how to get from an old status quo to a new status quo and actually make and foster the necessary change.

Weinberg continues further on how an anticipating organization works through the overall software development process. Starting from meta-planning, and tactical change planning, over to planning as a software engineer, this volume conducts how to make change stick in the organization. In addition, he writes about the process and process improvements. He lists processes commonly in practice by the time he wrote the book (1997), and discusses why it is important to know several process models as a change artist. Weinberg describes the differences between a process vision, the process model, and the process.

Finally, he gives a compelling view of things that are still relevant nowadays. Taking a closer look at how to terminate projects, and how to know that you should terminate or re-plan them, he gives a thorough overview of dos and don’ts in software development for the project manager. He discusses that requirements documents and design documents should be placed in a version control system alongside the code. Considering that he wrote this book more than ten years ago, it struck me when I encounter multiple teams which are still not using any version control mechanism at all. Finally, Weinberg takes a look at tools, and how and when to introduce them.

The biggest gift in this volume is the lists of dos and don’ts in software projects alongside the eleven commandments of Technology Transfer. His comparison of the waterfall model to other software development models may be seen as a bit outdated, but most of it is still relevant. Weinberg even touches on the spiral model in this discussion, so portions of it also apply to modern Agile methodologies. Of course, the principle to know about many models and knowing when they apply and should be used is the key lesson to take away here.

A blast from the past

Quality Software Management Volume 4 is the final book in Jerry’s Quality Software Management, and just by the count of pages in it the largest. A couple of years ago, Jerry re-published this series on Lean Pub. While breaking down any of the previous Volumes into three books, I think Volume 4 turned out as four books on their own.

As mentioned in my review of Volume 3, Volumes 2-4 in the series each deal with a particular model from Virginia Satir. While Volume 2 dealt with the Satir communication model, Jerry extends this with a deeper dive into congruent communication in Volume 3, Volume 4 covers Satir’s Change model, which probably one or the other of my readers have come across on their own. What I found worthwhile remembering from Jerry’s write-up of the change model, is his deep dive into the chaos phase. At some point, the Kanban community picked up the change model and used the chaos phase as an argument for more evolutionary change. Having read Jerry’s description, I never understood the argument there.

Basically, change consists of an old status quo challenged by a foreign element, something surprising is happening. Satir also put it funnily in this way:

The beginning of a crisis is always the end of an illusion.

In quite some length, Jerry describes how we as humans act in a non-predictable way – especially so in the chaos phase of the Satir change model, where the foreign element makes us wonder about our confidence in our daily routines and how things used to work. Some people react by hiding, some people go into the offensive. In general, whenever you bring in something new different people need different experiences to learn and integrate their working habits with that new foreign element. As we certainly went through very different life situations beforehand, humans react in totally new, and sometimes surprising ways. Jerry describes a few common ones, but I am sure his description is far from complete.

I recall a situation a few years back at our company. We just had introduced a larger change in how we organize ourselves, and I found myself on the change team. At a certain point, I noticed the different ways our colleagues reacted to the change underway. Having read Volume 4, I saw various different flavors that indicated to me that we were truly in this chaos phase of the Satir change model. When I raised that observation with the larger organization, some colleagues felt offended that I stated that. They somehow didn’t want the change model to be applied to them, even though they were clearly in it. And of course, to me, that reaction was just another data point where I could see how clearly they were in chaos and didn’t want to be attributed by it.

Looking back on the different points beyond Satir’s change model, I sense some of the things in Volume 4 have not aged that well. Jerry concludes the Quality Software Management series by bringing everything back together, and relating most of it to his experiences in a waterfall organization. That made total sense to me while I was working in a waterfall company when I read it. In hindsight now, many of the lessons today did not stick that deeply compared to the other three books in the series. I found it amusingly curious, that the largest book in the series, had the least to offer to me – though it had some crucial offerings as well.

Some personal gem

I’ll conclude this review with a personal gem that I posted as well on my other posts on the Quality Software Management series.

After finishing the first or maybe second Quality Software Management Volume, I figured that Jerry kept a list of all the reminders for the readers in the book of the books. At some point, I decided to write them up and keep them for my personal reference. In case you wondering, this is how I can relate to particular pages whenever I cite something from Jerry. I thought it would be neat to share this collection. I did not separate the different volumes into different files. So, here is the full list of laws, rules, and principles from the four Quality Software Management volumes. (And in case you are wondering, yes, I noted these down in LaTeX and

These lists will probably only make sense to you if you read the books. Also note, that Jerry, later on, published an updated version of Quality Software Management, and I think he basically split each of the books into two or three smaller ones at the time. If you read those, the page numbers will not fit, and I don’t know how much he changed between the Dorset House and the later published ones.