Some time ago, James Bach blogged about quality being dead. At that time I put up a response to that blog. Skip forward two years, and I might have shifted my mind. Asking the data question, what have I seen or heard that led me to this new conclusion? Absolutely worth a full blog entry from my point of view. So, here it is.
- Set the Stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
I was able to attend a retrospective training with Diana Larsen in July this year. One activity I noted down back then was called “goes-into, goes-onto”. As I prepared for the retrospective, I decided to use that activity. Unfortunately I couldn’t find a reference or a write-up for this insights generating part of a retrospective. I decided to write down what I did, and my experiences with it, so that others won’t fall for the same problem in the future.
You know what happened on the March 7th 2009? According to Wikipedia, the Real Irish Republican Army killed two British soldiers and two civilians, the first British military deaths in Northern Ireland since The Troubles, and the Kepler space observatory, designed to discover Earth-like planets orbiting other stars, was launched. Right. But there was also something happening in the software development sphere. You don’t remember? The Software Craftsmanship Manifesto went public. Amazing.
Paul Pagel announced the publication on the Software Craftsmanship mailing list using the following words:
In December, many of us met in Libertyville at the first ‘craftsmanship summit’ with the intent of establishing a set of principles for Software Craftsmanship. After the summit, the conversations continued on the mailing list, finally culminating in an elegant summarization of our thoughts by Doug Bradbury. Today, we put the manifesto up on the web as a statement of our values as craftsmen. I’m inviting you, as members of the software craftsmen community, to view the manifesto and, if you choose, to sign it.
This is an exciting time for all of us, a result of the participation and thoughts of everyone, both at the summit and in the subsequent discussion online. I want to thank everyone for carrying these ideas forward.
About one week later, Mark Levison had interviewed some of the folks who were involved in the early days of the movement, among them was Micah Martin who found the right words when he saw that 1500 people already had signed the manifesto after just one week:
As of today, there are over 1500 signatures on the Manifesto. 1500 people are fighting against “crap code”. Those who have been fighting “crap code” now know that they are not alone in their fight. Those who write “crap code” now know that there are 1500 people fighting against them.
The Manifesto is a gentle push away from “crap code” and toward craftsmanship.
That quote immediately sprang to my mind last Saturday when I head home from the first German Socftware Craftsmanship and Testing (un)conference. With 52 participants from at least five different countries, we had 52 people getting together in order to carry on that message, in order to fight crappy code.
No wonder then, that we had a lot of coding sessions. Sandro Mancuso for example led through a session using the Nine Rules from Jeff Bay’s Stefan Roock led through several coding dojos on the OpenSpace day.
But beyond that, I was glad to see other topics that are sometimes forgotten when speaking about craftsmanship. In fact, if you take a closer look on the manifesto, it states that we want to raise the bar by growing communities, and helping others learn what we do, and how we do it. That said, there was a talk by Fabian Lange on performance, one by Uwe Friedrichsen on architecture, one by Pierluigi Pugliese on soft skills for developers, and my session on self-education in testing. We also got together in a fishbowl on software craftsmanship in order to seek opportunities to go further from the starting point of SoCraTes, and grow communities all over the country. We had Uri Lavi who leads the user groups in Isreal as well as Sandro Mancuso who runs the London Software Craftsmanship user group.
In a call to action on Saturday we decided who was interested in running a meet-ups in the next two months in different locations all over Germany. Just in case you live nearby Hamrbug, Osnabrück, Münster, Bielefeld, Düsseldorf, Köln, Karlsruhe, and Frankfurt keep your eyes and ears open. There’s probably soon someone starting something, announcing something, or just getting together in a bar to discuss the topic of Software Craftsmanship, and what it means to us.
I was really impressed. Not only having been around in those early days on the Software Craftsmanship mailing list back in December 2008 when it all started, but also being in the loop of discussions around the Ethics of Software Craftsmanship, having contributed to the Wandering book, and having helped organizing this event (please send the real kudos to Andreas Leidig and Nicole Rauch who mostly put together this conference alongside Bernhard Findeis, Martin Klose, Marc Phillip and myself), it was so amazing seeing this become real, and kicking off for next actions to grow a community in Germany.
I look forward for more to come after this inaugural get-together of the German Craftsmanship community, and will surely report on the things that are going to happen.
At the ALE 2011 conference, Rachel Davies held the first keynote of the day. She reflected on 10 years of Agile software development, and what this probably means for the future.
In the past week I started a new blog – this time in German. I will keep both my English and my German one, but might write less here in the near future. If you’re interested why I started a German blog, I left some reasons on first post. In case you’re unfamiliar with German, you might want to read on.
I dropped out of English classes in the 11th grade. Yeah, I did that. Skip forward 15 years, and I find myself having written several articles in English, contributed a chapter to a book, and eventually wrote one in English on my own. How did I do that? I think that an English blog made a contribution to that.
Now, as I want to know whether I am capable of publishing even more in German. I see some demand for that, and I see a difference between my English-speaking audience and the problems in Germany I face. The second and third entry on my German blog for example describe the issue of congruent communication as well as how to define a problem, and that not the problem is the problem, but our inability to cope with the problem.
That said, I will keep both blogs, and will deal with different topics on the different blogs. I won’t translate between the two most of the time – but leave myself the option open. So, if I raised your attention, you wouldn’t be the first to use an online translation on my blog, I think. :)
As we have received fewer submissions so far than we hoped, I think I need to write something about my expectations as I consider myself the content-owner of the German Agile Testing and Exploratory Workshop. What strikes me when I visit teams claiming to do Agile, I often find their teams doing either of the following:
- Exploratory Testing – applied bad, without debriefings, charters, and without the collaboration that would make it more structured, and provide product owners and managers with the information they are asking for
- Test Automation – mostly done by programmers or testers who have a strong background in programming, sometimes not even beyond unit tests on an integration level between multiple classes
As I see immense drawbacks focussing on one or the other of the two approaches, I am convinced that Agile teams can do better by using a combination of both worlds. Exploratory Testing alone might leave an Agile team with the problem, that exercising all the tests becomes a burden over time – especially when programmers lack proper unit tests. Test Automation – even with ATDD – alone ends with the drawback that for human obvious holes are left in the software.
That said, I am interested in good applications of Exploratory Testing on Agile teams, what helped them succeed, and what could help them manage their Exploratory Testing. I am also interested in Test Automation topics, how they helped Exploratory Testing gain momentum. Finally, I am also interested in talks about how to prepare the tester’s mind, and where the connection between traditional testing techniques and Agile testing techniques might be.
So far, there is a strong balance towards Exploratory Testing in the schedule. I like this to some extent, but I would also see more attendees on Test Automation, ATDD, BDD, you name it. So, if you think you have something to contribute, drop Maik or myself a line, and we may have a discussion about that. IF you’re unsure what GATE will be, read my initial blog entry on it.