Take your time for improvement

Dave Hoover just raised an interesting point on personal improvement: Spend 50% of your working time on personal improvement. Basically I found myself in that blog post. Since about two years – since I have been asked for taking a leadership responsibility – I am constantly reading books in my spare time. Over the last year I started to read several mailing lists and blogs. I am thankful to have married a wife over the last year that is patient with me (I wonder how long she’ll stay that way).

What shruggs myself is the fact that Dave states it takes about five years to see the return on that investment. Five years seems to be a very long time. Reflecting over my life so far I must say, that I have spent more than five years already on improving personally. At the age of 15 I choose to lead a youth group at our local sports club. In my spare time I gave swimming lessons over the past thirteen years and also grew into the leader role at my sports club over the past 15 years. In the meantime – while making my diploma at the university – I was involved in three clubs at a time. Through all these I made great experiences in leadership and organisation. Over ten years I participated and helped to organise helpers for our season openings of our local open air bath. This was a great time and helped myself improve for my current job.

On the other hand I even worked for money at a local store during my university years. There I had to organise the order process for soft drinks, juice and later even alcoholic drinks. I had to organise according to market and seasonal demands and manage the surpluses. In the end there was a major rebuild of the store where I was highly engaged in. Over the years I had learned how to work together with my colleagues and contribute to critical work that is daily business at a local store.

All these experiences were a major part of the preparation for my current position. In the past I have been working with people, for people, sometimes even against people if I was convinced from the opposite. Taking some spare time now to support my journey towards mastery is just a little duty for me. Personally I just took out my calculator and tried to calculate the time that I might have left for my family with Dave’s proposal: One week has 168 hours, 6 hours per sleep each night, two hours for getting to work and back, two hours for eating, 40 hours of work, 20 hours for personal improvement leaves you with 42 hours of time you may spent with your family and for leisure activities like sports. This seems ok to me, but don’t blame me for my naive assessment of the situation. (My wife is working in retail sail and usually does not come home until 9pm due to this, so don’t try to project my situation onto you.) Take Dave’s point into account to at least try it out for a while. Personally I consider myself more of the former group of people in his statement:

I think it would be silly to try to force yourself to do it, you’d end up burning out. Really, I’m talking to two groups of people. To those who are already spending their spare time on becoming a better developer, I want you to know that your efforts will pay off, but understand that it will take between 5-10 years to see the most significant benefits of your efforts. To those who want to become a great developer but hold themselves back out of fear of failure or hard work, I hope to inspire you to give it a shot.

and Dave made me feel good about it.

Grading, evaluation and good code applied to apprenticeships

Today I had the opportunity to talk about some of the skills that I needed to learn while becoming a leader. The girlfriend of a brother-in-law is a teacher for primary school. Today I got into a discussion with her about grades in school. During the discussion I thought on where do teachers get to know how to grade a student. Since I had one in front of me, I took the opportunity to ask directly. She stated that there was no education or course during the time she spent on university on this. In Germany there are two years of traineeship for new teachers mandatory. She stated that during that time she learned just a few regarding the grading process. So most of the grading is done on intuition. Interestingly her description reminded myself of the very first few months of my group leader time, during which I had to do a performance review for one of my colleagues. No one had taught me up to that point how to do it, I just had one review so far for myself. There was no course back in university where I could have learned it. During my last ten to fifteen years I have been a swimming trainer and lead the swimming department at our local sports club for some time, but clearly this was the only opportunity where had experience from leading people – and these situations are less context-driven due to its nature of a teacher to a student. Even today it is still hard for me to reflect whether or not I take the proper intuition into account. (The bad news is that most of your colleagues will not take the courage to inform you of your bad decisions.)

Right before starting to write about this article, I noticed that there is a similar case for good versus bad code. What did I learn at the university about code? What had I learned about bad code? Good code? Most of the insights I have today come from my experiences at work. When I started about three years ago we had an undesigned test automation framework. There were lots of script functions without intent. Whenever I needed to put in something new, I had to go out look for the right place to do so. Additionally I was never fully aware if there already was a similar function that I should have been extended, decomposed, refactored to meet my new requirement. This was a mess. Over the past year I was able to get rid of this grown framework and introduce and grow a new one.

We focussed on good aspects of code there. Using test-driven development, refactoring and regular reflection while evolving our classes. This was a good practice and we even tried to avoid most of the deficiencies from our previous experiences. Over the last year we had some contributions from a team that did not follow your initial approach. The result is that there are currently two ways to do things. When inspecting the code I can now see the difference between good code I wrote, bad code I wrote and very bad code from that I permitted to be included into the code base. (There was an up in the findbugs remakrds, a down in the code coverage and an up in the crappyness trend after the commit operation. The bad code was visible.) The main problem is that my colleagues do not seem to bother, where the broken window rule comes in. There is much work left to do and I know that I will have to take the responsibility to clean up this mess.

The point that is striking for me is, that there is no education on these things that matter most during day-to-day work. You do not get taught the stuff to grade your students. You get able to do so by getting experiences, intuition and your own guts and hunches. Similarly there is no education for a good or a not so good worker. You have to trust yourself here. The same goes for the cleanliness of code. Despite the books I could mention (the one with just that name), there is no preparation in university for clean code. Similarly there is little to no education on good tests or not so good tests. From my perspective a major challenge for craftsmanship – be it software craftsmanship or even testing craftsmanship – is to teach these difference in an apprenticeship. This is our profession and our job to do in the years to come.

Testing in the days of Software Craftsmanship

Matt Heusser came up with the idea of the Boutique Tester. While reading through his article, I was wondering about the same striking question that arises in me since the early days of the Software Craftsmanship movement: Where are testers going to be in the Craftsman world?

Some months ago I started a series which I called Testing focus of Software Craftsmanship, covering Values, Principles I and Principles II and in addition I have planned an entry on Principles III, that I did not conclude so far. Most of the stuff in it I took from Elisabeth Hendrickson, Lisa Crispin, Janet Gregory, Brian Marick, James Bach, etc., etc. In this series I tried to raise an understanding of the testers role in the craft world while just restating the lessons most Agile teams already learned. The reason that I did not yet conclude this series is that I came to the realization that there seems to be no clear understanding of the sticky minded in the craftsman worldview for me.

Reflecting back on the lessons I learned from Agile methodologies like extreme Programming, Scrum, Crystal or Lean I remember myself being a bit jealous. Programmers were taught to use test-driven development, pair programming, big visible charts, planning poker. For me they seemed to have most of the fun. The tester simply does testing – the stuff they always do. As long as they don’t get into the way, this is wonderful… It was striking first, but when I realized that there are definitions of Exploratory Testing, Pair Testing, Retrospectives, etc., I got aware that testers also have fun activities.

A while back I proposed to rename the Agile testing school to the example-driven one. After getting some feedback from peers, I realized that there seem to be no room for school-mindsets in the Agile world and care for naming in the other schools. My initial motivation to rename the Agile school was driven by the realization that the Agile view on testing seem to be a good one for craftsmanship either. While my reasoning was based on poor assumptions, I started to realize a bigger argument behind this.

The bigger argument behind all three previously described situations is from my point of view that Software Testers have defined their craft long, long ago. Jerry Weinberg wrote in December about the way unit testing was done in the older days. Over the years there have been several thought-leaders appeared for Software testing. (I refuse to name a few here, since I know I’m too few in business to give honor the right ones.) Over and over the craft of software testing has been discussed, defined and found anew as the latest approaches to Agile testing teaches us. Just a few months back there was a heavy discussion on why Agile testers just define the terms that context-driven testers already teach since decades.

What is the difference between Software Craftspersons and Testing Craftspersons then? Testers know their craft from decades of experiencing and definition. There are more than enough books out there that teach good software testing just as not so good techniques. Software testers have most of their set of tools together to start leading their craft. For the development world this is not as true. Over the decades programming languages have come up and fallen down. Programming techniques like assembler, structured programming languages, logical programming languages, object-oriented programming languages, functional languages. The craft of software development seems to be more fluent to me as the craft of software testing. You can nearly apply all the testing techniques found in the books to your software, even to real world products as an Easy Button.

My point is that Matt raises a good point in his Boutique Tester article. Testers can directly go out and provide their testing services, gaining experiences over the years in order to improve. Maybe they can also take apprentices to teach the lessons they learned over the years. Basically I assume his proposal could work, though I’m concerned whether I would like to view myself more as a tester-developer or more as a developer-tester. In the end I think what matters most, is that there is only us and testers and developers form some kind of a symbiosis, just as automated and manual testing does. It’s a good thing that we’re not all generalists, but we should keep our mind open for different views of the problem at hand to compose an improved solution to it.

Facets of an Agile Team

Brian Marick started a series of blog posts on the seven pillars of an Agile team. Brian, Chet Hendrickson, Ron Jeffries, Robert Martin and James Shore came up with seven basic aspects of an Agile team:

  • Product sense
  • Collaboration
  • Focus on Business Value
  • Supportive Culture
  • Confidence
  • Technical Excellence
  • Self Improvement

Brian already started a first description on Product sense with more to come.

His description on the spider graph approach used during retrospectives reminded myself on the A Better Team questionaire based on James Shore’s and Shane Warden’s book The Art Of Agile Development. Since James contributed to the seven items, I believe this is no coincidence.

Three stone cutters

Ivan Sanchez put up a blog entry on a parable: Three stone cutters. He challenged my thoughts with the following question:

Sometimes I have this feeling that we as professionals are frequently trying to be more like the [“I’m a great stone cutter. I can use all my techniques to produce the best shaped stone“] stone cutter than the [“I’m a stone cutter and I’m building a cathedral”] one. Am I the only one?

Due to the analgoy I felt the urge to reply to this question with Elisabeth Hendricksons Lost in Translation and Gojko Adzics Bridging the Communication Gap. Most of the stone cutters I meet in daily business think they are creating a cathedral, while building a tower of babel. The biggest obstacle to efficient project success lies from my point of view in communication among team members.

This principle was discovered in his research on successful project in the 90s and early 2000s by Alistair Cockburn, see for example Methodology Space or Software development as a Cooperative Game (Warning: don’t get lost on his wiki site just as I did several times). Software Development is done for people by people. Since people are strong on communicating and looking around, software development as whole should strengthen this particular facet of us. A cathedrale is of no use if the entrance is on the top of the highest tower. Though during day to day work I see software developers lacking early feedbacks, that do not see the problem.

The industry I’m working in has a high changing rate of requirements. In the mobile phone industry there really are impacts from competitors, that you will have to react on to stay in business. For me this means to reduce the time to market for the product we’re building as massive as reasonable from a quality perspective. This also means to communicate with our customers spread all over the world in different time zones – even in distributed teams. This means that I need to find technical and motivational ways to bring people together that do not see each other on a day to day basis in the office. Just last week I we performed a Lessons Learned workshop on one of our products, where our colleagues in Malaysia took there web cam the first time and showed us how the world was looking outside their office. (It was during a refreshening break, so don’t get wild on wasted resources, my dear boss.) This lead to personal touch and a lower personal distance between the two teams – at least during that session.

Anyways I wonder why these moments happen too little. Instead I see teams – erm basically groups of people – working without communicating with each other though they need some information from the co-worker directly near to them and wondering in the end why there is an integration problem. Another point is the problem of open interfaces (lacking communication of protocols and the like), open scope (lacking the communication of content of the project), open everything. Clearly, for me it seems there is no way to communicate too much, it’s more the opposite that I bother about.

Stuck in mind models

Last week I had an experience outside work, which I could relate to work. Finally I decided to share this in my Journal. Beside remaining posts in this category I decided to make this one public.

On Tuesday I had a discussion with club mates about training in swimming. In my city there are several swimming clubs combined together into an organization for supporting talent scouting. About ten years ago I noticed that the philosophy of my swimming club and the philosophy of the clubs around us differ in one particular point. Most of the other swimming clubs following the rule to have training lanes separated according to the age of the trainees. From 6-8 the kids shall learn how to start swimming, from 7-9 they learn back stroke beside breast stroke (which they started with), and so on.

Our local swimming club follows another philosophy. We pretty much believe that each step needs to be taken regardless of the age of the trainee, but based on his achievements so far. A quick learner at the age of 12 can quickly move forward to the fastest swimmers, and a more slowly learner might be trapped on one training lane for two years or longer.

Jerry Weinberg taught me to be aware of the threat/reward model of modern psychology. Therefore I won’t argue one over the other. Instead I say that there are some advantages to one form of teaching swimming and organizing a swimming club (technically) over the over and vice versa. The point I would like to raise here, is that you may get stuck when sticking too much with one model. This one I noticed in the discussion we had last week. There were several pleads during the discussion, where I could not understand the argumentation, since I had a different model in mind. Basically I realized that the other parties seemed to be trapped in their model, that they did not see the problem. Yes, this is an occurrence of the No-problem syndrome.

How does this hold to work? Currently I need to prepare a discussion at work, where one of my colleague has a model of how stuff works in mind and I have another one – a different one. We tried to get an approach already last year, but soon got stuck in the discussion on a more personal level. Our superior decided by then to refuse the discussions and have both parties follow their model. During the retrospective of one of our projects the point was raised to stick to one approach to exchange team members from both groups more easily. I take this point very seriously, but based on the past year struggle to prepare for this. Both of us seem to be stuck in their mind model and do not see the solution through copulation. While reading through “Becoming a Technical Leader” I already realized this one, and decided to prepare a spike solution to have a better basis for further discussions at hand.