Recently I restarted the Wandering Book. The Wandering Book is a tiny book passed on from Craftsman to Craftsman, fromCmmunity to Community intended to collect the Zeitgeist of Software Craftsmanship. I deliberately decided to start passing this to the German Softwerkskammer user grups. The idea is to collect the different notions, sort of a guest book of all the local events happening all over Germany.
Since the first book seems lost, I decided to put a disclaimer in it at the beginning. Here is the initial entry I made.
I have a confession to make: I am addicted. In this blog entry I would like to warn you about it, so you don’t go the same route down as I did. Don’t follow me on that path, even if the temptation looks promising and convincing.
You don’t have a clue what I am talking about? I talking about conferences. I am addicted to them. In this blog entry I would like to foster my coming-out, and provide the things that make me addicted. Don’t fool yourself that you won’t become addicted. Stay away from conferences! Don’t go there!
Since it was shortly before Christmas, I put a wish on twitter last week:
Anyone who wants to give me a gift for x-mas, consider writing a programming language where “if (* == true)” results in a compiler error.
This inspired some ideas on the twittersphere, and I decided to bring this topic to the Hamburg Software Craftsmanship user group on last Tuesday. Here’s what we brainstormed together: The best programming language, ever.
Probably the ugliest thing about going to conferences is that you pick up a lot of books to read. That even held for XP 2012 in Malmö, Sweden, although I just attended the first day at the tutorial of J.B. Rainsberger & Ruud Wijnands on Agile Coaching. They recommended two books from Patrick Lencioni for my to-read pile at home, The Five Dysfunctions of a Team and The Three Signs of a Miserable Job. While getting close to finishing the latter one, I noticed that the three signs of a miserable job map easily to signs that your Scrum implementation is miserable as well. Here’s the rationale.
About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.
Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:
Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.
I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:
In the past I have been more than skeptic about certifications. I even wrote about my minimum requirements for a certification programme that might (or might not) add value in an article called Meaningful Certification?. Despite the split between the two larger organizations (and their early leaders) on Scrum – the Scrum Alliance and Scrum.org – yesterday I noticed that the certification scam has taken on new levels with a program called Certified Scrum Manager (IAPM). Here is my honest critique about it, and I will try to rant as few as possible about it.
Last Saturday we had the first testautomation coderetreat in Munich. Woohoo! This was a kickstart for this new coderetreat format – besides the original one from Corey Haines, and the Legacy Coderetreat format from J.B. Rainsberger. Here is my report from the facilitator’s point of view and with some hints about what I am going to try at different other follow-up coderetreats.
Today, a colleague of mine, Norbert Hölsken, started off a discussion in our internal communication channel. He asked:
How do you treat bugs on the taskboard that are found during testing? Create a new test for each bug, and put the test task back in ToDo? Or create a bug, and a bug-follow-up testing task?
As it turns out there are a lot of valid reasons to do it one way or another. Yet, the answer “it depends” does not help – neither a Scrum Coach, nor a tester working in a Scrum environment. So, I started raising some of my experiences and concerns, and some of my other colleagues replied as well.
Skip forward three hours, and I am writing a blog entry on my thoughts about it.
