Category Archives: Leadership

Technical and personnel leadership

Leadership, Testing

On Attitude

4 Comments

Last week I came across a tweet from James Bach on Twitter:

I break dreams about products, not products.

Since I am currently reading through Quality Software Management – Volume 4: Anticipating Change from Gerald M. Weinberg, I had the Satir Change Model in mind. Jerry cites Virginia Satir there:

It may look like a crisis, but it’s only the end of an illusion.

Adopting the citation from Weinberg, putting it into James Bach’s citation then became the following tweet:

Testers don’t break software, we end illusions about its usefulness.

Alistair Cockburn commented on this with the following:

I liked when a tester said, “My job is to see that once it gets past me, it doesn’t break for anyone else.”

This made me thoughtful. Finally, I realized that I need to put my phrase into context.

What I had in mind with testers ending illusions about software, is the fact, that testers do not put quality into the software just by their work. Tester interactions with the project manager, the business analysts and product owners, the developers and the customer probably end up in high quality software. Often, testers are the messengers of the bad news and might get the blame for their messages, but they shouldn’t. Testers just test the software they get handed and make evaluations about it. We collect the information and our reports maybe let developers fix bugs or make project managers delay product deliveries, but testers don’t create quality, we try to make it transparent. So, my statement is more against the management view on testing as it is prevalent in some organizations nowadays.

On the other hand, what Alistair is referring to is the attitude of a tester at work. Of course, I want to be proud of the job I did and sign for the testing I did. Taking it to the extreme that no one else will find a problem, when I’m finished with the product is a really good attitude. Most good testers I have met had just this attitude. When I have finished testing the product and the manager decides to ship it upon my report, it’s a moment of pride for the work I achieved.

But there is a problem with quality. Quality is time-effective. Software that is perceived to be of high quality, may be of poor quality tomorrow when a competitor delivers a new version of his product and puts my company out of business with it. As a tester, there is little I can do about that. I can communicate about the information I got while interacting with the software. I can communicate about the information that bug fixing seems to take longer and longer, which might indicate Technical Debt. But since I don’t have control over the business schedule, the developers and resources on the project, I cannot decide to do something about it. Instead, I make informations about quality transparent.

Of course, the right attitude for a tester is great, and as I learned the tester Alistair mentioned got promoted several times in the last two decades. But, testing attitude alone does not lead to quality software in itself. On the downside, there are decisions taken for testers and they receive the blame in the end, as Michael Bolton pointed out:

People give testers scripts with explicit steps and observations, then ask /the tester/ “Why didn’t you find that bug?!”

Now, that’s ridiculous!

Leadership, Methodologies, Retrospectives, Testing

Planned conferences in 2010

Leave a comment

Zeger van Hese‘s summary of the Agile Testing Days in 2009 reminded me to write about some of the conferences I plan to attend over the course of this year. And yes, Zeger is right, since it was my first conference presentation back in October, I was very nervous. Thanks again to Gojko Adzic and Mike Scott, who gave me great feedback the evening before during the Oktoberfest took place. On a second note, Zeger attended nearly all the presentations I was also in – despite the tutorial.

That said, I’m going to attend the Agile Testing Days from 4th to 7th of October again. The submissions are still open until end of January, but I think one of my proposals may be selected. Additionally, this year it’s going to be a four day conference. So, I plan to be fully blown afterwards.

Another great conference last year was the Software Craftsmanship Conference in London in early July. Thus far Jason Gorman has not decided upon the programme, but he’s working on the submissions. If I can make it by any means, I will attend again and maybe get one or the other book signed. I don’t plan to submit an own session.

A conference I haven’t visited last year is the XP2010 conference in Trondheim from 1st to 4th of June. I’m not sure whether to participate there. I will make this dependent on whether my submission will be taken.

Last, but not least, I plan for the XP Days Germany, though I haven’t seen any planning for the conference thus far. Last year the conference was great. Personally I had great exchanges with Alistair Cockburn on methodologies, the Agile manifesto, and a possible future for Crystal. That said, I hope to attend the conference and get to know another great keynote speaker there, hopefully.

Leadership, Software Craft, Testing

Patterns for Test Automation

Leave a comment

Robert C. Martin brought up a blog entry yesterday called The Polyglot Tester. He argues about the Behavior-driven development style of automated tests the table style encouraged from FIT, Slim, RobotFramework and others. While I’m not going to jump into the discussion which of the existing tools is better, worse or more suitable to do some job, here are some references to patterns for test automation, which I came across.

Continue reading Patterns for Test Automation →
Leadership, Software Craft, Testing

People Learning

2 Comments

Nearly everything in software involves some humans doing the job. Today I got a phone call:

Caller: Do you have some resources for me?
Me: Sorry, I don’t have resources for you here. Just people.

Reflecting back on my university years it’s interesting to notice, that we teach computers to learn just like humans, in order to replace humans by computers. But, while we’re doing so, we treat people like things. In addition most of the time people in the software get treated as resources, who can be sent to some course, get a degree or a certification, come back and know everything – inwards and outwards. Sure, this is how it works, of course. Maybe they will be inventing some injections in the near future. Then people – sorry – resources can be as productive all the time without the need to send them to trainings. Now THAT would be an improvement.

This is not how it’s going to work. Let me try to transport this concept to teaching swimming – one of my leisure activities I need in order to gain work-life balance. When setting up a swimming course like most of the projects I’ve been in to, this would look somehow like the following. In Germany the first certification is the “Seepferdchen” (tiny seahorse). By the time the kids know one to two techniques, are able to swim 25 meters (we use metrics here!) continuously and can jump from the edge of the pool right into the water. They can dive and fetch some rings from 1.2 meters depth (metrics!). That’s it.

Now, this is the basic certification a swimming student needs. By then he has the knowledge how to swim through the pool. Ok, let’s put her on a project – a swimming contest. She made her grade with an A, so we better have her sent to the national swimming competition. Of course she knows how to train for the event. Ready, steady go…. What do you think will happen?

Right, when battling the 100 meters against Michael Phelps or Alexander Poppov or Mark Spitz your kid will drown. Why? Because it lacks practice. It does not know how to swim properly with the resistance from the water. The experience of the water pressure is known to her, but not how to use it for her advantage. In addition the muscles has not been built properly to beat with world class swimmers like the ones I mentioned.

There is a pattern we observe each holiday season. Parents sent their kids to our swimming course, because they are going for two weeks to the sea and the kids need to be able to swim by then. Of course, six weeks are enough for anyone to learn to swim. After telling the parents that we have a waiting list for new kids, they take it disappointed to have to wait for a free place. In the end when the kid gets their certification (remember the seahorse), they take the kid with them for their holidays. Why is this dangerous? The kid has just practiced in a safe environment without waves and without streams. The kid knows how to hold their face above the water for some time, but without having the right condition to do it over time when the waves take them out far to the sea. Basically all that certification says, that the kid is able to do basic swimming without saying anything about the abilities.

I hope I raised the point for practicing far enough by now. In order to survive the waves of the software development projects to come, you need to practice your abilities. You need to train and have your programming and testing muscles being built up right in shape in order to survive the streams of the tar pit (see Brooks’ The Mythical Man Month) of software development projects.

But keep in mind that there is no pattern or schedule for people learning. In fact some kids take more than a year to learn enough to get the seahorse certification, others may be able to do the practices for it in just ten weeks. There is no way to have them scheduled on a certain date, because each kid has their own pre-requisite of moving behavior and familarity with water. Compare two kids. The first one has taken baby-swimming courses right after birth and is very comfortable with the element. The other one has nearly survived a fall into the local pond at age of three. The first one is likely to take a shorter period of time for learning how to swim. The second is more likely to have fears against the element that need to be removed before the kid can get trained on the techniques. So, it’s likely to take a longer period. My considerations are not guarantee, though. (On another note I would be happy if I got told about certain fears before starting to work with the kids sometimes.)

I hope it’s obvious to see the similarity to people learning how to test software or how to develop software. People differ in learning styles and learning speeds, but people learn. The difference is to get the hook on the past experiences of the people good enough for them to take the step beyond that gap to the new models you’re providing. Therefore a good learning approach is to settle for multiple models of your teachings in order to get as many people as possible and make them able to refer to your model as well.

Leadership, Software Craft, Testing

Multiple facets

1 Comment

As a swimming trainer I was taught that I reach some of my students with some exercises, some of my students with some tactile impulses while some others need to be taught the model by showing them my movements. Keeping in mind that “correct” is an interpretation from some human, I don’t think there is one and only one correct path to teach anyone anything. People vary in their ways of getting the hook on something.

That said I don’t believe in the single solution of a training model. I believe that we need multiple ways in our toolset to teach people what we’re actually doing. People perceive some of the lessons we teach them by one or more of the following:

  • formal training classes
  • reading a book
  • failure on the job
  • failure in some save environment like a training session
  • watching an experienced professional doing some work
  • (positive) on-the-job experience

Though we don’t make much use of tactile experiences in the software world as I may need as a swimming trainer, there are multiple facets of learning. Based on cultural aspects and diverse background from people there is multiple responsiveness to certain aspect on software development education. This also holds from my perspective for software testers – and I believe for nearly all jobs.

Over the course of this year I got to learn about Coding Dojos. The arrangement there is to have people from the audience brought in to some time-boxed hands-on experience in a save environment. The second aspect is watching two experienced developers developing code. This arrangement sets up people for various learning facets. The more ways we try to set up the learning, the broader our learning audience will be.

The interesting part here is that people can gain experience while they are work. They can be taught what they may need tomorrow. Since the learning is based on a broad set of tools enabling learning, we make sure to include more people – more people that may need more diverse techniques for learning. The concept behind Coding Dojos is very impressive, and it works.

The question that struck me nearly all year is, “May we use this idea also for training testers?” For quite some time I knew there is some way, but I didn’t know my model about. Then something happened that made it very clear for me. More on this in the next blog entry in this series on learning and education.

Journal, Leadership, Software Craft

My Long Road

1 Comment

Yesterday I finished reading through Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman from Dave Hoover and Adewale Oshineye. Personally I met Ade at the Software Craftsmanship conference in London earlier this year and participated in his session on Mapping personal practices. After I came back I used the format for Personnel development. Since May I have a video from Ade open in my browser tabs on How to walk the long road, which I still haven’t seen, yet. So, just after finishing the book, I decided to describe my personal development as a reflection of the last four years of my life using the pattern language provided in the book. So, here it is.

Continue reading My Long Road →
Leadership, Software Craft

Dial the manifesto

2 Comments

Elisabeth Hendrickson put up a response on Why I defined Agile in terms of results on her blog, which made me thoughtful about the dialogue I had last weekend with Alistair Cockburn on the XP Days Germany. Though a more thorough write-up of the conference from me is still missing, I decided to respond on Elisabeth Hendrickson’s blog entry.

During the Open Space session on Saturday Cockburn introduced to us the use of the value statements in the Agile Manifesto as dials. Overall there are eight dials on the meter to consider:

  • Individuals and interactions
  • processes and tools
  • Working software
  • documentation
  • Customer collaboration
  • contract negotiation
  • Responding to change
  • plan

Based on the particular context we tune the amount of individuals and interactions and the amount of processes and tools. Likewise the remaining six values can be adapted to our particular situation. Indeed, we value all eight mentioned terms. That means that we may sometimes need to create documentation. As Hendrickson pointed out to me at the Agile Testing Days earlier this year, being Agile does not equals being stupid. If there is need to create that thorough documentation so that you can be set-up for the next round in the Cooperative Game, then you better create it – now! On the other hand if you find out that you’re documentation is mostly waste, then you should reflect on how to recude it or get rid of it completely. But you need to consider your particular situation, the project, the customer, the people involved at hand. That is what good coaches do.

The second thing Cockburn pointed out was the fluent up and down among practices, principles and values. During our work we keep on continuously switching from one level of abstraction to another, up and down. Some time ago I thought that this fluent switch among the levels is comparable to skill-set development with Shu-Ha-Ri. The main difference is, that you go through the Shu-Ha-Ri stages when learning a new techique, like TDD or Refactoring or facilitating Retrospectives. When working in an Agile team, you switch quickly between the values like simplicity or responsibility and the practices and principles, like TDD, Refactoring or Emergent Design. From time to time you may adapt and adopt some of your principles, practices or even values. Indeed, the Software Craftsmanship Manifesto is just a result of such a value shift. Giving the Agile values, we have put our new values beneath them. This does not mean that we don’t value the statements from the Agile manifesto, but we found new value statements that we think are worth to consider for the next ten years or so.

Getting back to Elisabeth Hendrickson’s write-up, focussing on the results is essential in all the above. When we loose our focus on resulst, we start to day-dream and seldomly get something productive finished. You can use the dials from the Agile or Software Craftsmanship manifesto to finetune your situation, but do this based on the results you already got. The essential thing here is still reflection. Without reflection I constrain myself to self-blindness and No-Problem-Syndrome thinking. This hinders innovation and improvement in your actual work.

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.