All posts by Markus Gärtner

Leadership

Problem-solving with First-order measurements

Leave a comment

Today I attended a meeting at work, where I noticed a pattern. It was a problem solving meeting. Problem solving in the sense that it was identified where we wanted to get, then identified where we are and between both positions is the problem that needs to be solved.

The target

The pattern I realized is the fact that it seemed to be pretty clear to everyone in that meeting where we wanted to be at. Though where we wanted to be was clear for everyone I suspect in retrospection that we had a shared understanding of this. The target was implicit. No one spoke up where this would be. Personally I think the target was ambigious and therefore not well defined. Recently I read a similar example in Quality Software Management Vol. 2 from Jerry Weinberg. The amibious term in his example was “Quality”. In his example everyone would like to have “Quality”, but he found out about the different understandings of “Quality” by asking control-questions.

The current position

Since there were just weak second-order measurements available and no common understanding of the situation at hand, it was hard to gather where our current position was. There was a lot of speculation. Since we were hit with a problem from our colleagues in a timezone three hours behind ours, we did not have immediate feedback. Instead we had filtered feedback through some emails and through participants who attended the chat the night before. This feedback was filtered, uncomplete and in order to find out the current position the meeting participants where vaguely speculating bringing in their own interpretations about the meetings at hand.

The problem

Overall we did not have a shared understanding of our target, no common understanding of where we were at this very moment. Therefore the problem we had to deal with was a meta-problem. The problem between the position where we wanted to be and where we were was fluent and not-distinguished. Therefore the problem to be solved in that meeting could not be understood and therefore not solved. The problem we had in that meeting had to do with the problem that we failed at the first two steps of problem solving and since this meta-problem was not solved, we could not solve problem.

Solving the meta-problem

In reflection in order to solve the meta-problem here are some alternatives that could have helped:

  • Shift the meeting to a later time, so that our colleagues can give us direct feedback, rather than relying on emails and filtered or biased feedback.
  • Abandon the meeting when you find out the participants are not prepared with the information available at the meeting start. Usually you just need to this once in a learning culture.
  • Have a skilled facilitator, which is prepared and has no hidden agenda. This is difficult to realize in a project, which needs to hit the ground this year in recession times.

When you’re faced with a meta-problem the next time and realize it, pick your favorite from this list.

Agile Testing, Testing

Exploratory Testing – Learning

1 Comment

Over the course of the Agile Testing Days in Berlin I realized why Exploratory Testing works. Personally I found a model from my past, which explains Exploratory Testing based on face-detection systems. After some initial feedback I decided to break it in three different posts: Learning, Scanning and the Differences. I will start with the part on Learning.

Continue reading Exploratory Testing – Learning →
Testing

Collective Quality Ownership

Leave a comment

Elisabeth Hendrickson pointed out to me that she recently renamed her seventh practice of Agile testing to Collective Test Ownership. The name is the compartment of the XP practice Collective Code Ownership. Behind it is the value that everyone should be able to change everything if there is a claim to do so. There shall be no human singletons, which are the keepers of the holy grail of your product. This holds for the code that will be compiled and shipped as well as for the tests for that code. If a user story affects existing tests, the tests should be able to change – probably after discussing it with the product owner or using The Power of Three to decide about a failing acceptance-test.

However, I see another collective thing that Agile adresses very well: Collective Quality Ownership. What’s that? Collective Quality Ownership means that everyone has the responsibility to hold the line at the occurrence of a quality problem. Everybode on the team has the right and the responsibility to get to that problem, fix it, and get back to speed. XP practices like Continuous Integration and Collective Code Ownership are just some examples of it. In a waterfall environment where everyone is playing hot potatoe you will realize that there is a lack of Collective Quality thinking. If there is a problem, then someone to blame for this is identified and the hot potatoe is handed over to the next. In the end after months of passing the potatoe around, the problem is still there, and a lot of time has been wasted to pass the problem around, but not to address and fix it right here, right now.

Why do I think that this is important? Collective Quality Ownership is part of several parts in our development live. Each time a bug gets filed, ask yourself how much does this new bug contribute to fixing the problem? When testers hide in their cubicles, getting code thrown over the silo wall, throwing bugs back, then the problems are not addressed. Such a system is not optimized for fixing the problems, for solving the problems, but for identifying problems and for throwing them around. Time is spent in information hiding, time is spent for passing the next potatoe getting passed to own-self and too few time is actually spent at solving problems.

On the other hand Collective Quality Ownership calls out that everyone is responsible for delivering quality to their customer. What is quality? The famous quote from Jerry Weinberg here is

Quality means value to some person.

Quality may mean value to your customer, quality may mean value to your stakeholders within your company. If you see a problem that their very quality perception of the product may disturb, you have the right and the responsibility to fix it. Now, do it. Don’t pass the potatoe. It’s your responsibility. Don’t be blocked by the problem, don’t play the victim role here. If it’s an area which you’re not familiar with, you can always find someone to pair with you on it who is capable of it. In the end you may find out that you learned something and then be able to fix the problem yourself the next time. But you have to address the problem. Now. So, do it!