Practicing relevance

On the Software Craftsmanship conference in London End of February Micah Martin presented a session on where he presented an implementation of Langston’s Ant in Ruby. As an introduction he raised the point how important practice for a software craftsman is. He used his background in Martial Arts as a motivator where Katas are used to fit into uncomfortable positions in order to gain flexibility for the fight with an opponent. By over and over practicing these fight-unrelated moves, the aspirant learns for the fight. (Actually I remember the first Karate Kid film, where something alike happens, when the kid needs to paint a fence etc.)

By that time I did not fully agree to Micah’s point on practicing. However I made a note on my personal digest by then to research something suitable for me. Since I don’t have a background in Martial Arts, but in Swimming competition and as a swimming trainer, I was looking for analogies like how I teach kids to learn swimming with some learning chains getting from the easy to the complex and from the well-known to the unknown. These ideas did not quite match the Kata analogy from Micah, since they were related to how people learn in their minds and the bridge towards software development seems to be too far away here.

During the last week I found a better suitable analogy however, which is partially motivated from my experiences in swimming. As a trainer I need to be able to save anyone from drowning. While this sounds rather reasonable since I get to train kids that are entrusted to me by their parents, during the latest courses to fresh-up my knowledge on water-rescue I realzed, that the training for the german DLRG groups – the german baywatch – does over and over practice how to rescue someone from drowning. While the one being rescued might attempt to reach your neck in panic to just save herself, the life-saver might end up needing to save herself as well. While there are some grasps to free oneself out of such situations, the DLRG practices these over and over in order to be able to use them naturally when getting in a panic situation – since every second counts be then.

Similarly during first-aid courses which I needed to take several times as well I was told to practice reanimation process and how to get an injured person into recovery position. When people get under stress they forget what they have learned, if they did not practice over and over. Similarly when a software project gets under stress, people may forget to apply test-driven development, refactoring and design patterns and introduce technical debt. On the other hand by practicing seemingly unrelated software Katas in order to improve your tdd skills might enable you to excel your work even in serious situations. As for first-aid and water-rescue practicing, knowing and maintaining software development practices, but not having to use them every day, makes myself feel safer and relaxed.


Obtiva and 8th Light are currently stressing out Software Craftsmanship in an apprenticeship program between the two. Jim Suchy currently writes down experiences from each day on their blog. The entries for the first three days can be found here, here and here. While taking out the links for this entry, I also ran over Colin’s Apprenticeship.

As it turns out I ran into the idea two times during the last few weeks. One of our business analyst from our product development department stated some weeks ago that he has been asking for taking some kind of apprenticeship in the System Integration department in order to get to know the product he is defining. While the technical view of the product is rather clear to him, he stated that he is unsure of the actual use cases during System Integration work, where we configure most of the system for the end customer.

Some weeks earlier I ran over the idea as a tester to work on-site for your end customer in Lisa Crispin’s and Janet Gregory’s book. From the viewpoint of a tester I would be able to follow the mission to deliver working software to the customer in a better way when I had some experience on how the product will be used in the day-to-day work. By attending call-center calls and participating while our product is used to sell product to the end-consumers of our customers, I would get a very good picture of the business flow and the motivation behind it. Exactly what Gojko Adzic addresses in Bridging the Communication Gap.

Today I sat down with a former group lead in order to identify what I shall present on FIT end of next week. While we were discussing things I stated that two of my colleagues will be on vacational leave for four weeks during summer this year, since they will become fathers. While discussing the bottleneck in which we will get by then, he made the suggestion to exchange one of his testers with my group in order to get deeper knowledge on how we use FIT as a testing framework. Personally I think of it as an apprenticeship program, that could lead in improved communications between our two departments. Hopefully something great is going to be built out of this idea – but I’ll try to motivate and follow-up on this idea.

Mapping practices for Personnel development

Influenced by Adewale Oshineyes session on Mapping Personal Practices, I lead a meeting on personnel development with one of my testers two weeks ago. Earlier this year I started to do some work on personnel development for my workers and we already had come up with four to six major categories worthwhile to consider as evolution points: Testing, Programming, Product Knowledge, Teamwork, Technical Leadership and Leaderhship with personal responsibility. Incluenced by this previous session, we came up with a mind map similarly structured.

The colleague we drew the map for is rather junior. In the map you can see a division to the major categories mentioned. Let me try to explain on how we came to the final map.


First of all we build up the map with the personal practices of my colleague. Motivated by the flipchart page of our first session in January and Adewale’s session on mapping personal practices, we started off with the items my colleague already does to a reasonable degree and has already reached a good level in doing so. Our initial session was based on the Shu-Ha-Ri principle of Skillset development and we picked those practices where we agreed he had reached Ha-level already. For the Testing category this includes writing tests, bugtracking and bug verification and execution of regression tests on a regular basis. Related to our company’s products we identified knowledge for one of the major Sub-Products and one Component related to it that was built over the last year and my worker had tested heavily during this time period. Related to Teamwork we agreed on a great skill to support our developers and enabling team communications through direct contact and collaboration. I consider him to have huge strengths in these fields and respect him for this. He mastered a computer science degree with a minor subject in psychology, which of course helps in this field. Since he is rather on a junior level, there seemed to be no relevant practices for the programming and technical leadership category, so we left them empty.


We then started to discuss areas of improvement. Reconsidering each category, we were able to identify one point for improvements. For the testing portion we agreed on getting more knowledge related to User Acceptance Tests. Currently our teams have big problems with this item and on the last few Lessons Learned workshops during this year we realized that our company as a whole needs to improve in this field. Relying on his communication skills this is a good point to combine two areas, basically. Related to programming we agreed on the possibility to go out and ask for help when dealing with problems while doing some Fixture programming for our test automation. Here again I was happy to include his communication skills into this area of improvement by identifying this. Related to the knowledge of our product, we choose to get more insights into the second major component our Sub-Product has to deal with. This will not only give him a better overview of the value we deliver to our customer, but also enable him to find out hidden assumptions in the plug-ins we test for the Sub-Product 1 and that indirectly talk to Sub-Product 2. (I know, it’s hard to explain, if you cannot mention more context.) In the teamwork area we agreed on two major points for improvements in the whole organization and I think that he can help us work on these items a lot. We called this one Synchronisation. This is related to getting developers and testers to a common understanding of the solution, to include testers from the very beginning of the project and to include them in discussions about the solution. On the other hand we have co-workers spread all over the planet: Germany, Poland, Romenia, Spain, Italy, Brazil, Turkey, Ukraine, Malaysia. A usual project consists of people working in at least two countries. Therefore distributed collaboration is a major topic in our company. Related to his very good communication skills he can help us improve here. For technical leadership we both agreed that there needs to be improvement in the technical knowledge before starting a discussion here.


After finishing the mindmap, I was very proud of the result. During the next few months I will have to track the achievements in these fields, so we have again a discussion basis for the review we agreed to take place in early June. There is no impact on salary of the like based on the outcome. I just realized during the last year that I need to take care of my peers for personnel development since no one else did. Using mind maps on this improved the discussion a lot, I think. And I was able to incorporate his best skill – communication – into the remaining areas to help the organization as a whole. One side note I would like to add: Most of the practices and feedback came from my colleague. I tried to facilitate and help him find out ways to improve himself without demanding them. All of the discussion was of course done in collaboration, where the biggest contribution came from my worker. I also asked him afterwards if I will be allowed to publish it online here after anonymizing it. (I had to translate the german terms to english and get rid of and company’s product names.)