Markus Gärtner's Blog, page 9

The generalizing cook

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.

Nom-nom.

On writing blog entries

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.

21:34

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.

21:44

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.

21:48

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.

21:51

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.

21:53

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

21:56

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

22:01

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.

22:10

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.

22:20

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.

22:25

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

22:33

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

22:36

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

22:41

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.

22:45

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.

Working effectively with legacy tests

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.

Flavors of sunken costs

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.

Money

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

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.

On coaching questions

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.

Only human

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.

Books

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.

Confer

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 shino.de? 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.

Learning styles

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.

Reading

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.

Coaching

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

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!

New names for the quadrants

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?

Masters of Disaster and Improvisation

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.

Hard(ly) to coach

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.