Skip to content

Markus Gaertner (
Syndicate content
Software Testing, Craftsmanship, Leadership and beyond
Updated: 6 hours 14 min ago

The generalizing cook

Tue, 04/01/2014 - 18:07

The agile community is full of stuff on generalists. Ideally, you should be able to juggle coffees for your developers while riding a one-wheeler, and playing the guitar to “Master of Puppets” from Metallica at the same time. Oh, and you really should have found that bug while doing all that.

That’s a task close to impossible. Let’s take a step back, and take a look into another field of work: cooking. How do you react to generalists there? Let’s see.

Caution: Before reading on, make sure, you had enough to eat. (Or didn’t, depending on how fast you can get weak.) This blog post includes references to lots of yummy meals, and contains itself 2000 kcal.

Cooking specialists?

Before we can define generalization successfully in the cooking field, we need to be able to identify possible directions of specialism. Generalizing is a relationship that cannot exist without specialization. In order to generalize, you have to define the opposite specialities first. Generalization then becomes the movement away from one particular speciality towards at first two, then maybe three, and on the other extreme all the specialities that you can identify in the according field of work.

For cooking, there are several ways you can think about specialization. You may specialize in green, or veggie foods. You may specialize as meat-only cook, or even become a beef master. You can specialize in cooking just with the oven, or focus on grilling activities (may favorite). Consider a cook that is proficient with the barbecue grill to properly prepare a cake with it besides serving you the steak first. Awesome! A meaty cake. I would love that one.

But let’s consider some alternatives. There are cooks in the high pricing segment, like five-star cooks. There are fast food chains that provide you meals with fewer turn-over costs (and other different qualities).

But there’s more. There are cooks that focus on local specialities. There are cooks for the German kitchen, serving bratwurst, haxen, and sauerkraut. Then there are Italian cooks that can serve pizza, pasta, and other specialities from the South-European country. Oh, and don’t forget about the Japanese food. If you’ve ever been to a Japanese steakhouse, you know what I mean. (I should certainly find one in Germany.)

Oh, and then there are cooks that specialize on a particular piece of the whole course. For example there are specialists at creating dessert, like an ice-cake (yummy!). And there are specialists for soup, for salad, and main dishes.

As you can see, there is a whole bunch of stuff that you may focus on. Now, let’s take the counter-position, and see where generalization would lead us to.

Generalizing cooks

How could a cook generalize? When considering the five-star cook, she is probably already generalizing. She knows a couple of dish well enough to receive the five-star certification. For the certifier it does not matter where these dish come from. They only need to be yummy, well prepared, well served.

Or should a cook generalize in the sense of dish he serves? A cook that’s only good at meat probably won’t win many prices in the long run. To prepare a proper meal, he also needs to serve the openers, and he also should have a clue about the composition of the whole course, like which wine to serve with the deer, and what kind of dessert fits better: ice cream or fruits?

Then what about the fast food cook versus the noble restaurant cook? The fast food cook knows a bunch of recipes, and he has streamlined his whole business according to his margins – and what people are willing to pay for it. In a noble restaurant people eat because they want to taste something special. Only the best ingredients get into each individual meal, and that also has an end result on the price. And of course, the overall experience in a five-star restaurant is totally different than the one in the next local Wendy’s.

Oh, and if you can’t get a dessert at the local shop, then you are probably going to the next ice-cream shop, and spend your money there. That might be ok in certain regions of the city. But if the next ice-cream bar is 20 miles away, your customers are more likely to complain about it.

And, finally, you may generalize across country specialities. Besides burgers you may serve sushi, paella, and Irish Stew. You are so proficient in your cooking skills that you can serve all meals from all over the world. 120 meals in your whole menu.

One cook to rule them all

The other day, when I stood in a fast food shop in our home town, waiting for our lunch, I started wondering. That shop sold Döner, Pizza, and a couple of German and Austrian dishes. That shop appeared to be a generalizing shop.

As a customer, did I like it? I started to wonder whether they followed the demand from the market, or tried to fill a particular niche in the local market by offering everything. I certainly wasn’t convinced that many of the offered dish were good while waiting in that shop.

Now, after writing about this experience, I think there is a tremendous difference between a five-star generalist cook, and a generalizing fast food cook. I trust the five-star cook on another level than I trust the tiny small “Fetthalle” around that corner that serves lots of different international foods. I prefer to be more like a five-star software developer rather than a generalizing “fast code” hacker.

That made me wonder what the outside impression from us software generalists would be? Should we be more like generalizing fast food cooks or like five-star cooks in the end? Well, in the end, software development has only to do with stuff you can’t see – if you won’t take a look. Food is different.


PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

On writing blog entries

Wed, 03/26/2014 - 09:00

On Sunday, while writing the blog entry for Monday, I tweeted (or is that ‘twoted’?):

One of these days I’m going to write a blog entry on how I write blog entries. You are going to be surprised.

That cliffhanger triggered some responses from people that wanted to know more. So, I took the writing process of my Tuesday’s blog entry as an example to describe the process of me writing a blog entry.

I hope you are not going to hate me after reading this.

The writing process

I am going to deliver the process with timestamps so that you can get an impression on how I write these 1000 words blog entries. We’ll start in the beginning, and that starts with picking an idea.


I take a closer look into my notes to pick a topic. I have a bunch of topics that I want to write about. Here is the current list:

  • Working Effectively with Legacy Tests
  • Task Switching in Automation
  • Short-term vs. Long-term
  • Where tool vendors succeed, and test automation fails
  • Test This: Train restaurant
  • social density and approaches to slack

As topic, I pick the first one as there appears to be the highest energy in my writing. So, I get down the structure with the title in place, tags, and category down. I then try to come up with the first paragraph. The thought and flow is still not there for me to start, so I take a nip from my beer, and decide to read yammer, mails, twitter, and maybe waste some time on facebook.

I finally begin some writing after learning that scientists found out how to explode cancer, raising life expectations of some mice from 30 to 80 days.

I got the introduction down. Three paragraphs. Now, I am going to outline the structure. I think there will be a couple of sub-headings, so I start with four h1-tags, and filling them piece by piece.

I write down the final paragraph, the conclusion first. That’s usually the thought that has the most of my energy, and I want to have that out of my way right now.

My beer is empty, let’s get another one from the hotel reception.

Beer filled in. What’s new on the internets?

While registering for the SoCraMOB 2014.2, I noticed that the information about what I wanted to learn was nowhere used again. I asked for that on the dedicated mailing list. Word count on blog entry: 221 words.

First chapter finished. Now, I have written down 467 words. I defined the term Legacy Tests, as I see it, and introduced the three patterns that I want to talk about. I laid out the structure for the remaining blog entry. My energy is high for the content, so after a nip from my beer, I continue.

Finished the second part, how to overcome red tests. That was rather a long paragraph. I am now up to 853 words. I think this is going to be a longer blog entry. Maybe 1200 words in the end, let’s see.

Oh, a new notification on twitter, let’s see what that is.

Responded to two mails, read three, read twitter, let’s move on with two more chapters for legacy tests.

Finished the long-running tests part. I feel like I am on writing flow, but my beer is empty. Better get a new one.

Poured the new beer. Checking on wordcount, I am on at 1151 words now. Maybe this is going to be longer than I expected.

Finished the part on blinking tests. Now, I am going to find a headline for the conclusion, and write it down with some closing thoughts.

1487 words, I hit “schedule” for the the next morning. Done.

Taking a step back

Roughly an hour into the blog entry. What can you learn from this? What can I learn from it?

Actually, note that I eventually wrote two blog entries on this evening: the original blog entry, and this one describing it. But how do I deal with blog entries like this?

First of all, I try to collect ideas that I feel passionate about over the day. I get them down as keywords, on paper, on the computer, and pick the idea that strikes me most when I start.

Often I get down a structure of three to five headings that elaborate on the point. I skim down the introduction, and spent some time procrastinating before finding my way into writing-flow.

That’s what I did a couple of years ago during a pattern writer’s workshop. We had 30 minutes to write something – and I spent the first 15 minutes to browse social media like twitter. At the end of the day, Elisabeth Hendrickson told me that she was impressed by the two pages of material that I had produced.

For me, it’s crucial to start with goofing off. These faces help my brain to get familiar with the content that I would like to write about. Only this goofing-off period helps me to get something down, to get into the flow of writing.

I have written before about the fact that I worked as secretary for three sports clubs in my past. I think this helped me a lot. Also chatting on more than 100 IRC channels helped.

A couple of years ago, I read Weinberg on Writing, and his fieldstone method. I find myself not collecting too many fieldstones in the sense of paragraphs that I re-use in articles and blog entries, but instead single phrases that help me get stuff down. I collect these while I am at clients, and note high energy for a particular topic.

That said, how do I deal with longer articles or book chapters? For articles, I mostly need more time, but proceed similarly. For a 2500-5000 word piece, I take 2-4 hours to get that down after an initial sketch of chapters.

For book chapters, I apply the same approach to individual chapters, and get one sub-chapter mostly done in one go.

The only difference between blog entries and articles or book chapters is, that I will deliberately re-read articles and book chapters at least three more times. For blog entries it’s more like a fire-and-forget for me. Maybe that’s why you might experience a lot of typos. But as I said earlier, I don’t care about that output, I care more about the outcomes in blog entries.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Working effectively with legacy tests

Tue, 03/25/2014 - 09:00

A couple of years ago I read a book from Michael Feathers that kept on being mentioned a lot in the literature I was reading then. The title? Working effectively with legacy code. Feathers makes some points on how to get code without tests working, by breaking down dependencies, introducing seams, and working towards more testable code. I loved that book.

When we take the idea of test automation as software development seriously, then there also should be a concept called legacy tests. That concept to me is related to testing debt, a term I think I coined back in 2009. But what are legacy tests? How do they slow down your productivity? And what can we do about it?

Here are some limited experiences I made with a couple of legacy tests, and how to overcome them. I hope this blog entry will trigger some more experience reports from folks, so that fewer teams need to suffer from it.

Legacy Tests

Legacy Tests are automated tests that no one pays attention to. This happens from time to time, and is surely a sign of test automation debt, and probably of test automation failure, that is going to end up as test automation abundance in the long-run if not treated.

The team will lose all faith in the automated tests, and eventually completely ignore them. The side-effects to this are usually that people no longer fix broken build. They then will lose the insights into their progress, and soon enough folks will start to be more conservative about changes to the now untested code. Over time changes will take longer and longer, until completely slowing down the development.

Legacy Tests come in several flavors. At first there will be tests that are constantly red, because the responsible guy has left the company, helping out in a different team, or simply became ill.

Then there are long-running tests. These usually take hours to complete, so they only run over night, and turn red quite often. Since no one is using them effectively for development, there will be less attention to them – and more so less information when they fail.

Finally, I have experiences lots of legacy tests when they start to blink. Blinking tests are tests that run red once, then turn green again, only to fail during the next build. These usually are hard to deal with, and can waste a lot of your time.

Let’s look at each of these patterns, and see how to overcome them.

Overcoming red tests

Red tests are usually the easiest to treat. There is a root cause for having red tests, and a meta-root cause for the root cause.

In most cases, a red tests signals that someone has been unaware about the test so far. Maybe he didn’t execute all the necessary tests before checking their changes in. Maybe they have not been told about that. Maybe there is a team rule missing for that. Maybe during on-boarding a new team member this rule was not mentioned.

No matter what, we need to deal with two aspects of the issue. We need to treat the immediate problem, the red test, and the underlying root cause.

The red tests can either be fixed quickly. In that case, analyze the problem, and fix it. On the other hand, it might be that there is a hard-to-understand test being written. Then it might take longer to fix the underlying problem. I strive to delete the test then, and re-write it from scratch so that it will be easier to understand. Of course, throwing away tests can scare you, but it’s usually the best option that you have when faced with a hard-to-understand test, that only one guy knows. Before investing too much time into the problem, I rather decide to delete the test, and re-writing it from scratch.

But what do you do when you don’t know what it’s supposed to test? Throw it away anyways. It’s of no use to you right now. It’s better to get rid of it. You will face the problem sooner or later. Then you can still write the test from scratch. But also remember that a save assumption is that code without tests is not working.

But how do you decide which is which without investing too much of your time? Well, pick a timebox, say 10 minutes. If you can’t figure the problem by then, either get help, or delete the test if that person is not reachable at the moment. Oh, 10 minutes is too short? Yeah, it’s short, but if it wastes more than 10 minutes of your time to find a problem in your code base, that’s crucial information about the design and architecture of your code base. Nothing a broken test will fix.

Overcoming long-running tests

Long-running tests may eventually lead to red tests. So better get them faster now. What does long-running mean? That depends. For unit tests, I consider a test suite of more than 12 minutes long-running. For acceptance tests my threshold usually is 3 hours. At either of these points I will take a step back and see what I can do about those tests that would make them faster.

xUnit Test Patterns has a lot to say about dealing with long-running tests. It’s usually a combination of tests that exercise too much of the production code, and dealing with slower subsystems. This is usually ok-ish for acceptance tests that seem to have a larger focus, but not so for micro-level unit tests.

You can treat either of the underlying symptoms by mocking out the subsystem in question that is giving you a headache and leading to long-running tests. That usually is a first step. After that you can driver down the test automation towards the level where the actual behavior is tested. Also make sure to reflect over your design here. Maybe you need to fix that as well – introducing new concepts that will help you describe the intended behavior on a more abstract level.

Note that all these tactics introduce new risks. These risks come in the flavor of losing some of your previous confidence. Just because you tested all pieces does not mean that the application is usable. You still need to tackle the situation where individual parts of the application try to speak to each other. So, make sure to deal with the integration of the individually tested components with its own test. Usually though you will need fewer tests for this integration effort if you tested each individual part to a reasonable level. (But don’t rely this.)

Overcoming blinking tests

Blinking tests are the worst of the problems mentioned in this blog entry. Blinking tests may be green at times, and red on totally different times. These usually have a variety of reasons.

Mostly it’s that the initial test writer forgot about a particular piece in the environment that has now changed. For example when the daylight savings time changed, and a test does not run any longer, you might face a blinking test. If a test runs over midnight, and you end up with a problem, then it took into consideration that the duration of the test should never exceed the day boundary.

In all these cases you need to decide whether you want to dive deeper into the root cause of the problem – or simply get rid of the test, and re-write it from scratch. There is a pitfall, though.

The test might blink because the system is unstable. In that case you should fix your system, because if your tests face such instabilities, then likely your users will do so, too.

Delete tests that no longer serve their purpose

Legacy tests are harmful. They can slow you down, make you feel unsafe in the face of producing code that is reliable in the long run. Its impacts will make you feel like slowly boiled frogs that notice the threat only until it’s too late to do something about it.

In either way, automated tests are useless if they can’t provide you with feedback. These days I am quicker to throw away tests that no longer work. I find this has the highest benefit of trust in the development team, as well as having some education side-effects. If your tests is unstable so that I will delete it, then you might turn mad at me. Maybe that madness will drive you to talk to me, so that we can overcome some of the problems that we had.

Legacy Tests should not slow you down. If you find yourself slowed down by constantly needing to pay attention to non-working tests, realize that these no longer fulfill the reason they should be there: to provide you with feedback on your current development status. Delete these kinds of tests, and forget about the sunken costs that went into them. It’s going to be better without these anyways.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Flavors of sunken costs

Mon, 03/24/2014 - 09:00

In his book, Thinking fast and slow, Daniel Kahneman explained the concept of Sunken Costs to me. I found this concept powerful and interesting. But only recently I discovered the many costs that can be sunken. Here’s a brief summary for costs involved in software development.


Sure, when we think about costs, the first thing our culture has started thinking about is money. Money appears to be the dominating way to pay something off. It has become so valuable to us that we see it as a primary driver for cost exchanges.

In software development, calculating how much money you invested is easy. Take the amount of time that people are working on stuff, multiply it with the amount of people involved, and their salary. Voila, you’re done. This calculation is quite easy with agile methodologies that favor a team that is working 100% on stuff.

The amount of money you have put into something influences how you think about it. If there is a project that you have been working on the past four years, you are looking for finishing it off – no matter how. On the other hand, if you are working on something for the second hour, chances are you easily switch to something more fruitful than the 1,000,000th accounting system.

Since money is a so dominating currency when it comes to sunken costs, people will make dysfunctional decision based upon it. For example, Cem Kaner mentions the company where programmers were given higher extra pay if they fixed more bugs. Testers were given higher extra pay if they found more bugs. Virtually there was no software developed anymore – even though that might lead to the company going out of business – and therefore the pay check donator for the employees.


Risks are harder to see sinking in. I think I did a misnomer with risks here, since I wanted to address the mitigation of risks rather than risks themselves. But risks seem to be catchier.

Risks come in a variety. There is technical risks that folks seem to address these days by building spike solutions. There is business which is largely influenced by costs in money, but also by the amount of revenue you get out of it. Then there is social risks. That risks usually comes in several notions on its own. Since people are individuals by themselves, they have pretty different understanding, needs, and challenges to tackle with. Social risks are all part of this.

When it comes to risks and sunken costs, remember that you are mitigating risks while working on stuff. You are delivering a spike solution to address the technical risk. You are addressing the business risks by getting feedback from real customers, and interviewing them for their needs. And you are installing a ScrumMaster or coach to tackle the social risks.

What Kahneman taught me has to do with your decisions based on the experiences level of sunken costs. When you feel that you have already invested 6 months of time into this Agile transition you surely want to see it succeed. When you have already worked with a ScrumMaster for 2 years, you are unlikely to fire that guy if he is effective. If your platform is running on JBoss 7 for 2 years, you are unlikely to move towards WebSphere.

Sunken costs applied to risks leads to different solutions – just like sunken costs in real money. Eventually you can calculate everything down to some money equivalent for the sunken costs, but probably you don’t need to.

And this is where I got the insight that maybe sunken costs are not only about money, but also about less tangible factors. Risks and the mitigation of risks are one of these. But there is a more dominant factor.

Social investments

Social investments happen when you educate your staff. Social investments happens when you hire a new team member. Social costs are less tangible than money costs – unless you only take into account the additional salary. There is a whole lot of stuff going on between team members that eventually should lead to team building effects.

Social costs are less dominating in our minds, but they are real. Consider the up-rising movement of development coaches that help you to shift some of your social investments in another direction. They try to use the social costs that you already invested by team-building towards working together more effectively. Coaches help you reach other levels of insights, and starting the whole team formation again.

Social costs sink in when you introduce a commercial tool, educate everyone, and find out that an open-source alternative would be more effective. That social cost will keep you from moving towards the better alternative, even though it will deliver better results.

But, it’s even worse. Your mind will trick into believing that whatever choice you made was well spent. It will convince you that method X will not work here – since you invested so much into Y. It will convince you that there are so many way method G won’t work here because you trained all the folks in method H.

Sunken costs vs. costs in Euros

Ever since I had that realization I became wary of sunken social costs. These are harder to work with as they may boil down to

  • certifying everyone in your company for certificate X, and then you find out that certificate Y would be better for your working model
  • managers made some mistakes when deciding for application A where application B would have been better
  • personal careers attached to career path I, then the company needs to shift to a careerless model.

Now, here comes the hardest part about this lesson: While you can give numbers to all the monetary investments, it’s hard to measure the social investments in the terms above. The bottom line is this: People will know soon enough that they invested money wrongly, while the social investment might have been right. Nevertheless, people move away from the monetary goal, even though it might contradict the social investment being made.

That is why us consultants should do proper contract negotiation before starting a new client opportunity. The social investment will be high, you know that. The monetary one for your salary will be lower, but the two combined together will still outweigh the introduction of a commercial tool.

Keep that in mind.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

On coaching questions

Fri, 03/21/2014 - 09:00

My blog entry from last week on coaching questions triggered some responses, mainly asking for a definition of a coaching question. I am not good at defining, but maybe at providing examples. Let’s explore the concept of a coaching question with some examples.

The dinner at a conference

Suppose we meet at a conference. It’s late, I ask you whether you would like to join me for dinner. You do.

We chat over stuff. I complain about work, you complain about home, I complain about all my gardening, and that it takes me 1.5 hours to mow the lawn. I also complain a lot about all the renovations that I need to make to our house.

“What have you seen or heard that led you to that conclusion?”

That’s a coaching question.

The peer

I work with a colleague at a client. We visit some teams, different ones, and exchange our thoughts in the evening. One team is doing well, another not so well. There is a conflict in the team. The ScrumMaster leaves the Sprint Retrospectives – upset. My colleague tells me that she had that same situation with that particular ScrumMaster, and there is a conflict between those two persons on that team.

“What have you seen or heard that led you to that conclusion?”

That’s a coaching question.

The personal coach

I have a monthly call with my personal coach. I ring her. She answers. She asks me how I am, and what I would like to talk about today. I start with that difficult situation in that training class two weeks ago, and how that still puzzled me. That attendee of mine reacted so abnormal, and really drove me and the whole class nuts.

“What have you seen or heard that led you to that conclusion?”

That’s a coaching question.

The question

Note, that I tricked you, and provided one example of a coaching question. Also note that I provided contexts for that same question. Whether I consider one of these questions ok with me depends on that context.

In the first situation, we just met. We don’t have any agreement about what you can offer to me, or what I might be offering to you. We are hanging out, probably drinking some beers if it’s after 6pm. By asking the question in such a situation, you are revealing that you see yourself in the position of a coach when it comes to our relationship. We never had that agreement. That coaching question is not ok. God will kill that kitten.

In the second situation, I am out with a colleague. We exchange our thoughts about the client. We work together, and want to reach a shared understanding about various things. In that situation (that I have in mind), that coaching question is not ok. It might be ok, if we had a chat about our relationship at the client, or she asked me to help her reach another level professionally. We didn’t. That question wouldn’t be appropriate.

In the third situation, I worked with the personal since 2011. I pay her to provide me with new insights. We have talked about various things regarding her coaching contract with me. We have talked about lots of things like overloading myself, me experiences with the loss of my parents, my relationship with my family. We worked on the coaching relationship since three years, and I agreed that’s ok with me. That coaching question is ok.

What’s the difference?

Friedemann Schulz von Thun, a German psychologist, came up with a model on communication that is quite similar to Virginia Satir’s. According to Schulz von Thun, there are four elements in every communication message: context, self-revelation, appeal, and the relationship to the one you are communicating with.

According to Schulz von Thun, we not only speak on each of these levels, but also listen on each of these levels. Now, comes the tricky part. If I listen to your message on a different ear than you wanted to speak to me, we will misunderstand each other.

That’s the case in the first situation above. You ask me a question, probably aimed at the context-level. However, I “hear” that message with the co-notation of how you define our relationship. I don’t agree with you on the definition of our relationship. Now, things go awry.

Contrast this with the third situation. We had a chat about the relationship between each other. My personal coach asks me a question with regards to what I perceived. I agree with the relationship message, since we had settled with that coaching contract. I can now focus on the context of the question.

In the second example, the situation may be different. Maybe the colleague is senior to me, does not like to be challenged by a junior, and opposes my message on the relationship level. Maybe my colleague is junior, learns a lot these days, and welcomes that reflection moment.

That might be a coincidence, though, and I better should settle a coaching contract if I observe myself asking lots of these question regularly. At least we should have a conclusion on how we want to learn from each other.

There are alternatives

Finally, consider the alternatives in the situations above. These stem from Schulz von Thun’s model as well.

In the first situation, you could have said: “Sorry, I don’t understand what you are saying. What’s the thing with your house? I think I need more details to support your conclusion.”

That message addresses the self-revaltion part: “I don’t understand what you are saying.” It also addresses the relationship level in another way as the question before. It addresses the context, that is my house being intensive on renovations. Finally, it comes with the appeal that I should define more details so that the other party can share my conclusion.

A similar phrase or approach may be used in all of the other cases. The thing with my opposition to coaching questions is this: if I don’t share your definition of our relationship, things may go bad. That is since coaching questions leave a large room for speculation. “Why is that guy asking that question?” “What’s the context that he needs to have?” “What is your appeal to our communication?”

Maybe, the only thing that I would need in support of the coaching question is the self-revelation part. Please don’t give me a coaching question, but also consider to reveal something of yourself when asking me without permission. Thanks.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Only human

Thu, 03/20/2014 - 09:00

While attending conferences, sometimes some folks approach me. I can sense they are nervous, I can sense that they have some questions to ask, and I can sense that they look up to me – and I always get the impression that I am frightening some of these folks. The bottom line is: all of us “celebrities” are only human. You can contact us, and you can have a chat with us most of the time. Here are some things that I did in the past.


Early in my career, I read a lot of books, blogs, articles, and contributed to a bunch of mailing lists. Whenever I read something, I needed to try that out the next day back in office, and often this helped me to learn more.

Over time I started to reach out to the authors. I remember when I wrote my first mail to Jerry Weinberg after reading Perfect Software. He recommended Quality Software Management to me for understanding the Satir communication model. I provided him some feedback on some of the typos that I found. I did similar things with Kent Beck, James Bach, Lisa Crispin, Janet Gregory, Gojko, and so on.

Usually us authors are very approachable. We like to read stuff that other folks come up with while they read our stuff. We like to hear war stories from folks who tried to implement our ideas, and the experiences they made. These stories help us learn, and see beyond limits. We are very open to discuss questions, and provide feedback, or give out additional thoughts since that will help you as well as us. A classical win-win.

Let me add a disclaimer: So far, I haven’t been overwhelmed with questions in my inbox. That might change at some point. Right now, I usually follow up on emails within a week. If you get in touch with me, those numbers might have changed.


At conferences, you may talk to a lot of folks. Some of them are well-known for their contributions to the field, and might be crowded by lots of folks. Others are not so well known, but maybe maintain a blog that has some pretty good thoughts. I always find it great to put faces to names and writings. So it pays off to get in touch with these folks – at least have a small chat with them, even if it’s just about the weather outside.

At conferences as well as user groups you have the opportunity to get in touch with some great folks. You can directly engage with discussions, and get an answer to your “I ever wanted to ask”-question. Take that opportunity. All of us speakers, and authors like to hear from others, and like to exchange ideas, explain stuff, hang out with folks. Asking someone for dinner options is always a good pick, usually. Besides the celebrities, you can also get in touch with other folks that share their passion – and yours. Over the years, I have met many interesting folks at various conferences.

Early on, I was surprised at conferences when they approached me with “hey, aren’t you the author of I read your blog. I like it.” Most of the times I replied “oh, you’re that guy. Thanks, now I know my only reader.” I then could explain that I keep that blog for my own reflection, and always find it surprising to hear such stories. But honestly, don’t tell me that you read this – ignorance keeps me at writing. :)

Social Media

Nowadays, social media is big. Beyond mails, I like to have chats with folks over skype, over twitter, or just read stuff that is on their minds on facebook. I am bad at following up on forums these days. That’s mostly because I am on the road mostly, and flaky hotel wifi combined with lots of hours on the train don’t combine well enough with online forums.

Usually there is some kind of overlap between these communities. People want to help out, and you will find like-minded people in all the different forums. At times, some of the gurus also contribute, and you can grasp easily some thoughts from them when they do. That’s great.

Get in touch

We’re all humans. We have our great moments, and our bad moments. Sometimes we’re up to capacity, and can’t contribute to stuff, at times we do more of that because we have the bandwidth available.

Guru, or not, we’re all approachable, and connecting on the human level with folks usually is a good starting point. Most of us are here to help.

Finally, I would like to share an experience that I gained from one very large conference last year. There were more than 2000 attendees, and of course also some gurus in that community. Some of them had track sessions.

What I disliked were the various gurus that sat in their hotel rooms – I don’t know what they did there – rather than hanging out in the hallways, chatting with folks, and getting in touch with the folks that try to incorporate their ideas into their working life. Some of these gurus only showed up for the 90 minutes duration of their talks. I found that disappointing to me as a participant since I really wanted to hang out a bit with these folks.

But not all were like that. Some other gurus were always present in the hallways. These folks were approachable, and said hello every morning. When I am attending a conference, I usually see myself as a peer, I want to learn something as well. For that to happen, I need to stay in touch with folks.

In the end, we’re only human.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Learning styles

Wed, 03/19/2014 - 09:00

During DEWT4 I reached the conclusion that there are different learning styles, and they have different levels of effectiveness, at least for me. I think it was Alistair Cockburn that triggered the thought with his model on communication effectiveness. I think there are various levels of learning effectiveness related to Cockburn’s communication effectiveness as well. I think the axes for learning styles are the amount of interactivity, and its effectiveness for the student.


In my past, I received a lot by reading about different models, styles, and models. I learned a lot by engaging with folks afterwards. I also learned a lot by incorporating the thoughts from the books that I read into my daily work.

That said, I think reading about new ideas is a style of self-directed learning that has a role to play. I am heavily engaged with this learning style, and it necessiates a lot of passion, and discipline.

Reading alone does not solve a problem. You still need to incorporate time to deal with the different outside influences. Most of the effective learning will take place while you put down the book, and try to incorporate the various foreign elements that you noticed. At least that has been my experience.

Class-room training

In class-room training, traditional style, there is usually someone that tells you how to do stuff. There is someone that is leading the conversation, and providing you with more directive input. There is still some self-direction involved when it comes to pick the right training course for you; and of course you can reframe and refuse some of the lessons taught to you. The teacher usually does not have a direct feedback when it comes to incorporating the different thoughts into your daily work-life.

Training effectiveness can suffer a bit here when it comes to pick the training course to attend to, and which ideas you are going to follow up on, and try to integrate into your daily life. Usually the trainer will be gone for the integration part, and at times the trainer will also be missing for the selection of ideas to follow up onto. This is unfortunately as so much intangible and tacit knowledge is not transported between the trainer with the experience and the student that should be seeking that knowledge. On the other hand it may work for folks that are able to learn from distinct impulses alone.

Experiential Learning

Rather than having someone tell me what to do in my daily work, there are other training formats rising up right now. Training from the back of the room, simulations, and experiential learning build upon students experiencing how the learning objective translates into their daily business. The learning effectiveness is a different one for these learning styles.

This type of learning has more self-directed elements in it while providing concrete experiences that people can leverage to help them realize which lessons to bring back into their work environment. This kind of learning style uses feedback cycles to help students evaluate for themselves which learning topics bring more value for them, and their companies, at times on several levels of meta.


My current picture is that Coaching helps you realize more things about the topics that you want to improve. It’s highly meta in the way that it helps you to realize the different areas of knowledge that you would like to invest in.

Coaching makes you realizes about all the areas that you could invest time and energy in – and helps you to come with conclusions about which one should be first. Coaching is a style of learning that makes you aware of all the things that you don’t know, yet, and how you could prioritize them. Coaching makes you aware of the right questions to ask to reach that conclusion, and derive the next steps for your self-direct learning next.


Mentoring solves a different problem. While coaching relies to throwing up a bunch of questions, mentoring tries to engage with the answering process a bit more. Mentoring helps to make more directive decisions when it comes to learning fields. Mentoring provides some options here, and provides guidance for the individual learning style, and ties back some feedback about personal preferences.

Some folks refer to mentoring as a life-long learning opportunity for the mentor and the mentee. I think that the intangible outcome lies in more direction towards possible learning goal than coaching provides. When it comes to me personal coach, I learn a lot about models, but not so much about when to apply them. That’s something more suitable for mentoring.

Pick your weapons

Depending on the stuff that you would like to see addresses for your personal learning journey, you should be clear on your goals, and next steps. Based upon that pick the learning style that addresses your personal style best, and helps you receive the best outcome. Thereby you ensure that you get the most out of whatever model you pick as your favorite.

As my father taught me, when finishing your apprenticeship, your learning journey starts. Make sure to know what helps you most based upon your personal style and preference. From there on inspect and adapt. Oh, and enjoy!

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

New names for the quadrants

Tue, 03/18/2014 - 09:00

In the past there have been multiple folks proposing a rename of the famous testing quadrants that Brian Marick wrote up a couple of years ago. Lisa Crispin and Janet Gregory labeled them Q1, Q2, Q3, and Q4 in their Agile Testing book. That naming misleads some folks as they think about a progression in the four quadrants. I recently read something that triggered a thought. I think we should rename these quadrant completely, and drop the counting digit at all. While several other folks have tried to find new names for the quadrants, I came up with a different thought: let’s try to find person names for the quadrants. Here is my first proposal for those.

Technology-facing team support

In this area fall tests that support the team. These are low-level unit tests, as well as some higher-level unit tests that combine for example two different classes that need to work together. GeePaw Hill made me aware when copy-editing my chapter for How to reduce the cost of software testing that these are usually called micro-level tests. These tests shall ensure that the team is building the product right.

This quadrant is a lot developer-centric. Let’s call this quadrant Kent. Kent will develop with other programmers a lot, usually working with TDD and lots of pair programming. Kent will help others, and heavily automate every single design decision that he made so that the whole team is able to remember the choices from today, and have a unintended change detector running in their continuous integration build.

Business-facing team support

Business-facing tests that support the team consist of story level tests. Usually, when using ATDD, these are fully automate during the iteration. These tests shall help the team to see whether they build the right product. Also workflow, use case, and scenario tests fall into this quadrant.

This quadrant combines the business viewpoint on the application together with developer practices. Let’s call this quadrant Ward. Ward will work closely together with business stakeholders, using examples to understand the underlying business rules, and automate them while working on the features. Ward will also include these automated tests into the CI build, and the team heavily relies on these tests while working on the system. At times, Ward works from the examples into the architecture and design of the software.

Business-facing product critique

This quadrant consists of manual and user acceptance tests. These are usually carried out by sapient testers. The tester evaluates the product, and checks for problems in the application – something that does not seem right according to a couple of heuristics that he has in mind.

Tests in this quadrant are usually exercised using an exploratory approach. Let’s call this quadrant James. James will work on short time-boxed sessions of exploratory testing. He has the mission of the team in mind when he exercises the application, and finds crucial problems in the product before it is shipped to the customer. He provides a session charter for each of these sessions, so that he knows when he got too distracted from what he actually wanted to achieve. James also closes the Inspect & Adapt cycle by doing a debriefing with his session notes after each time-boxed session, and reflects with a team colleague about necessary adaptions to the current approach and testing priorities.

Technology-facing product critique

Tests in this quadrant aim at the so called non-functional requirements. Usually these involve special tests like performance, load, and stability tests. The system is exercised under concurrent situation, and needs to prevail the intended target user load.

Tests in this quadrant require special knowledge. Let’s call this quadrant Scott. Scott knows all the performance tweaks that you can take for an application. He know how to fire up load tests that can bring down the system in seconds, and he knows the limitation of different usage loads, and how to reproduce them in a test harness. With his tools, he has super powers that frightens every DevOp, and system operator.

Kent, Ward, James, and Scott

I think with these names, the questions about a good testing strategy on an agile project shifts from fulfilling all the different quadrants – and usually forgetting Q4 tests – towards the different names. Instead of asking how many tests we do in Q1 of the quadrant model, we can ask how much influence Kent should have on our tests. We also start to think whether Ward and James should have equal influence on the overall testing strategy, or whether you want to have a preference for either of them. Oh, and we certainly won’t forget Scott, since Scott needs a whole lot of attention.

We can also shift our conversation when it comes to staffing. Rather than thinking about particular persons, we can ask whether we have enough Scotts on our team. We will also certainly notice whenever we lack some of Ward’s skills, and can directly hire for a person that brings that additional knowledge in.

If you struggle to remember those names, let me reveal my motivations. Since Kent Beck wrote the dominating book on test-driven development, I decided to give the technology-facing quadrant that supports the team the name Kent. In the business-facing quadrant for team support, I put Ward Cunningham, the inventor of the Framework for Integrated Tests, effectively one of the first frameworks to support ATDD. For the quadrant with business-facing tests that critique the product, I was struggling between Cem Kaner, Michael Bolton, and James Bach. I picked James here, since he wrote the most about session-based test management, and Exploratory Testing. Cem and Michael would have been an equal pick, and it was a hard decision. For the technology-facing tests that critique the product, I picked Scott Barber, performance test specialist.

I think these names have the power to change the conversation from a ranking between Q1, Q2, Q3, and Q4 towards the right balance between these four gentlemen.

The only flaw I see in the model stems from the realization that I only picked male names. Reflecting over it, what would be appropriate female pendants? Probably Emily, Liz, Elisabeth, and Mieke. Can you guess which ladies those would be?

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Masters of Disaster and Improvisation

Mon, 03/17/2014 - 09:00

Over the weekend, I came to the conclusion that we humans are masters of disaster, and – at the same time – masters of improvisation. We have the tendency to fix things by putting up signs, by coming up with work-arounds, and often these work-arounds make things better for some people, or worse for other people. Let’s explore this idea, and I hope you have found one instance of this or the other.

On Sunday I went to the gym. I visit that gym for a couple of years now. Right now, Since I joined that gym, the owner changed once. The new owner is investing some money. That comes with annual closing periods of one or two weeks where something gets renewed.

Recently, I saw some notes hang out in the lockers room. They asked us to put the weights back to their place where we picked them after exercising with them. Over the years, I have been to three to four gyms. Maintaining a regular place for the weights has always been an issue. So has the issue of people putting the weights back to their place. In most gyms that I have been to over the years, this always has been a mess, unless there was someone paying attention all day – and few gyms invest that money.

What’s the disaster here, and what’s the improvisation?

The disaster is the mess of weights that people tend to leave behind. In my current gym there are several weights ranging from 12kg to 32kg. There are two benches to put them. Every now and then I spend some time to sort them by weight.

Unfortunately the weights don’t all fit on the available spaces. I surely can understand that putting back the weights after doing some heavy-lifting does not end in the most clever thoughts. So, people put back the weights wherever they feel they would be appropriate. The next guy picks the weight up, and puts them somewhere else. With too few space left for all weights, usually at least one weight ends up on the ground – and this is where it all begins.

Soon, there is another guy that puts two weights on the ground rather than the dedicated benches. Soon enough, there are three, four, five weights on the ground, at times lying over each other. The mess is complete.

Now, what’s the improvisation? Hanging out signs that ask people to put the weights back in their places. The root cause lies in the too short bench. So, rather than getting a bench where all weights may be put on, or removing one pair of weights, or, or, or, people improvise with the immediate solution to put up a sign. Unfortunately this does not result in a change of behavior, so nothing improves, and over time folks become upset because “people should have read the sign”.

That reminded about a video that I saw a while ago.

This is broken

A couple of years ago, Seth Godin delivered an awesome TED talk on all the things that are broken in our daily life.. He collected pictures of everyday situations, and explains that these are broken. He identifies seven kinds of brokenness that he found over the years:

  • Not my job
  • Selfish jerks
  • The world changed
  • I didn’t know
  • I’m not a fish
  • Contradictions
  • Broken on purpose

Godin identifies putting up a sign to fix a broken situation, is an instance of “not my job”. The sign in my gym “is not the solution to the problem”. The problem starts with the bench with too few spaces for the available weights.

With that situation in mind, I noticed that we humans have a tendency to take the easiest way to solve something for. Another instance from the gym is this: I attend a course. As part of that course, we go through some stations. We have 1 minute of exercise, and 30 seconds of rest to change the station. There is a colored light indicating when to go, and when to exercise in green and red light. There are dials to influence the lighting durations.

As I faced today the situation that the change station light was set up too short, I was thinking to put up a sign there that indicates how to tune the dials so that the right amount of time would be available for all course participants all the time, and people could play around with the timings when there wasn’t a course.

But that would also be an instance of “not my job”. Humans have the tendency to trick the system, when we start to understand it. There are many speculation on why the dials are turned. Some trainers are lazy, and put the exercise period up longer so they won’t need to do much stuff in between. Some folks don’t need longer periods of rest, etc. I noticed that I had the tendency to put up a sign to fix the situation. But the fix would also be possible by getting rid of the dials, or working closer together with the trainers to stop tricking the system, and teaching them on which settings the dials should be before starting the course. The note with the correct settings would be an improvisation.

The Fun Theory

The weights, and the dials reminded me about some videos that I saw a while ago. The videos dealt with what is called the Fun Theory. The theory is this: something as simple as fun is the easiest way to change people’s behaviour for the better. There are some pretty good examples on the website about how people achieved that. For example, watch the bottle bank arcade machine or the world’s deepest bin. These experiments lead to a better environment around the devices that were set up simply by making it fun to use them.

When it comes to the weights in the gym, I think rather than putting up a sign, we could also make it fun again to sort them back on their bench. I don’t have an idea on how to do that – that overwhelms my creative power – but I think that this solution could have worked better than the sign.

The broken window, and the boy scouts

Now, think back about your work place. Do you notice the disasters that you create for others? Do you notice the disasters that others create for you? Do you notice the improvisations that you bring in that make it an disaster for others?

Now think about it. How can you apply the fun theory to make solving these kinds of disasters in the future more fun for all of you? For example, continuous integration systems where you win some experience points if you pay down some of the static code analysis remarks. Or if you increase the test coverage level, you receive the unit testing badge.

I think we can still learn lots of things from the gamification domain for our workplaces. Let’s try to re-introduce fun into our tedious daily duties. Maybe we will have fewer broken windows, and leaving the campground a little better than we found it.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Hard(ly) to coach

Fri, 03/14/2014 - 09:00

Over the past few years, I noticed a pattern for myself. Whenever I found myself in a group situation, there is usually this one guy, the one that asks a lot of mystique questions. Do you know that guy? Sometimes there are a couple of them, sometimes there is none, sometimes it’s myself. That mystique guy (or gal) asks a lot of questions that drives you nuts. Within a second I can spot a coaching question coming up. Sometimes I project lots of meaning on why he’s asking that question. I think I developed some kind of resistance to that.

Coaching questions

There are lots of variations of coaching questions out there. Some of them are direct, some of them are less so. Some folks learn them by hard (guilty as charged!), some folks can hide the coaching intention better in their questioning.

I remember a situation where I had a chat with a team that I wanted to join. We sat over lunch break together in order to find out whether we would fit together. “What do you want to achieve?” I remember my reaction. I could directly spot the nature of the question, it was frightening me. I knew I could trick their system by simply providing what I thought they wanted to hear. “To make this world a better place, bring unicorns that vomit unicorns that vomit rainbows, and make everyone dance in heavenly peace.” (or something like that)

I knew if I said that, I couldn’t stand behind that. I knew if I gave an answer like that, I would reach out for a shallow agreement, setting myself up for later disappointment when we found out that we didn’t fit together.

Since a long time, I consider myself hard or even hardly to coach. I can spot those coaching questions on the spot. I can even directly jump to the conclusion about what my other side wants to hear. (Sometimes I am wrong my assumptions.) And I hate that.

I hate those coaching questions not only because I know how to trick their system, I also know that it will defeat their purpose – and that I am bad liar. And I know that I am guilty of asking those questions a lot, too.

I even prepared this picture to indicate my hate.


So, if you happen to ask me a coaching question, be aware that God just killed a kitten. Your fault, sorry.

The Coaching Contract

But wait, there’s more. There are times when I want to be asked coaching questions. That is when I have a direct agreement with someone that I want to take a step back, and see what I can improve. That’s when I reach out for a coach to specifically help me.

The most valuable thing you should be aware of is the coaching contract. When engaging with a coach, we have a chat together about what kind of feedback I am looking for, and what I would like to learn. We take the first steps together. I get used to the type of feedback that I will receive, and how I react to it, and whether I feel ok with that feedback.

All of this is in place because I am deliberately going out of my comfort zone, and I want to have someone guide me out in the wild. I want to avoid the situation where I become upset about the current situation, and I want to feel safe that someone is taking care of the facilitation that needs to happen in order to bring me back. That’s why I settle with a coaching contract.

The problem in the aforementioned situations though is this: we don’t have a coaching contract. In most of these uncontracted coachings, I notice the following happening inside me: “who are you to ask me that question? Do you really want to go down that road with me?” “I don’t trust you to be able to handle the situation when I go off constraints, so don’t ask me that question.”

Of course, most of the times, I can keep myself calm enough to not take it personally (beware of me after 6pm), and navigate through that situation without confrontation. While writing this blog entry, I think that I probably need to challenge the premise that it’s ok to ask me such kind of questions right now.

What to do instead

I can only answer that for myself, but maybe you feel that same. Instead of receiving a coaching question (and I don’t know whether I used the right term here), I would like to have an open conversation. Whenever someone asks me questions like “what do you think about it?”, that’s not telling me what that other person is thinking about it. Whenever someone asks me a question like “What did you see or hear that led you to that conclusion?” I would like to receive “I don’t see how you reached that conclusion. What did you receive as information that you didn’t provide to me?”. And, sometimes I just want to try out stuff, and reflect over it later, rather than up-front to avoid too much speculation.

So, please, whenever you are tempted to ask a coaching question to me, check whether we have an agreement, if we don’t, and you still ask me that question, be prepared to be guilty of God killing a kitten. Yeah, right, it’s you killing the kittens.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Creating good testing challenges

Thu, 03/13/2014 - 09:00

Time and again I run into an ambitious tester that presents me his (or her) latest idea for a testing challenges. “What do you think about this situation where you set out the tester to learn X?” “You could provide product foo to the tester, and have him learn X. What do you think?” Time and again, I think there is something seriously flawed with this approach to create and design testing challenges.

Closed problems

What’s wrong with the examples that I showed? Let’s work through one together. I will think of a number, and you have to find out which one it is.

Ready, ok, let’s go.

No, it’s not 42.

It’s not 666.

It’s not NaN, that’s not a number.

No, it’s even not 31276391861.

You’re there yet? Starting to feel annoyed?

What’s the problem with such testing challenges? There is one true answer to the challenge. This is called a closed problem. Closed problems come with the drawback that there is one right answer, and you will get it quickly if you understand the underlying rules of the system – and you will become annoyed slowly like boiled frogs if you don’t.

Closed problems when given out as testing challenges to apprentices, junior testers, and so on, can come with this notion, there is one true answer. The problem with that is that these are not so much related to the work of testers. When we are working for a client, we are really rarely sent out to find that one bug that the developers hid in the software. Or those ten bugs. Or twenty. The real world usually has more to do with unforeseen problems that we discover. Rikard Edgren was the first to introduce me to the idea of serendipity, and how testers can make their environments work in favor of that.

Another problem with closed problems stems from one factor I consider crucial when it comes to learning. When giving out a testing challenge to someone, it should be something not so closely related to their work, and it should be obvious that they put some of the leisure time in it. That being said, the challenge should be fun to pursue rather than dragging out the energy from the student. The student should feel engaged to solve the puzzle. If there is one right answer and you just need to sort of “get it”, this usually becomes frustrating to most folks pretty quickly because they will feel trapped. Testing challenges should be fun.

Don’t get me wrong, there should be just the right amount of “kicking someone out of the comfort zone” that does not kick them out into the land of frustration. As psychologist Csíkszentmihályi found out, flow happens when the level of challenge meets the skill-level of the student, and does not put them off into the land of anxiety, or boredom. Personally, I can shift with a closed problem from frustration to boredom pretty soon, when I don’t “get it”.

Lessons from Weekend Testing

I remember some early lessons from my time when I co-facilitated a couple of sessions on Weekend Testing. I think it was Ajay who told us that the experimented with setting out traps for the attendees, but found out quickly that such kind of traps were simply not necessary. Testers were already up to creating their own traps.

My training experience tells me that giving out more open problems where there are several “right” solutions to solve the problem, are more demanding on the trainer. You need to design those exercises well for the learning objective. You also need to debrief the activity well enough to provide everyone involved the right amount of feedback so that they can learn and grow from the experience.

That’s what we mostly did during Weekend Testing sessions. While there was one hour of engaged testing in the beginning, testers took the biggest value out of the sessions from the debriefing part. And every trap you set out in the initial challenge usually fired back with ten traps testers set for themselves. At some point we realized that we simply didn’t need the up-front thinking, if testers could do that on their own.

Lessons from Experiential Learning

Ever since I attended PSL, I am aware that experiential learning is different. It goes deeper, and you learn from it whatever you need to take away in your current situation. The learning is context-dependent on the situation of the student.

There is a pitfall involved. If the student is feeling overwhelmed by the learning that you can offer, then he will have a hard time stepping back from the challenge. That said, students needs to be safe to step back from a challenge, and the challenger should be in the position to evaluate the thin line between leaving the comfort zone, and destroying the learning environment of the student.

Also, during the experience, testers should be in a position to play their role fully. They should be able to contribute like they always contribute. In the debriefing of the activity, though, the challenger needs to build the connection from the experience towards daily work.

That is what we somehow achieved in Weekend testing sessions. People were sent out for testing on their own, and we had a debrief afterwards. People that didn’t attend the one hour debriefing later usually were one-timers, while folks engaged in the second part, came back to learn more.

Open problems

What I took away from PSL in particular is that open problems are more fun to solve, and usually reflect the complex reality of our work situation in a better way. Therefore learning is more fun, and it comes with more direct take-aways for your next day at the office.

When designing testing challenges, we should avoid challenges that are too closed, and do not fit the current situation of the student that wants to learn something. If the experience is frustrating, he will not come back to learn more, and instead lose interest in us.

Testing challenges should be open, where we need to observe testers in a similar environment than their work situation, and help them make the connection back for their take-aways. In the end, that will be lots of more work for the challenger, but it will make the student grow more while having more fun.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Where I failed to lead

Wed, 03/12/2014 - 09:00

There is a lot to say about leadership. Personally, I consider it a skill that needs to be honed – and developed. There are lots of bosses in the companies out there that don’t have a clue about leadership – neither do I. I attended a couple of courses on leadership. It started off with a course called “From colleague to boss”, and I attended the Problem-solving Leadership course with Jerry Weinberg, Esther Derby, and Johanna Rothman. Most of them only made me aware about the things that I didn’t know, and the possible directions that I needed to learn more about. Let’s see where I have failed on leading dramatically in my past.


The hardest lesson I ever learned was a few years back. I had been appointed a group leader position, took the training, and considered myself a good leader. I tried to listen to my colleagues since they knew where the action was. I knew we needed to change something. I was aware that I needed their help to derive a solution that was well understood. I also knew that I needed to align all of my group for the direction. Only then were we able to follow-up on the same path.

That’s why I included my colleagues into all of our discussions regarding the direction that we were going to follow.

In remember one lively discussion where I felt like I awakened from a terrible dream. “You are trying to direct us for your own opinion. You are playing the boss card.”


I was totally unaware of that. What happened? I considered myself part of the solution. Therefore I considered myself part of the discussion, and wanted to be convinced. Seems that the outside impression in my colleagues was different. They thought I was trying to influence them based upon my appointed position, rather than trying to be on the same level as my colleagues.

I thought we were discussing on the same level, while my colleagues didn’t think so. Huh. I clearly lacked the empathy to understand that my colleagues saw me in a different position, and considered my weight in my arguments than I assumed. My outside perception didn’t match with my inside perception. That totally got me confused. Even worse, I failed to notice that my empathy filters shut me down from the imagination of that situation.

That stroke me.

What I learned from that situation is that from time to time, leaders need to slow down, and listen to the ones that are following them. With listening I mean actively listening rather than rushing to conclusions about what they perceive.


Another time, I was working a lot with one of my colleagues. Most of my team considered him the worst of us five. I wanted to make sure that he can follow along with the pace that the others were setting up.

I remember that we went out for lunch often, we talked a lot about work, family, and all that stuff. We discussed situations back at work, how to solve them, providing each other feedback, and thinking difficult situations ahead of time.

When I came back to propose all the awesome ideas that we could have ended up with, I noticed resistance. It took me some time to realize where this resistance came from, and it was partisanship.

Since I spent so much time with one of my colleagues, the other colleagues felt abandoned. Since we discussed lots of situations back at work, our thoughts even lost contact to their reality. They couldn’t understand how we derived at the point where we ended up at. That resulted in a disconnection between our proposal and their current struggles.

They had to resist our brilliant ideas since they couldn’t understand the problem that we were trying to solve. Even worse, they couldn’t imagine there was a problem – nor that that problem was the most important one to solve.

And it got worse. Since I talked on a more personal level with one of my colleagues, the others felt downgraded and abandoned. They were not only resisting our idea on the content level, but also on the personal level. That made the whole situation worse. In order to help them understand our points, I had to reach out to them on a personal level plus on the content level. That made experimenting worse, and dragged our innovation power down.

What I learned from that situation is that I shouldn’t take about work life when engaging with a colleague beyond work. That may ruin your whole team – especially if you are a leader.

Asynchronous communication

In other situations, I tried to make my colleagues aware that we had a problem. My personal introversion preferences, and my writing skill makes me write a lot in order to reflect, and make sense of all the various thoughts that jump up and down in my head.

I learned the hard way that writing emails, or blog entries is a terrible idea to create a sense of urgency.

Written communication lacks multiple feedback channels. What each of us writes down is ambiguous on multiple levels. When we engage with persons face to face then we broaden the feedback channels. There is lots of information that we take in during direct synchronous communication. It’s the gestures, the mimics, and we may ask clarifying questions. All these factors make direct face to face communication more effective and efficient than remote, asynchronous communication.

So, rather than creating a sense of urgency, or reaching anyone, I figured I created the opposite reaction. Everyone was fighting my ideas, close to no one was following up on the stuff that I had written down since no one could follow it. Everyone was thinking that I annoyed them, and I was the last to see that.

If you want to create a sense of urgency, make sure everyone can “listen” to your ideas, and ask clarifying questions. The best way I know of to make that happen is direct face to face communication.

Lessons learned

There are a couple of lessons I learned over the various years on leadership. If you want to lead people, either by being the appointed leader or the “natural leader”, you probably want to be aware of these different levels.

Before you try to “lead”, make sure how you are perceived by your colleagues. If your outside picture does not match your inside picture you might find out that there is a problem that no one will tell you about. Some people avoid the confrontation with their bosses. Get the delegation level for decisions clear.

Avoid personal friends. Everyone should have the feel that they have the same contribution to make. Avoid the trap where a colleague that you commute with often takes on too much influence. You will do a disservice to your other colleagues just because they live in a different part of the city, and can’t commute with you that often.

Finally, synchronous face to face communication trumps anything else when you try to create a sense of urgency. Things can get worse if you make the impression that you are giving out orders for your colleagues’ behavior just because they think you are the boss, and you have to follow up on your words. If they feel invited by direct communication, they will feel more invited to following you. As a leader it’s your job to be receptive for that kind of feedback – positive and negative.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

More learning as a professional

Tue, 03/11/2014 - 09:00

This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:

In your blog post on learning, you’ve left out community, and bafflingly to me, practice.

Wholeheartedly I thanked him for the idea for today’s blog entry.


Seems I assumed too much in my last blog entry. I thought I made it obvious, but it seems that I missed to put practice into the blog entry on learning. Looking back, what I did in order to learn, was to dig deeply into theory, and directly apply it the next day. Here is an example.

At a certain point, I read about Computer Organization and Design. The authors Hennessy and Petterson explain many of the underlying concepts for today’s computer systems. They explain how a CPU works, how USB works, the mechanics of pipelining, memory allocation, and much more.

Being a math guy back in school, I paid particular attention to the chapters on converting numbers – and how mistakes could happen at different levels. Just about that time I was dealing with our system. There were two major components, one written in Java running on a JBoss application server, and the other written in C/C++. There was an XML interface between the two. The C/C++ component was the master of all currency related data, while the JBoss application stored all the business relevant data like customer data, and addresses and so on.

There were some pass through services in the JBoss application server that infected the balances in the system. This system was all about tariffs, prepaid, postpaid, and convergent billing. There were certain postpaid tariffs where a certain amount of money needed to be deducted based upon a monthly fee that needed to be paid. Unfortunately that amount could be pro-rated based upon the amount of days the account was active in the current month. Of course, the pro-rating changed based upon the amount of days per month as well. The interface between the Java component and the C/C++ component dealt with a percentage value in floating point notation.

I found a bug in that interface that was based upon usage of double precision floating point numbers rather than 128-bit floating point numbers as used by Double-typed variables in Java. That bug could lead to a miscalculation for large amounts monthly fees in certain months, because the conversion from binary to decimal digits in that case couldn’t carry along the right amount of fractional digits in the C/C++ component. The balances where calculated with six digits of precision.

I was only able to find that (maybe rare) bug, because I had understood the inner workings of binary and decimal maths. I was only able to find that bug because I dared to try out. I dared to practice this skill.

Practice is a key ingredient to incorporate lessons learned. I practiced when I read about LDAP, and I had to immediately try out stuff the next day at work. At times, I even couldn’t wait that long, and needed to give it a try right away. Thereby I was able to learn not only the theory of how it should work, and take that for granted. Instead I could play around with my inner concepts of how it should work, and how it really worked. There were many more things that I directly had to try out, and I consider practice a prevalent thing that professionals learn from. I even dare to state that you cannot learn without putting your knowledge to practice. That was my assumption yesterday. That’s why I left out the obvious.


When it comes to community, I dare to state that communities weren’t my first learning source. If I recall correctly, it took up to reading Lessons Learned in Software Testing back in 2007, before I joined any mailing list. From then on, I dived deeper into mailing lists. Right now, I joined countless of them – and I muted lots of them. There are a couple mailing lists that I deliberately want to have a peek here and there – just to stay up-to-date.

But there’s more.

There are more and more online communities. Some of them meet up on Skype sessions, some on twitter, others in direct forums, like the Software Testing Club, or the AST forums. You can find lots of helpful folks there, and it only takes a few days to receive a helpful response in case you have a question (and present that you did the most basic research on your own rather than engaging in Let-Others-Work mentality).

Communities are a great resource for your learning. However, I found out later than my first course about this. It helped me shape in the long-run, and I didn’t need communities to get started. This might be about the time I was learning, and communities only grew later, but it might also be about me being unaware of those sources.

What about….?

I think there is more where you can go and learn from. But remember this: if you can directly apply stuff the next day back at work, your learning will stick deeper. Of course, you probably need to have the right amount of slack that play around with new ideas. You need personal freedom to master that new skill. If you don’t have it, then you probably need to invest some of your personal time.

Some folks claim that you need at least 10,000 hours of deliberate practice before reaching mastery for any skill. That might be true, and some folks claim that I invested a lot of my time in the early days. Might be that this time paid off in the long run. I joined this field in 2006. That is eight years ago. I am not so sure about where I currently ended up, whether it’s the right path, and whether my early pays off, or burns me out. Only time can tell that to me. Time will also tell you. Keep patient.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Learning as a professional

Mon, 03/10/2014 - 09:00

Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.

There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.


Personally, I have studied back from 1999 to 2005 in university. I learned a bunch of stuff. How to do programming in Haskell, how to program a 6-limbic robotic arm, and how to do offline and online training of computer systems. I learned about face detection algorithms, and we wrote one on our own. We adapted that stuff for office materials like a keyboard, a rubber band, and so on. My diploma thesis was about hand gesture detection applying similar approaches. I am still amazed that most smartphones nowadays can do the stuff we researched back then.

I interviewed for my first position in 2006. I was interviewed for a position of a software tester. I had heard about software testing twice in university. Once during a course on software engineering when it dealt with the V-model. There was a 15 minutes lecture on it. The other time was during the Software-Praktikum, a combination of programming, and some lectures. There was this professor who told us about those freaking folks doing extreme Programming. They were doing test-driven development. No one cold explain to us what it was in 2000.

So, I sat there the first few days into my new job, and needed to learn a bunch of stuff. Besides the unfamiliar domain, and the unfamiliar approaches to automatically executing tests on a Solaris machine, I needed to learn about software testing. That was my profession now.

I didn’t learn much about the domain I was working in back in university – no wonder. I slightly learned something about shell-scripting that I could use in my job. But I certainly didn’t learn anything about my profession – neither software testing, nor software development. So, I had to learn that somehow and somewhen differently.


What I had learned in university about learning was to get a bunch of books on the topic, and get going. So, I ordered a book about software testing. It was a classic book, written in German. It had some decent amazon reviews, so I decided to get me a copy.

It was awful.

I couldn’t read it for longer than five minutes. All those terms didn’t give me a clue. It was worse. They were confusing me. Equivalence classes, white-box, black-box, you name it.

So, I still sat there, and couldn’t find out what to do. So, I took a different approach.


I started to ask questions to some of our senior testers. We were in the middle of a project, and were closing up on release 0.4 for an upcoming product. We had weekly meetings with our project manager that asked for status.

I had taken on some tests for use cases that I could understand two months into a new job. I was able to add customers, addresses, modify them, maybe I was able to create an account with those address data as well. That was it – mostly.

So, I took on some of the tasks related to customers, addresses, and maybe accounts. For me, those were easy. I merely created the tests that I felt were necessary. I worked with colleagues to have a look over my documents, and provide me feedback where I needed it.

I was able to learn from my colleagues back then more than I was able to learn from books, or rely on the knowledge that I had gained from university.

Training classes

One and a half year into my first job after university, I attended an in-house course on software testing from an outside consultancy. At that time, that guy spoke about all the stuff that was in the book that I had bought a couple of years ago on software testing.

At that time, I knew which test practices I would need. At that time, I didn’t see any benefits of the stuff that guy was offering. I never needed it again.

Due to lack of official training classes, I had decided to jump in and learn as much as I could to do a decent job on my own. I knew how to get to the sources that were relevant for my job. I had bought books which resonated with me, and were easy to read. The training class came to late, and it was merely justifying what I already knew.


What I had learned back in university was how to learn. University didn’t teach me lots of stuff that I would use again when I joined the corporate live, and worked for The Man. I had to re-invent my knowledge to fit the job that I was hired for. I knew how to do that thanks to university.

The training class that I attended eventually came too late. At that point I already had done a decent job as a tester, and was asked whether I wanted to become a group leader for a particular testing group. I already had learned what I needed to learn to do a decent job of software testing. If I had waited for the training class to kick in, I would have provided a dis-service to my employer. I could learn that faster than that.

There are good and bad books out there. But how can you differentiate the two as a beginner? You can’t. I jumped to the first, and really got disappointed. I was lucky enough to be able to follow my passion and my instincts, and could compensate a lot of missing knowledge by that. Over the years, I have read several testing related books. Now I think that I merely started with one of the worst ones. Bad luck. Maybe I should have looked for more alternatives first. Who knows. Peer recognition can be helpful with that.

But most of the stuff I needed to know I learned from my colleagues. They were able to help me on the job, and answer my most-pressuring questions. They were able to help me, to coach me, and to mentor me. They could help me with the pressing questions at the task I was given. They provided some answers to me, and eventually those helped me shape my mind.

Learning on the job with feedback from your peers is probably the biggest learning channel that you have access to. Use it whenever you can. Few other methods can provide you the same learning depth.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Scaling Agile – really?

Fri, 03/07/2014 - 09:00

There seems to be a buzz around scaling agile around lately. A couple of weeks ago I saw a tweet from Gabrielle Benefield that made me think.

Screen Shot 2014-03-06 at 19.28.03

Why is everyone hell bent on scaling Agile when they have trouble even getting one team going?

That question reminded me about a lesson I learned from Don Gause, and Jerry Weinberg in Are Your Lights On? What’s the problem? Who has the problem? And who should fix it? Let’s see.

What’s the problem?

A problem is the difference between a perceived state, and a desired state. In order to solve that problem, we may work on the state, the desire, or the perceiving. That’s the bottom line I got from the aforementioned book.

One question to ask in regards to the underlying problem folks try to solve when talking about scaling is what’s the problem they are trying to solve. Stick long enough with corporations, and some of the answers you receive for this are “we want to deliver faster”, “we want to deliver better quality”, and “we want to be more flexible”. These are all valid answers for the desired state.

As consultant, when entering a new client, one thing you try to find is has to do with the currently perceived state. The answer to that question lies in how good the client can currently perceive the situation. As an outside consultant you can often easily make the customer aware of some things he doesn’t see. That influences the perception of the current state in the organization. So to speak, as consultant us consultants help the organization perceive other things in their current reality, and thereby maybe shift their problem.

When it comes to agility, and the above quote from Gabrielle Benefield, the question probably should shift towards “are we really doing good in one team?”, “where are the problems with our current market situation?”, and “how can we deliver faster?” While trying to answer those questions, you might find out that you perceive your current situation differently, and scaling with 200 teams is not necessary, since 2 teams already can deliver lots of business functionality, while the other 198 teams can focus on conquering new markets.

What some of the fuzz around scaling agile right now is all about, is to shift the client’s perception regarding the desired state without challenging the perception of the current, and what causes some of the problems they are currently perceiving. I think rather than providing a solution to a perceived problem, or drawing a picture of a desired future state, we would be way better off helping the enterprises around to take a step back, and help them evaluate what they really want to do, and then solve that.

Who has the problem?

This already touches the field of who has the problem. When we talk about creating a desired state, my impression is that we try to impose a solution on all the large companies out there. I think that’s wrong because that focuses on the consultants having the problem of not being able to reach out to the large enterprises. So, all that a solution consisting of pre-defined practices solves lies in the utilization of the consultancy selling that solution.

In my current perception, that larger companies out there currently face that small startups can outperform them easily, and deliver better solutions more quickly. So, the one who really has the problem is the enterprise organization that is going to become extinct unless it changes something.

When talking about agility, and business agility in special, we should help those larger corporations to the agility that helps them outperform the competition. That probably means that we should engage with our clients, see their reality, and help them either shift their perceptions, or help them to really solve the problem.

Who should fix it?

You may have noticed I already shifted into this question a bit in the past sections. So, let’s focus on who should fix the problem of too few business agility, being too slow on the market, and so on.

What I perceive happening right now is this: a consultancy has invested large amounts of money in becoming certified for a particular method. They enter a new client, and sell that solution to them – because of sunken costs for their investment, and maybe because that’s the only thing they know.

That would mean that we really try to impose a solution on the client that has the problem.

With large organizations, as an outside consultant, I learned that I have limited influence on the folks. I don’t have budget responsibility for all the people involved. I don’t have payment influence for individual people. The only thing I can do lies in a servant leader role. I can help influence some people, but I can’t really put pressure on them – and that’s good.

Who’s the one that can effectively re-shape the current organization? Who’s the one that can effectively change team structures in the organization? Who’s the one that can create new teams from the existing structure? Usually it’s not the consultant that can directly do that, but the manager of the organization.

When introducing a new methodology, we shouldn’t rely too heavily on the solutions that outside consultants provide to us with their blueprints, practices, and direct actions. Rather us consultants should clarify how much we and the client will be able to agree, and have a 50:50 influence on the proposed solutions. I don’t see that the ivory tower blueprint solutions that consultants come up with will work out if we don’t make sure to connect with the ones that really have an influence on the organizational structure. And I think that they also shouldn’t delegate all their hard-earned influence onto us, the folks that have the fewest clue about the inner working of the organization at hand. We should do this together.

More Honest

When it comes to scaling agile, I think we should be more honest when helping others to implement a solution that should work for them. That includes understanding their reality, helping them see things they don’t see, and then help them to work on the resulting problems. When it comes to change management, there is still a bunch of stuff us agile consultant can work from change agents, and it’s better to join forces with our client rather than imposing our pre-fit solution, just because we thought about it. Thereby, we might eventually be able to help our clients – I hope that’s the problem that consultancies at large really try to solve.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

Five years of fighting crappy code

Thu, 03/06/2014 - 09:00

Today marks the fifth anniversary of the Software Craftsmanship manifesto. Doug Bradbury asked me the following question:

Do you think that the bar of professionalism has been raised in the 5 years since the Software Craftsmanship Manifesto was published? Why or why not?

My short answer is “yes” – and “no”. Being around since the early days back in November 2008 when I joined the Software Craftsmanship mailing list, and having been involved in the different thoughts on the Ethics of Software Craftsmanship, my longer answer hides in this blog entry.

Where we raised the bar

Overall, I think we raised the bar to some extents. Here is a brief list of stuff I see attached to the Software Craftsmanship movement.

There are lots of conferences where we share our work. I was lucky enough to attend the first Software Craftsmanship conference in 2009 in London. It was a blast. Gladly, we didn’t stop there. Since then other conferences popped up, like the Software Craftsmanship conference North America, and the German Software Craftsmanship and Testing conference (SoCraTes), that also start to spread to the UK recently. It’s a very good thing that we keep on conferring, exchanging our thoughts, and sharing what we know to other peers in the field. Clearly a value that we put forth from the manifesto.

There are also a couple of books available on the topic. Uncle Bob Martin’s Clean Code and the lesser known Clean Coder to start with. Dave Hoover’s and Ade Oshineye’s Apprenticeship Patterns are lesser known. So is Sandro Mancuso’s Software Craftsmanship book. (I am guilty, I haven’t read it, yet, as well.) Not to forget Emily Bache’s excellent Coding Dojo Handbook. These books collect the Zeitgeist of our movement today. I hope to see more books coming up in the next years.

Then there are events like Code Retreats and Coding Dojos. Corey Haines popularized the former one; for the Dojos there are several people around that started them. These help persons of the craft of software development to learn more about coding practices in the 21st century. For example, I remember a code retreat where we had a couple of students attending. At the end of the day they thanked us all since they learned so much on this one day that their professor couldn’t have taught them in years of study at the university. Then there was this other guy that claimed that he would be looking for a new job on Monday – and he did. These events make people of the craft aware about more effective (and efficient) ways to program in this century, and how to overcome sacred beliefs about coding habits.

On a side note, I think that the same goes for the larger testing community out there. As I see it, the context-driven testing community is very close to both, the Agile and the Software Craftsmanship community. I get a lot out of all of the three communities, and I think that we could do better if we managed to join forces.

Last, I think the biggest impact the Software Craftsmanship movement came out of the very first SoCraTes conference. We got together, and thought “this can’t be it for another whole year; we need to maintain this momentum”. We created the German Softwerkskammer to spread the word about Software Craftsmanship. One year later, we found out, that we had started ten local user groups with this. Each group met between once per quarter up to several times per month. They shared their knowledge among each other. They helped convince the larger world of software developers out there, to do create well-crafted software by steadily adding value, and nurturing a community of professionals that understand how to create productive partnerships with their customers.

Where we lowered the bar

There are also things that trouble me, and I think we can do a bit better than that.

Early on, there was the Wandering book. I think it floated around between various craftspersons quite a lot. I think I was number 42 on the list when I signed up, and it took a year or so until the book made it to my hands. Unfortunately that book is – so is the revival book that I started about a year ago in Germany. It’s a pity, to some extent since if we can’t value our treasures, our words of wisdom to the extent that we put it aside, and forget to share our wisdom with the future generations of craftspersons sent out. If we do that with our words of wisdom so tragically, what do we expect our code bases to look like?

Recently Uncle Bob Martin had an answer to that question – and the community is heavily discussing it. The idea is the one of a dedicated foreman that has the right to reject certain changes to the version control system. I think – like all rules – we shouldn’t try to apply that rule without unthinking faith. Personally, I think we should answer the question “how does that help to advance the craft?” before we implement that foreman.

Then there is another thing that makes me worry. I have worked with a couple of companies in the past few years. In that, I saw a pattern emerging. There is this group of software craftsperson that think they are the elite. So they form their own central core team where the best code of all time is produced. This is pattern that is clearly not in line with the manifesto as I interpret it. As Software Craftspersons we should be able to share our tales, share our stories, share our practices. Creating an elite team that thinks they build the best code in the company is creating an artificial barrier that will prevent other folks from joining the elite club. It shuts down the sharing aspect that we held so dearly in the manifesto. Learn how to get along with your colleagues is the way to go.

How to move on?

As I see it, there are good aspects of software craftsmanship around – and there are bad ones. I would be surprised if craftsmanship was a silver bullet after all. I am glad that we could make more people aware of coding practices they never learned in the 19th century in university, and we are starting to reach out. From my perspective it’s still the tip of the iceberg, and if we don’t learn how to overcome some of our elitist thoughts, we are probably ending our history after five years. Let’s avoid that, and keep on fighting crappy code that we created.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

The worst thing about electronic tools

Wed, 03/05/2014 - 09:00

A couple of weeks back, I became aware of a fact about electronic tools that gives a large drag to using it. I see lots of teams struggle with electronic tools. Most of the times these work with a raped bug-tracking tool used for – well, I think – status reporting towards their ScrumMaster during the daily Scrum meeting. That’s broken on so many levels – at least that’s what most team members reported to me when a particular tool was inflicted on them. The infliction usually happens either by sunken cost syndrome (“we invested XXXXX amount of money in that, you need to use it!”) or other self-imposed factors causes (“we work on twelve different planets”, “this paper thing is too touchy for me”, “we are green here, we don’t kill trees”). Let’s explore some of the reasons behind that, and try to come up with clues on why these are broken, and what I think the worst thing about these is.


Empirical evidence trumps speculation – every single time. That is why Agile methodologies invest so much time in empirical process control. Empirical process control necessitates three key ingredients: inspection, adaptation, and transparency. You need to have transparency on your product, your process, and your current working plan on a daily basis in order to make the right decisions regarding the best actions to take next in order to inspect and adapt. If you don’t have transparency on the thing that you try to inspect, you will only receive a blurry picture, and can only improve that blurry picture. (And sometimes the best action to take is to unblur the situation.)

With electronic tools, the last thing that happens, is transparency. Usually during meetings – where transparency for inspect and adapt is most needed – there is one guy sitting in front of the mouse and keyboard, dominating the whole transparency by wildly scrolling and clicking around, or totally slowing progress of the meeting down to an unreasonable level by being the only typist in the meeting. I have rarely seen less effective ways to waste money.

On the bottom line, you get costs for installing, running, and maintaining the tool, time wasted in meetings by being less effective, and time wasted due to less transparency. Good job.</sarcasm>


I think the great invention of our age lies in – drum-roll – plugins! You can dynamically plug in behavior to every software today. Just as you could theme everything 15 years ago, now you can plug-in anything that you need to do. That’s why there are lots of plugins for the available electronic tools. I think at a point in the future we will need a plugin to manage our plugins more effectively.

What stroke me most a couple of weeks ago had to do with a tool where there was an “Agile plugin” promising that you could manage all your “Agile work” with it. It had an Agile backlog, it had an expedite lane, it even had Enterprise Java Gems!

Funny thing, I talked to the ScrumMaster and ProductOwner after a standup about the tool. They used the Kanban view for managing their bug tickets, and the Scrum view to have an insight into the current state of the Sprint. I asked why they kept on switching between the two views, and whether there wasn’t a combined one, so that they could easily see the amount of planned and unplanned work on one page. “That’s not possible.”

A couple of minutes later into that talk, I found out that another ProductOwner in the same room had created a dashboard to overcome that short-coming of the plugin on top of the tool that was really in place to track bugs. I mean


The whole transparency could be solved with the customized dashboard alltogether. I am quite sure that they wouldn’t need the plugin AT ALL. Thank you for providing that piece of junk, making everyone install it, getting confused about it, while never solving any real problem.


In the end, I noticed it boils down to this: filters. A year ago I worked with a team that used a tool that was heavily using filters to provide different insights into the product backlog, the sprint backlog, and the current state of the development.

The problem was that everyone had different filters. The bigger problem was that everyone had different technical filters in combination with their personal filters. So, everyone had a piece of truth on their mind whenever they entered a particular meeting. All of them together had totally different truths. Of course, all the meetings took a lot of effort to reach a common ground for all those different truths around.

We are all facing personal filters. For example, there are certain people that I will stop quickly listening to. Most of the time that effect has to do with personal history, personal experiences with folks, and at times also my coping-stance with the signs I see in a particular person – or maybe even just how likely that guy reminds about that dork back in my high-school years.

The same goes for various tools that we use on our computer. The problem comes from different filters that distort our reality. Every filter takes away some complexity so that we can more easily deal with the situation. There are personal filters that we develop over time, and there are technical ones that we use.

While working with an electronic tool, you have two filters while working with your teammates: the personal ones, and the electronic ones. When working with a physical board, you remove one set of filter that might distort your reality from the one of your colleague. Thereby you have an easier time to reach common understanding, and fewer opportunities that lead to shallow agreements.

The biggest problem

When it comes to electronic tools, I think the biggest problems arise from the various levels of filters involved that distort our truth from the truth of our colleagues. We should be sensible for it, and we should remove the tool whenever we notice problems with it. In the long run I never faced a situation where a physical tool was not better in bringing more transparency for a better inspect & adapt cycle, had fewer work-arounds to take (think plugins), and led more easily to a shared understanding of the situation. That’s why I think that electronic tools – despite the fact they were most often built for different needs – are ineffective, and therefore useless in a fast-paced environment.

Your mileage may vary.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs


Tue, 03/04/2014 - 09:00

When I became a swimming trainer, I had to learn various ways to teach kids how to improve their swimming strokes. As part of a seven weekend education course, we not only heard about stuff, but also had to give training lessons to our classmates that proved that we were eligible to the trainer certification. In these courses I learned about a gentle technique that I lately noticed to apply in other fields as well – whether appropriate or not.

OVer-correction in swimming

Say, you have a swimmer that is turning his whole body during crawl swimming when taking in breath. That’s terrible, since the swimmer will lose lots of momentum. He is rolling his body too far. The whole arm movements won’t be as effective as they could be in the water.

Another swimmer does not apply a wave movement on top of his body during breast-stroke. He will be losing momentum constantly, since his legs will slow him down way more than necessary. The same goes with the arms when he brings them back in the starting position.

What do you do as a trainer? You need to correct that movement. The easiest way that I learned was to over-correct the situation. In the first example, I would ask the swimmer to turn his head to a point at which he can barely take in air from above the waterline. I often asked kids to turn their heads just as high so that they could barely see the benches outside the water – but no higher. For the second example, I would incorporate a training lesson with various coordinative exercises. I would ask kids to swim a wave, then add the arms, then eventually add the legs – maybe with many more steps in between, depending on the particular group I was training with.

The technique is called over-correction. You over-compensate a wrong movement in the other direction for a limited amount of time. Then you go back to “normal” swimming, and the movement has shifted a bit. You do this over and over again to make a better movement stick.

I used this technique quite lots of times. Whenever I noticed there was something wrong, I planned in exercises for the training group that would correct some of the major errors. Notice that we also learned “movement sight” during the seven weekends. That is how to spot that something is wrong, to notice the wrong turn in the movement while observing the swimmer closely. Only when you directly see what goes wrong, you may provide corrective feedback after the swimmer finishes the lane. Or you can help the swimmer with exercises to over-correct. In either case, you need to spot the problem first, and then understand it well enough.

So, vision, feedback, and over-correction form a vital training package.

Over-correction in professional life

In software development I noticed the same technique applied by others. For example, take Michael Feathers’ book Working Effectively With Legacy Code. He provides a set of rules for unit tests in it:

A test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can’t run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as editing config files) to run it.

If you apply these rules without thinking, then you might start to wonder how you can test a class that is a network adapter for your application. Or how do you test the component that writes data to your disk, and will be used all over the place? A few years back, I asked Feathers, and he replied that he wrote down those rules at a time when developers would only test their code with integrated tests, rather than simple unit tests. He wanted to change that. (According to my experiences this is still the case.)

Clearly, he used over-correction to kick programmers out their comfort zone to think from a different perspective again.

Or take Lessons Learned in Software Testing. That one has a couple of contradicting lessons. For example, lesson 145 is titled “Use the IEEE Standard 829 for test documentation” while lessons 146 (the next one!) is titled “Don’t use the IEEE Standard 829″. That’s not to drive you crazy. It’s there to make you think. Think about your problem from a different perspective. It’s an over-correction – as I would call it.

An honest correction

As a trainer, coach, and consultant, I lately noticed that I use that technique a lot. Probably too much. When I say that programmers should start to test, I say that because I have made the best experiences with cross-training people in up- and down-stream activities.

At the local shop I once worked (for ten years), I knew how to do the cashier, I knew how to deal with vegetables, but my main activity was ordering of beverages, beer, wine, and liquor. I could contribute in other ways since I knew all this stuff, from product ordering, to the shipping process to how it is sold. I could jump in when there was trouble in any of these activities, and I could quickly evaluate the current situation, and jump in.

The same serves us in software development. If we know just enough to compensate for bottleneck situations, or when a colleague won the lottery and left the country for greener pastures, we are able to contribute more meaningfully.

In the past two weeks, I probably drew some false dichotomies. That was just to make you think. Of course, it might be the case that you need to develop some other skills like “movement sight” to spot a problem when it occurs, and the power of providing feedback in order for your colleagues to hear what you are trying to say. I will leave those ones for other blog entries.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

SoCraTes 2014

Mon, 03/03/2014 - 09:00

I remember when Andreas Leidig approached me in late 2010. He wanted to get a discussion going regarding a conference on Software Craftsmanship in Germany. We decided to meet up during XP Days Germany in 2010, and see what we could do. We quickly agreed on an unconference format, two days, somewhere laid back. Some folks had organized the German Agile Coach Camp and Play4Agile in Rückersbach close to Frankfurt. We decided on that spot as well, and organized everything for 2011.

Early on, we decided that we will need outside support. That was when we started to reach out to other craftsmen, like Micah Martin, Adewale Oshineye, Sandro Mancuso, and many, many more. We had around 10-20 participants from outside Germany with us. All the tales they told us on how they were running things in London, Israel, Finland, you-name-it engaged us. It felt good to be around so many like-minded folks, and receive outside inspiration.

The first SoCraTes – Software Craftsmanship and Testing (un)conference – was a success. We had some track sessions back then, and a full day of Open Space. During the Open Space I joined a session that was looking for how to continue. With all the energy in the room, we placed ourselves on a virtual map of Germany. That was when I noticed, oh, there are a bunch of other folks around me that come from a similar location as I do. That was also when we decided that we needed to keep that spirit going.

One year later, we came back for SoCraTes 2012. Since the first conference we had founded 10 user groups all over Germany on Software Craftsmanship. There was one in Hamburg, one in Karlsruhe, one in Munich, one in Nürnberg, one in Berlin, one in Frankfurt, one in Dortmund, one in Düsseldorf, and one shared around Münster, Osnabrück, and Bielefeld. We created a timeline of events that had happened in the various local communities since our first get-together.

We were amazed about the various events, code retreats, user group meetings, and so on.

We still adhered to reserve space for foreign inspirations at that time. We had 10-20 people from outside Germany with us. However, Rückersbach had just 70 beds overall available. With ten local user groups potentially joining our unconference, we faced a serious problem. From each location just around 5 people would be able to join. So, with such a large community, we already excluded many potential attendees.

The format of the unconference had shifted. We had abandoned previously-set track sessions all-together. Instead we focused on two full days of Open Space. That provided the freedom necessary. Here’s the schedule from the two days in 2012.



At the end of the day, we decided to run the conference again in Rückersbach, but have it organized by a different group of people. We explicitly decided to pass over the organizing responsibility to one of the local groups from year to year.

Last year, the limited amount of beds became a problem. We discussed again what to do about it, and asked the organizers to seek a location that may scale up to 200 participants.

Rückersbach had an advantage: it was close to Frankfurt airport (about a one hour ride by car). That made it easy for people from other countries to attend, since Frankfurt is the largest airport in Germany. It would be hard to find such a spot with more beds in such a good position.

Late last year, the organizers contacted me. Since I am working in Hamburg, they asked me whether I could take a closer look at a potential spot for 2014 that sounded promising. They had 200 beds, and were located in Soltau. That’s about a one hour ride by car outside from Hamburg.

I agreed. When I finally made the trip there, I was amazed. The new hotel was awesome. There are ten meeting rooms all set up with video projectors, flipcharts, and so on, one central place where everyone meets, one large room for the Open Space opening, a bar with space for 170 people in the evening, a swimming pool, decent space outside close to nature. I got back to the organizers and told them that this spot would preserve the privacy that Rückersbach had with it, and that it seemed to be perfect to scale.

Now, I know that the announcement for SoCraTes 2014 is coming closer, and I can’t wait for the registration to open. Unfortunately I probably will only be able to attend on Friday, since I have a trip to the State to make for an AST board member meeting and CAST 2014 in the following week, but I know that I have to be there.

SoCraTes 2014 is scheduled for August 7th (evening arrival) to 9th, probably with a code retreat on Sunday, August 10th. I know it will be awesome. I know it will be full of craftsmanship, coding, and conferring. I know it will be worth my time. I now it will be worth the trip. You should reserve the date, too.

P.S.: Last week, I also heard rumors that the fine folks organizing SoCraTes 2014 are looking for sponsors. There will be different sponsor packages, some with free slots available. You can meet a bunch of fine folks there that are the top-notch in software development in Germany, Europe, and probably even the world. If you want to support the craft, please tell your bosses. It’s worth their money.

P.P.S.: Did you know that the UK folks – yeah, those that heavily influenced us in the first year – brought the same format to their country as well? I attended SoCraTes UK last year, and it was similarly awesome to the German event. They are organizing another event this year in June. Reserve the date as well.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

The elite foreman

Fri, 02/28/2014 - 09:00

It turns out that Uncle Bob had some more to say on the role of the foreman, and how it applies in various situations. However, I have totally different experiences.

The foreman team

Over the past two to three years, I observed a pattern while visiting various clients in Germany, and I sense there is a correlation to what Uncle Bob is actually saying. Time and again, I see teams separating themselves from their peers. I see craftsmanship elite teams forming that put craftsmanship on their flag, rise it high – and dramatically fail to address the business needs underlying any software project.

More often than not these craftsmanship elite teams separate themselves at the core of the application, intending to create the best software they ever can. What teams outside that ideal bubble of crafts-fore-men get is that they are writing crappy code, but the world will be safe as long as that elite team continues to control all the commits to the main branch.

Sorry, I am exaggerating a tiny bit here. Just a tiny bit, unfortunately. These elite teams set themselves off to produce the best code that was created ever at this company – heck, ever in the whole damn universe.

This situation is so broken on so many levels.

First off, if you encapsulate yourself in your own little bubble, you are not teaching your peers – clearly a value that we set out five years ago when we discussed the contents of the craftsmanship manifesto, and the underlying ethics.

That sort of situation is also not very helpful for the larger community. It gives rise to a two-class organization. Either you are with or against us. Surely a driver for conflict, and Uncle Bob’s recent explanation carries along that this is what he intends to do.

A false dichotomy

Unfortunately, Uncle Bob is drawing a false dichotomy. Uncle Bob distinguishes between two extremes. On one hand, you have the perfect agile team that consists only of alpha-animal-like foremen that have a shared value system. On the other hand we have the open source model where a master committer appoints valuable contributors the right to also commit directly, and supervise the work of others.

This is a false dichotomy. There are many, many more levels of collaboration in between. There are many, many more levels of collaboration besides that. For example consider a quite senior programmer that is joining your team, but doesn’t know the code base. Would you grant him the commit rights from day one? Day ten? After ten successful commits?

Clearly, we can’t answer that question without more context. That context is crucial for deciding whether that new guy is actually sharing our value system, or parts of of it, or maybe just one of it. It’s hard to tell, isn’t it?

There are many more factors involved than meets the eye. There are more factors in play that don’t have anything to do with foremen at all, for example personal safety. These factors contribute largely to how productive and effective your team is. I worked on a team where we delivered nothing because the team hygiene wasn’t right. Overcoming that factor lead us to delivering twice the amount that we planned – for three sprints straight. Coincidence? I don’t think so.

A logical fallacy

Now, with all this said, here is the logical fallacy underlying Uncle Bob’s reasoning. He explains that someone might feel attracted to his classes. Then those folks join his classes, and ask him questions like “how can I convince my team mates?” Uncle Bob says that you can’t – I think you can, but it will take time.

The logical fallacy though, is this: Who is making you a foreman? Who is going to make you a natural leader that others want to follow?

Think about it. If you ask questions like “how do I convince my colleagues back at work?” you probably are not a natural leader. Otherwise your colleagues would follow you. Uncle Bob suggests to put those guys in the role of the foreman. But who would be doing that? Can you do it yourself?

I think this leads to elite thinking. “We are the elite. Please take a step aside if you’re not willing to join us.” On one hand, this might be good, since work might get done, and we will end up with better code than before. It resonates to some extent with me, since it sort of replicated the role of the ProductOwner for the code.

Still, it’s wrong. it’s wrong since you can’t lead without people following you. For that to happen you have to convince your colleagues for example by leading by example. That’s one way to do that.

I don’t know what Uncle Bob’s ultimate goal is with this rule and role. I am suspicious that it will in the end lead to sorting out capable from non-capable programmers and team members. I think it would be more helpful to engage in more proactive teaching with the ones that need it, and create a system that makes you aware when something is wrong. But maybe that’s just a cultural bias from my side.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs