Markus Gärtner's Blog, page 4

“Our release process pains us”

This week I had a conversation with several coaches at a client on something I consider pretty basic Agile knowledge, actually. To collect my thoughts together, I think it would be good practice to write all of them down for the time being. The topic at hand deals with test automation and enabling release-at-will through a zero-bug policy and how to get there. I think it’s going to be a brief blog entry, but fear my thoughts might run away there. So, stay with me.

Pain points in releases

The discussion started when one coach mentioned that she is trying to piece together how complicated a release will be. There is a release process in place, but releases happen so seldomly and are so painful that no one wants to deal with them (ok, that’s an interpretation on my part).

The first Agile principle I would bring in here:

If something hurts, do more of it.

Since the release process currently hurts, our human tendency is to shy away from that hurtful feeling. However, in order to solve the underlying problems, we need to embrace the pain points and solve them one by one. Elisabeth Hendrickson taught me this, I think, at the first Agile Testing Days in 2009 in Berlin. If we release more often, our releases become more rehearsed over time, since we really need to deal with the pain points in our release process. If we stick with just releasing once per year, we will continue to avoid the pains such a release causes us and the problems will continue to persist. So, contrary to human nature, we need to release more often.

From a business standpoint, we aim with Agile to be able to release more often than we actually do. Whether or not to release a new software package is a business decision where many more factors than just technical considerations come into play. Are our customers ready for a new version? Are we gaining some competitive advantage from our competitors with a new release? Do we need to proactively or reactively deal with changes in laws in our business domain to avoid legal payments? Ideally, from a technical standpoint, we should be able to release more often than we actually do. So, if your market now is fine with one release every three months, make sure, you can technically release at least every month should put you in an advantageous position. That will be one factor less to consider once you actually want to do another release. So, be able to release more often than you actually do.

Dealing with bug fixes

One other factor playing into the “let’s release less often” dynamic there is the number of bugs in each release. I re-cited a potential client visit a couple of years back. They told me, that they appeared to have less and less time. I asked them how many bug fixes they release on average per month. 40. And how many new bugs do you get from your users per month on average? 80. I have a good idea why you may find yourself with less and less time at hand.

Ideally, as a long-term perfection goal, we strive to put ourselves in a position where the final regression test before the release is put together will not find any bugs introduced by any of our changes. That’s an aspirational goal, that should infect and guide our thinking with new features we built in. How could this change break some other part of the product? Do we understand the clients of our component and their usage enough, to confidently change this bit?

Of course, there is a learning curve involved here. So, to get that learning started, start with collecting all the bugs that come back from some point down your value chain. Cluster them into categories, and find the biggest cluster. Now ask yourself: How do we need to change our team process to no longer allow such bug fixes introduced into our product piece? That should give you a starting point. Once you dealt with the biggest cluster of problems and implemented team process changes accordingly that work, take a closer look at the next biggest cluster. And so forth. You potentially want to restart the collection of bugs your process still allows you to build into your product.

Avoid branching in your version control system

Another problem I heard there was the extensive use of branching for every new component version. Based on personal experience, I would avoid branching at all. Instead, tag a released version in your version control system, and continue working on the head of the code repository all the time. ideally, the head of your version control system should be able to provide a working release more than once per day. Again, that might be an aspirational goal for you, depending on where you start. If you need to fix a particular bug in a particular release, branch from the release tag, and create a patch, that can then be merged to other versions as well.

Back in my days, I mostly used subversion for this, and I use the term “branching” in the subversion meaning here. The similarities to git which is widespread today, are not that direct, since git comes with at least one other meaning of branching.

If my old brain recalls correctly I initially got aware of all of these techniques by James Shore in his Art of Agile Development book. It’s out now in its second edition. I haven’t read it. Based on my 1st edition read, though, I wholeheartedly can recommend even the second edition regardless. (i need to catch up with my backlog of books on the shelf.)

Remembering Jerry: An Introduction to General Systems Thinking

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, I picked An Introduction to General Systems Thinking in its 25th-anniversary edition published by Dorset House Publishing in 2001, the original being published in 1975.

Looking back, it’s hard for me to remember all the lessons in this book. I recall my main takeaway being that it’s futile to try to understand general systems, you can only understand specific systems. But maybe my recollection is fooling me here since I read QSM Volume 1, Peter Senge’s Fifth Discipline, and Donella Meadows Thinking in Systems since then. So, let me go through the table of contents to help my aging memories.

The book comes in seven parts, or chapters if you like to call it that way:

The ProblemThe ApproachSystem and IllusionInterpreting ObservationsBreaking Down ObservationsDescribing BehaviorSome Systems Questions

I notice how the first sub-heading in the first chapter is called The Complexity of the World. There, in 1975, Jerry already became aware of the ever-emerging complexity of the world. An argument that’s still floating around about 50 years later.

Over the years, Jerry’s writing style somewhat developed. While at the time of Quality Software Management he put a list of laws in the back of his books, this one was written before that. Though, at the end of every chapter, I find a collection of deeper thoughts for the reader to reprocess the whole chapter while reflecting on the answers to the questions.

In An Introduction to General Systems Thinking, Jerry also proves his thinking points mathematically by modeling the laws throughout the book. At times, this was a bit complicated to follow along, though I think Jerry did a good job there. May this be a warning to the mathematically challenged readers out there.

Going further through the Table of contents, I notice there appears to be one law in nearly each of the chapters. Let me conclude this blog entry by pulling the Laws and Principles out from there:

Chapter 1 – The Problem
The Law of Medium Numbers (page 20)
For medium number systems, we can expect that large fluctuations, irregularities, and discrepancy with any theory will occur more or less regularly.
or, as Jerry points out in the text, it eventually becomes Murphy’s Law
Anything that can happen, will happen.

Chapter 2 – The Approach
The First Law of Thermodynamics (page 39)
Total energy in a system is constant.

When the facts contradict the law, reject the facts or change the definition, but never throw away the law. (page 41)

The Law of Conservation of Energy (page 41)
It is impossible to build a perpetual-motion machine.

The Law of Happy Particularities (page 42)
Any general law must have at least two specific applications.

The Law of Unhappy Peculiarities (page 42)
Any general law is bound to have at least two exceptions
or
If you never say anything wrong, you never say anything.

The Composition Law (page 43)
The whole is more than the sum of its parts.

The Decomposition Law (page 43)
The part is more than a fraction of the whole.

Chapter 3 – System and Illusion
The Banana Principle (page 55)
Heuristic devices don’t tell you when to stop.

The Principle of Indifference (page 72)
Laws should not depend on a particular choice of notation.

Chapter 4 – Interpreting Observations
The Eye-Brain Law (page 96)
To a certain extent, mental power can compensate for observational weakness.
To a certain extent, observational power can compensate for mental weakness.

The Generalized Thermodynamic Law (page 99)I
More probable states are more likely to be observed than less probable states, unless specific constraints exist to keep them from occurring.
reframed (page 100)
The things we see more frequently are more frequent:
1. because there is some physical reason to favor certain states (The First Law)
or
2. because there is some mental reason (the Second Law)

The Lump Law (page 105)
If we want to learn anything, we mustn’t try to learn everything.

The Generalized Law of Complementarity (page 120)
Any two points of view are complementary.

Chapter 5 – Breaking Down Observations
The Principle of Difference (page 140)
Laws should not depend on a particular choice of symbols, but they usually do.

The Axium of Experience (page 141)
The future will be like the past, because, in the past, the future was like the past.

The Invariance Principle (page 154)
With respect to any given property, there are those transformations that preserve it and those that do not preserve it.
or
With respect to a given transformation, there are those properties that are preserved by it and those that are not.
or (page 155)
We understand change only by observing what remains invariant, and permanence only by what is transformed.

The Perfect Systems Law (page 160)
True systems properties cannot be investigated.

The Strong Connection Law (page 161)
Systems, on the average, are more tightly connected than the average.
or (page 162)
A system is a collection of parts, no one of which can be changed.
or
In systems, all other things are rarely equal.

Chapter 6 – Describing Behavior
The Picture Principle (page 189)
When speaking about a dimensional reduction, insert the words “a picture of” in whatever you were about to say.

The Diachronic Principle (page 190)
If a line of behavior crosses itself, then either
1. the system is not state determined
or
2. we are viewing a projection – an incomplete view.

The Synchronic Principle (page 190)
If two systems occupy the same position in the state same space at the same time, then the space is underdimensioned, that is, the view is incomplete.

Count-to-Three Principle (page 196)
If you cannot think of three ways of abusing a tool, you do not understand how to use it.

The Conservation Law reframed (page 200)
The sum of the variables of this system is a constant.

The First Law of Simpledynamic (page 202)
Endigitry can neither be created nor destroyed.

The Second Law of Simpledynamics (page 202)
Eventropy can never decrease.

The Principle of Indeterminavbility (page 214)
We cannot with certainty< attribute observed constraint either to system or environment.

Chapter 7 – Some Systems Questions
The Systems Triumvirate (page 228)
1. Why do I see what I see?
2. Why do things stay the same?
3. Why do things change?

The Law of Effect (page 251)
Small changes in structure usually lead to small changes in behavior.,
or
Small changes in the white box usually lead to small changes in the black box.

The reversed Law of Effect (page 252)
Small changes in behavior will usually be found to result from small changes in structure.

The Used Car Law (page 254)
1. A system that is doing a good job of regulation need not adapt.
2. A system may adapt in order to simplify its job of regulating.
or (page 256)
1. A way of looking at the world that is not putting excessive stress on an observer need not be changed.
2. A way of looking at the world may be changed to reduce the stress on an observer.

The Deliberate Tester – A reflection

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. In the past weeks, I published all eight chapters here. If you want to catch up on them, here is a list:

Chapter 1: Session-based explorationChapter 2: Facing the Business with AutomationChapter 3: Fallacies and PitfallsChapter 4: The ChallengeChapter 5: Logged InChapter 6: The PresentationChapter 7: Lunch & LearnChapter 8: The first project

Today, I will share my reflection after reading through all of them 11 years later. So, find my thought below.

The Good

I recall writing these little snippets back when I had some great inspiration from the Software Craftsmanship movement and tried to transport all of the fun I sensed for the programmer toward the testing profession. I revisited my personal “falling into testing” history, and how I thought a perfect learning path for my first days would have been like. On that side, I hope to have given some inspirational clues about what might be worthwhile to really teach software testers – well, maybe just ten years back, as the world of tech is evolving so quickly, it seems. I’m glad I managed to find an ok-ish sweet spot between being too vague to not make sense at all, and too specific to age even worse as these eight chapters did.

Basically, we accompanied Peter as he got to know exploratory testing, test automation, and working closely together with programmers. I am still convinced this is a great starting point for anyone in the software testing profession, while these basics have much more to go deeper into. That sort of brings me to the bad part I feel more than ten years down the line.

The Bad

While reading through all the learnings from Peter, I noticed how shallow most of it is. I especially hate many of the dialogues where the conversation goes back and forth, and then out of the blue one person is convinced that the approach of that other person must be right. Maybe ten years later, I have become quite grumpy about it, but I sense that oftentimes we face much more resistance in many of these conversations than I actually showed.

Then, of course, my whole point about Peter’s story was not “how do you fight resistance as a new tester in a company”. I actually just wanted to hint at some of the practices that I had found useful five years into my own career. I think I succeeded sort of on that, yet, many of the conversations, and sometimes technical details could have been more fleshed out to really bring the reader into action. That’s how I feel about it today, more than ten years later.

The Ugly

I am torn at the ugly part I perceive. With the current zeitgeist around gender neutrality, I feel ashamed of how I picked a male character as the main character. On the other hand, I still wouldn’t dare to write about thoughts from a female character as well. So, this is really dragging me. To some extent, I’m happy to have found a good balance of male and female characters in the story itself and break with the pattern of how “most women become testers, most males become programmers” that I saw happening in my first few jobs. So, sort of kudos to that one, I still sense I could have done better on this front.

Overall, I feel ok about it. Not deep enough on most topics, not too fleshed out, and in the more than ten years since I wrote this little story, I learned so much more that would make me write a totally different story. It was a fun experiment on how I would write something more narrative rather than just combining different models I had come across. And in my personal writing skill-set, it’s a writing style I became more comfortable with by writing this tiny Deliberate Tester story. Hope you enjoyed some of it as well.

The Causation Fallacy – or how not to design salary systems

Re-visiting so many of Jerry Weinberg’s books in the past couple of weeks has made me realize some lessons I merely had on the back burner in my mind, waiting to be activated. One of these learnings is the Causation Fallacy, best illustrated by this funny video:

The Causation Fallacy
Every effect has a cause… and we can tell which is which.

Quality Software Management Volume 1 – Systems Thinking, page 90

Stick long enough in the business of organizational change, and you will come across at least one instance of this fallacy happening. Laying out the vision for the change, coming up with a change strategy, and listening to people, you start to hear different stories of cause and effect. Sometimes it might happen that you see a pattern of opinions where the effects stem from – and they might be totally wrong, since so many of the voices your hearing fell for the Causation Fallacy, and jumped too early on some conclusion that looks helpful but causes a strain of other, mostly unwanted effects down the line.

Maybe an example would be helpful. So let me pick one from the past of it-agile, the company I still work with. Back in 2011, our CEOs had the problem that we had outgrown the usefulness of annual performance talks with our superiors. We were roughly 30 back then, had literally no hierarchy beyond the CEO level, and scheduling 30 annual personal development talks was impractical, to say the least. We had quarterly tuning days back then, where we talked through some issues in our current organization and came up with experiments for the time after the tuning days. On one of those tuning days, the annual performance talks issue came up. (It wasn’t the only thing we dealt with back then, but one major experiment relevant to the Causation fallacy came up related to this.)

We sat down, talked, designed, experimented, and came up with the concept of a peer group. Basically, every employer could pick three to four other colleagues to help them advance in their personal careers. The idea was to go through a couple of categories and see that this person grew over time. Peer groups were allowed to change over time, so if you find yourself at one client today with some colleagues, you probably pick them as part of your peer group, and if you find yourself with totally different colleagues at another client in 6 months, you probably want to switch some members in your peer group to reflect that situation while getting you more first-hand feedback opportunity from someone who has seen you do the work, rather than speculating about it. Not everyone was forced to pick a group of peers, so it was voluntary. The tuning days concluded with this experiment, and the plan was to encourage everyone to pick a peer group in the next six to twelve months.

Later on, this experiment was extended. Since the annual performance talks also included decisions about salary, the CEOs were still lost on how to put those decisions on more shoulders. Deciding upon salary increases then also became part of the peer group’s job. Our salaries were mostly adjusted every six months, based upon decisions from the peer groups if you had picked one. One year into this we came to the realization, that most of the peer groups only met right before a salary decision was due with no personal development talk in between. Clearly, we had missed the purpose of why we invented peer groups to start with.

A later improvement separated salary decisions and personal development from each other to fix the system. In hindsight, everything might be explainable by the experiences you make. You can’t always tell apart cause and effect. And as our little story shows us, some good intentions can actually cause more problems than is helpful or intended.

I think there is a corollary here to discover as well. Human tendency probably is to then think this through harder, deeper, and so on. I think the contrary is more helpful. Start with a small experiment, observe the effects, and over time fix the system, but be prepared that your first experiment will be far from perfect, and you might cause many more problems if kept unaware. We eventually did this with our salary process but didn’t pay too much attention to the dynamics as they unfold at the time. The imperfection shouldn’t keep you from trying, though. Just be prepared and pay attention as the underlying dynamics unfold in real-time.

And, yeah, sometimes this leads to situations where some people say in hindsight, they could have warned about the effects beforehand. But unless they fall on prosperous grounds, they will not stick with the whole group as change happens one person at a time. But maybe there is a lesson in here for some later blog entry.

Remembering Jerry: Quality Software Management Volume 4 – Anticipating Change

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

Quality-Software-ManagementDownload

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.

The Deliberate Tester – Chapter 8: The First Project

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. Today, Peter gets on his first real project. In case you want to catch up with the previous parts, I published these ones earlier:

Chapter 1: Session-based explorationChapter 2: Facing the Business with AutomationChapter 3: Fallacies and PitfallsChapter 4: The ChallengeChapter 5: Logged InChapter 6: The PresentationChapter 7: Lunch & LearnThe Deliberate TesterChapter 8: The First Project

Peter enters Eric’s office right after the Lunch & Learn.
 “Peter, I got another challenge for you.”
 “Oh, a challenge like the login functionality?”
 “No, we got a new customer, and I would like you to lead testing on the project.”
 “What?”
 “Listen, Peter, you have mastered your first challenge quite well, you amazed most of the others in the company. We would like to show our appreciation for your progress with an assignment to a new project on your own. I think you’re capable of doing this.”
 “Oh, thank you, but what if I…”
“Of course, you will get full support from your colleagues on this.”
 “When does it start? What should I do?”
 “Let me give you some answers on this. The customer is Important Corp. They asked us to develop a product for them. Mike is managing this larger project. He will give you details on who to talk to in order to get more information. The project is currently getting set up, so I would ask you to finish what you began, and start working on it by the beginning of next week.”
 “Great, I will get in touch with Mike then.”

As Peter enters the meeting room for the kick‑off meeting, he feels a bit uncertain. Mike and one or two representatives from Important Corp. are waiting for him to join them.
 “Hi, Peter. Nice to have you on this project. Let me introduce you to Stella and Caesar. Stella is the subject‑matter expert for this project, while Caesar will help us with the infrastructure at the customer site. Stella, Caesar, this is Peter, the test responsible from our side.”
 “Hi, Peter, nice to meet you.”
 “Hi, Peter.”
 “Hi, Stella and Caesar. There are actually some questions, that I would like to get some answers to.”
 “Exactly that is why we got together here, Peter. “
 “Yes, also we would like to see your test strategy for the project, …”
 “Sure, Caesar, but please let’s stick to the agenda for this meeting. This point will be discussed later. Now, after we introduced ourselves, let’s try to reach a shared understanding of the project.”
 Stella and Caesar explain what the project will be about. Important Corp. has an old legacy system that they stopped to trust as any change to the system seems to break some unrelated part of it. In addition, the old system is too unstable, and adaptations to the system get too often in the way of the fast‑paced business model of Important Corp. After some brief explanations about the vision of the new application, the discussion reaches the point where the test strategy shall be discussed.
 “Now, as we continue to share our vision about the project, Peter, do you have an idea how we could make sure to deliver the right product?”
 “Oh, I got lots of ideas, but I think we should strive for an emergent solution. Your business seems to be fast‑paced, and we surely need to keep up with the changes that your business will force on the product. How was the last product developed?”
 “Oh, the other company that developed it for us told us they were using defined processes. Their company was certified with ISO and CMMi, and this would surely help in this regard. Then they asked us to describe the system that they would deliver in 6 months. Of course, things changed in the meantime, and over time we had to wait longer and longer for changes in the system.
 “Now, this doesn’t sound too well. Now, here is a thing, I would like to try out ‑ with your buy‑in of course. I recently read about something called “Specification Workshops” and how teams reach a common understanding of the next few items on their list to be developed.”
 “Oh, we attended one of those, too. It started right at the beginning of the project when we needed to discuss what the software should be doing. It still didn’t help, though.”
 “Right, but we will limit the scope of our discussion to one or two months of up‑coming features. Of course depending on your time and availability.”
 “So often? But we can’t set time aside for a whole week each month.”
 “Oh, I see a misunderstanding here. Our Specification Workshops will be held more frequently, but more timely to the implementation of the new features. In addition, these will last only a few hours.”
 “Ah, I think I got it now, and I think we could get this scheduled.”
 “Now, during the meetings, we will take a short list of upcoming features. We will discuss what this feature is about, and try to note down examples of the functionality. Then, while implementing the feature, we will use the examples from the workshops as a stepping stone, and automate them as acceptance tests, which will be running continuously throughout the life of the product.”
 “This sounds neat. But we are not so technical. How can we make sure that the right examples are automated? You know, I read an automated test once, but I couldn’t understand them.”
 “Of course, while automating the tests, we will take care to automate the examples as literally as possible. Since we sit together during the identification of reasonable examples, we will be trying to express them in a reasonable way, so that automation later will be easier, but you will still be able to read them.”
 “Hmmm, but can we trust what you automated? Who will test the tests?”
 “The automated examples will just serve as a stepping stone. We will add more tests to these examples, and therefore further refine the specification we initially agree upon. Additionally, we will test our automation code as well. And from time to time we may invite you to a stakeholder demonstration, and evaluation of the functionality.”
 “Oh, a demo? I know these, they’re just faked.”
 “Not really, as we will operate the real system, and you may also get some hands on the application if you’d like to.”
 “Oh, we may play with the application as well? That’s interesting. Your ideas sound nice, and I think we could work like this. Let’s try this out.”
 “Yes, that sounds like a workable strategy. Let’s settle this as today’s result, and schedule a follow‑up to get the first set of scope and discuss it in one of these ‘Specification Workshops’.”
 “So, let’s check our schedules, and find a date…”

The project takes off very well. After one or two iterations Peter’s team gets in some trouble but is able to work out of it. The team delivers their first version right on the scheduled date and receives another order from Important Corp.

Agile Songs – Hymn

Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, I crossed Hymn from Edguy, and found some Agile adaptation to its lyrics.

(original lyrics)

Give us this day all that you showed me [in the refinement]
The faith and the glory, till my [Sprint] Review comes
Give us this day all that you showed me [in the refinement]
The value and the glory, till my [Sprint] Review comes
Give me all the stories you told me
The value and the glory till my [Sprint] Review comes

When they say that in our time
All that’s good will fall from grace
Even users would turn their face
In our time
And they told us that in our days
Different words said in different ways
Have other meanings from he who says
In our time

Give us this day all that you showed me [in the refinement]
The power and the glory, till my [Sprint] Review comes
Give me all the stories you told me [in the refinement]
The value and the glory till my [Sprint] Review comes

And they say that in our time
We would reap from their legacy [code]
We would learn from what they had seen
In our time
And they told us that in our days
We would know what was design of design
We would follow and not defy
In our time

Give us this day all that you showed me [in the refinement]
The power and the glory, till my [Sprint] Review comes

Faithless in faith
We must behold the things we see

Give us this day all that you showed me [in the refinement]
The power and the glory, till my [Sprint] Review comes
Give me all the stories you told me [in the refinement]
The value and the glory till my [Sprint] Review comes

Give us this day all that you showed me [in the refinement]
The power and the glory, till my [Sprint] Review comes
Give me all the stories you told me [in the refinement]
The value and the glory till my [Sprint] Review comes

Give us this day all that you showed me [in the refinement]
The power and the glory, till my [Sprint] Review comes
Give me all the stories you told me [in the refinement]
The value and the glory till my [Sprint] Review comes

Remembering Jerry: Quality Software Management Volume 3 – Congruent Action

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 3 – Congruent Action published by Dorset House Publishing in 1994.

Review on Amazon

A while back, I reviewed this book on Amazon:

In Congruent action, Jerry introduces congruent communication. For any effective communication one has to respect the self-position, the other position, and the context of the communication. When leaving one or all out, you’re going to find yourself in an incongruent communication style. Leaving out the self-position leads to placating behavior, missing the other position leads to blaming, leaving self and other out is a super-reasonable response, and finally leaving all of them out is just an irrelevant coping style.

Additionally, Jerry discusses the Myers-Briggs type indicator system. He introduces the four dimensions in that model. The first of the four letters say something about how I refresh my energy – introverts (I) for seeking self-reflection or extrovert (E) for interacting with people. The second letter describes how I take in information – either by facts from the sensation type (S) or by grasping abstract concepts via intuition (N). The third letter says something about how I make meaning – by pure logic in the thinking preference (T) or by grasping the feelings of the humans around me (F). The fourth and last letter states how I prefer to take action – the judging (J) style prefers to settle decisions, while the perceiving (P) style prefers to leave options open. So, as I’m an INTJ, I prefer to take energy from being alone, intuitively grasp abstract concepts, make meaning of them through logical thinking, and prefer to have things settled.

So, a congruent manager should consider their preferences and see the preferences of others using the Myers-Briggs type indicator model. Whenever I am aware that my message was not received correctly by my communication partner, I can take the choice to reflect and maybe present the information in a different format for my audience.

A blast from the past

As with all these reviews in the Quality Software Management series, let’s see what I recall. 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 and Satir’s Self, Other, Context view of a communication that is going on.

Basically, in any communication between two persons, there is the individual self, the communication, the other, and the subject matter or the context that needs to be in place. If the self-position is missing in communication, you end up placating, if you ignore the other position you end up blaming, if the context is missing you end up with loving or hating going on. Jerry also picks on leaving self and other out ending in super reasonable behavior and leaving all self, other, and context out leads to irrelevant communication happening. Time and time again I happen to revisit this communication model, especially when I sense conflict arising between different groups.

Congruent Action was also my first touch point with the Myers-Briggs Type Indicator (MBTI) preferences. Despite diving into all the 16 different nuances, Jerry focuses on the four Keirsey-Bates temperaments of the NT Visionary, the NF Catalyst, the SJ Organizer, and the SP Troubleshooter. I recall knowing about the MBTI as preferences rather than unchangeable helped me during a training early in my early career to see that my communication style was too abstract for one participant that needed details especially to be able to follow me. After realizing that, I changed my communication style, and won him over as a supporter, eventually teaching the others in the room as well.

For congruency, Jerry dives into the aspect of being congruent with yourself, spotting congruent organization, and leading congruent teams as an overall structure throughout the book. I found this a good starting point for forming, leading and dissolving teams especially early in my career – even though other books go way deeper overall into the team aspects.

Another nugget worthwhile mentioning here is the Weinberg Addiction Cycle mentioned in Volume 3. Building on the causal loop diagrams from Volume 1, Jerry explains how addictions usually lead to positive results in the short term while having degenerating effects in the long term. He also points out some examples where this kind of addiction can be found in our organization to the detriment of the quality of the products, and a helpful strategy to overcome that addictive behavior:

Prohibit X (the addictive behavior).Provide an alternative solution (Z), that really works.Soften the short-term pain if necessary, but not with X.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 compiled them into a pdf.)

Quality-Software-ManagementDownload

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.

The Deliberate Tester – Chapter 7: Lunch & Learn

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. Today, April and Peter attend a Testing Dojo at a company Lunch & Learn. In case you want to catch up with the previous parts, I published these ones earlier:

Chapter 1: Session-based explorationChapter 2: Facing the Business with AutomationChapter 3: Fallacies and PitfallsChapter 4: The ChallengeChapter 5: Logged InChapter 6: The PresentationThe Deliberate TesterChapter 7: Lunch & Learn

Peter had just mastered his first challenge as John walks into his office.
 “Peter, we will hold a Lunch & Learn session on Friday at noon.”
 “Lunch & Learn? What’s that?”
 “We’re taking over a meeting room, everybody brings lunch, and we’re going to learn something. This week we’re going to hold a Testing Dojo.”
 “Lunch & Learn? Testing Dojo? This sounds confusing to me.”
 “Oh, don’t bother too much for now. You really should join us. We’re taking our lunch while we’re learning something about testing.”
 “Ok, I got that. But what is a Testing Dojo? Are we going to fight?”
 “No, no, at least not physically. We get together, pick an application to test, and one pair tests it following some mission while the others are watching. Over the course, we will switch pairs several times. Jennifer will provide the mission for Friday.”
 “Ah, now I understand. This sounds interesting. I’ll join you.”
 “Alright, see you Friday at noon then.”

That Friday Peter takes his lunchbox to the meeting room only to see the whole team attending the Testing Dojo.
 “Hi Peter, great to have you with us.”
 “Indeed, Jennifer, I think we may now start. What’s the mission for today?”
 “We are going to use the FCC CUTS VIDS heuristic today. The main mission is to evaluate whether it can guide our testing. The secondary mission is to test google maps with it.”
 “Ok, I think we need some clarifications before we can get going. What’s FCC CUTS VIDS?”
 Jennifer takes a pen and starts to explain the mnemonic on the flipchart.
 “In this mnemonic, each letter stands for a certain aspect we may want to watch out for. So, F stands for Feature, the first C stands for Complexity, the second for Claims of the product, the third C is for Configuration, U is for User of the application, T is for Testability, S is for Scenario. The V is Variability, I is Interoperability, the D stands for Data, and the final S for Structure.”

Feature
Complexity
Claims

Configuration
User
Testability
Scenario

Variability
Interoperability
Data
Structure

Source: Michael Kelly

“Ok, I think we got the picture.”
 “Great. We will run a paired session today, exchanging one tester every ten minutes. So, who’s going to start on this?”
 John and April jump in to test first.
 “As a reminder, I ask the audience to stay quiet until asked directly. You’re ready? Then let’s go.”
 “Ok, April, I think we should give this some thought first. Did you use Google Maps, yet?”
 “Yeah, let’s go over the mnemonic and see where to start.”
 “Sure. Feature, I think there are plenty of these.”
 “You’re right. I think this will be the biggest area to explore. Google Maps does not have much complexity, what about claims about the product?”
 “I don’t know about any. So, we might want to use some time researching this. Ok, configuration, there are some settings.”
 “Sure, we might explore these as well. Users using the application will be hard to simulate that in a short time period.”
 “Testability, hmmm, let’s note this down for later. Scenario, I think we could come up with some good scenarios on testing this.”
 “Indeed, let’s note down variability and interoperability in case we got some time left. Data is interesting, and structure as well.”
 “Ok, let’s start with exploring the features. Let me open the browser.”
 “Let’s start with planning your daily route to work.”
 “Ok, I enter the work address, and seek directions from my home address.”
 “Oh, a list of suggestions pops up while you enter addresses. Let me note this down for further exploration later.”
 “Alright, I can plan a route. Now, say, I want to go here by walking. Ok, this also does look good.”
 “Indeed. What happens, if you plan to go from New York City to Munich, Germany?”
 “Let me try this. Oh, look, it tells me that it could not calculate the directions between New York and Munich.”
 “Is this a problem or not a problem?”
 “I don’t know. Far distances seem to be unsupported. Shall we explore the maximum travel range?”
 “Let me note this down, too. We may get back to it later. Or should we tackle it now?”
 “No, let’s get ahead. Now, what about zooming in on a road? This looks fine with me, but what’s that?”
 “Oh, there seem to be some images missing when zooming in too fast. Let’s note this down as well.”

Jennifer interrupts the two: “I’m sorry, but ten minutes are up. John, I would ask you now to go back to the audience, April takes over the keyboard, and we need a new volunteer. Anyone?”
 Peter decides to take the challenge: “I’ll volunteer. Let me take some notes while you test, April.”
 “Alright, it’s April and Peter for the next ten minutes.”
 “Ok, you were touring the features. How much time should we spend with it?”
 “I think we should give it some more time, and then go to the next topic. We got mostly all the features of Google Maps covered.”
 “Ok, what do you think about Streetview?”
 “Oh, we didn’t take a closer look there. Let’s try.”
 “When you drop the Pegman to the map, you can see where Streetview images are available.”
 “Yeah, let’s see if they got images from our company building.”
 “Oh, look, nice. Now, let’s walk down the streets. Ok, this works, too. Though the interface needs getting used to.”
 “Noted down. Let’s see where we could go to lunch today.”
 “You mean we should search for locations nearby? Let’s try that.”
 “Oh, it lists up some restaurants here.”
 “Yes, you were right.”

The team continues following the heuristic to test Google Maps. They switch the pairing partners every ten minutes. In the end, Jennifer calls for a short reflection.
 “Alright, our mission today was to learn about a different approach to testing. Did the FCC CUTS VIDS heuristics help to guide our testing today? What do you think?”
 “Sure, though there didn’t seem to be anything new. It was interesting to focus on generating ideas for a particular topic.”
 “Yes, you’re right on this, John. I think we could have taken some more time initially to set up a brief charter and pick particular goals for test coverage.”
 “Do you think we should use this heuristic to guide our testing?”
 “Absolutely, we might try it out over the next few iterations and see how it can help.”
 “Yes, I agree, it seems useful. but a simple session does not provide enough information about its limitations. Let’s try it out for some time, and reflect on the benefits during our retrospectives.”
 “Thanks, Jennifer for providing this mission. It was a great session. Now, let’s get back to work.”

Software – Craft or Engineering?

The other day, someone on the Crafters’ slack posted a video where someone argued about software craft vs. engineering and asked for opinions from the community. Let’s elaborate on my reaction to watching that video.

Just in case you want to see the original video for yourself, here you go:

Software Craftsmanship vs. Software Engineering by the Continuous Delivery channel on Youtube

Go ahead, I will stay with my thoughts until you watched it.

Edsger W. Dijkstra

First things first. In the video, the author references Edsger Dijkstra yet fails to point to a more relevant piece from Dijkstra for the topic of Software Craft. I recall lots of discussions on the Software Craftsmanship mailing list late in 2008 and early in 2009 when the movement started to take shape. The piece discussed heavily back then was On the cruelty of really teaching computing science authored in 1988.

Dijkstra’s main point here is how universities are good at producing scientists, not necessarily good software developers. Companies in the software field, however, are looking for more software developers, not scientists.

Pete McBreen tried to come up with an answer to this problem described by Dijkstra. Actually, he wrote the book Software Craftsmanship – A new imperative as a reaction to this to solve the basic education problem for good software crafters. This book motivated Uncle Bob Martin to take on his son Micah Martin as an apprentice and prepare him for the software development field. Micah Martin later on founded 8thLight in Chicago on the premise of taking on new apprentices and helping them in their journey to become journeymen and maybe eventually masters in the field. Some of the early discussions that led to the Software Craftsmanship movement were taking place in 2008 at the 8thLight offices in Chicago, and in 2009 8thLight swapped some of their crafters with crafters from Obtiva, also located in Chicago.

Having been around for a while, I notice how this important part of the early motivation for Software Craftsmanship seems to have been lost to time. As the video author states while picking on the Software Craftsmanship manifesto, nowadays craft seems to revolve around “well-crafted code” and what the next shiny thing in the technical sphere might be to hunt after, or the next best way to test-drive your development.

Instead, the author picks on the results of the discussions we had when thinking about the Agile manifesto and the value pairs represented in it. Of course, value statements can be misguiding, as they are seldomly actionable on their own, and subject to interpretation for the reader. Or as Michael Bolton extended on an earlier Jerry Weinberg statement:

For any abstract X, X is X to some person, at some time.

Watching the video author arguing about the manifesto appears to be a weak argument here to me. In fact, back in the day we were fully aware of this fact and started to discuss our equivalent for the twelve more guiding principles behind the Agile manifesto. To recite them from my earlier treasures of Software Craftsmanship entry:

We Care
We consider it our responsibility
  to gain the trust of the businesses we serve;
    therefore, we
      take our customer’s problems as seriously as they do and
      stake our reputation on the quality of the work we produce.

We Practice
We consider it our responsibility
  to write code that is defect-free, proven, readable, understandable and malleable;
    therefore, we
      follow our chosen practices meticulously even under pressure and
      practice our techniques regularly.

We Learn
We consider it our responsibility
  to hone our craft in pursuit of mastery;
    therefore, we
      continuously explore new technologies and
      read and study the work of other craftsmen.

We Share
We consider it our responsibility
  to perpetuate the craft of Software;
    therefore, we
      enlist apprentices to learn it and
      actively engage other craftsmen in dialogue and practice.

All of that is not taken into consideration by the video author which makes his whole argument on why crafting is something he would rather not identify himself with a strawman argument for me. I would even claim that he did not get the notion and background of what motivated us back in the day.

Hindsight is 20:20

Looking back nearly 15 years later, I get another clue about what happened back in the day. Uncle Bob Martin held a keynote at the Agile 2008 conference on the forgotten fifth element in the Agile manifesto:

We value craftsmanship over crap.

Later on, that one got refined to “We value Craftsmanship over execution” as for the other value pairs in the Agile manifesto, the right side has some recognized importance, and that obviously does not hold for crap.

As Gojko Adzic describes in his blog entry from the keynote, he could see just this problem happening back then. Visiting the vendor booths at the conference, there was a higher emphasis on things the whole Agile movement did not stand for at all, i.e. the shiniest tool for managing your Sprint Backlog, Agile Project Manager education, and stuff like that.

In hindsight, I would claim that the Agile movement had high influences from the organizational culture in the competency culture of the Schneider model. Around 2008 that competence domination was taken over by more and more people from a control culture background. Uncle Bob Martin sparked a new movement dominated by the competence culture in the Software Craftsmanship movement as a counter-force to the Agile tool-vendor-driven era we were about to enter. By his own experiences, Uncle Bob had trained apprentices for quite a while at the time, and sought to overcome the “at least my work does not stink as much as it used”, or motivate investments into the delivering zone in the Agile Fluency model.

To some extent, it worries me how this early inspiration got lost merely 15 years down the road – of course also thanks to such strawman arguments as made in the video.

The author put Dijkstra in there, yet fails to recognize the motivation for using the craft analogy in Pete McBreen’s book and how it all got started: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html I think the author lacks some important nuances on where it came from. My read in hindsight is to re-focus on competence once the control culture started to more and more dominate the Agile community at large in 2008.

His whole argument is somewhat weak as well. “Engineering” vs. “craft” vs “art” is just using analogy to talk about some things that are similar in other fields, while of course, some things are different. Software development is neither craft nor engineering nor art in all ways you can think of. I think Chris McMahon wrote something similar on Software Testing as well, either in Beautiful Testing or How to reduce the cost of Software Testing. Craft vs. Engineering is a false dichotomy. As the author explains in his video, Engineering supported Margaret Hamilton to gain respect from rocket engineers at the time. Craft helps to solve the problem of educating good software developers. Both pick on some technical nuance to solve a particular problem. Neither is a complete picture on its own of what software development consists of.