Right before Christmas I crossed a write-up of Al Shalloway about Kanban being the integration of Deming, Ohno, Goldratt’s Theory of Constraints, Satir and Nonaka. At a similar time I finished Jerry Weinberg‘s most recent book Experiential Learning Volume 3 – Simulation. Jerry explains the Satir Change Model in such a great way, that I would like to elaborate a bit more on the relevance of the model particular for Kanban.
Continue reading The Satir Change Model and KaizenCategory Archives: Methodologies
Methodologies
The best programming language
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.
I need to elaborate a bit on some of them.
Disclaimer: Don’t hate me, I’m just a messenger.
Continue reading The best programming languageThe Three Signs of a Miserable Scrum implementation
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.
Continue reading The Three Signs of a Miserable Scrum implementation7 Zero-order measurements for agile projects
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.
Continue reading 7 Zero-order measurements for agile projectsTell a story at the daily standup
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:
- a story about the product
- a story about testing
- a story about the process
Certified Scrum Manager – somewhat more than a rant
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.
Continue reading Certified Scrum Manager – somewhat more than a rantTestautomation Coderetreat No. 1 – A report
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.
Continue reading Testautomation Coderetreat No. 1 – A reportTracking testing on the Scrum taskboard
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.
Continue reading Tracking testing on the Scrum taskboardTestautomation Coderetreat postponed
If you have followed this blog long enough, then you might have crossed the Testautomation Coderetreat in Munich which we planned for June 2nd. I apologize for having to cancel the first meeting on such a short notice, but we found it unprofessional to stick to the date. Here is the reason we had to postpone this date:
While this might mean, that I will have to do lots of other duties in the next few weeks – well, at least my priorities will change a bit – we also planned in a replacement for the for the first testautomation coderetreat. The new date is now the 11th of August, again in Munich, Germany. Here is the link to the event on eventbrite, please sign up there: Testautomation Coderetreat Munich.
Coderetreat goes testautomation
I remember a talk from Cory Foy back at XP 2010 in Trondheim, Norway. He referred to Corey Haines as the happiest guy in the world. Although he lost his job, he started to travel around in the world, from shop to shop, from company to company. He was able to learn so much in a single year that he continued his journeyman tour after that.
One thing that Corey Haines invented alongside is a Coderetreat. Up until the global day of Coderetreat last year on 3rd of December I didn’t know what a Coderetreat actually is. At the core are six sessions of 45 minutes each where you solve a problem in code. Then you delete your code, and do it again – maybe with a different pair partner.
Recently J.B. Rainsberger invented the idea of a Legacy Coderetreat. The idea there is similar to a Coderetreat, but have to deal with legacy code and improve it. I attended one Legacy Coderetreat in the mean time, and it was quite interesting to solve the problem of a big mess of code.
At some point back last year I got in touch with Corey Haines and Adam Goucher. We bounced some ideas back an forth, and I refined them later with Adrian Bolboaca to yield a Coderetreat for testautomation code. Now I am happy to announce the first Testautomation Coderetreat in Munich on June 2nd.
Continue reading Coderetreat goes testautomation