Category Archives: Leadership

Technical and personnel leadership

Team and coaching challenge

During the last view weeks I was able to come up with a challenge related to teams and coaching. On Thursday I decided to put this challenge up on my blog after having discussed some possibilities with James Bach, Matt Heusser and Michael Bolton. Personally I would like to try to apply Weinberg‘s Rule of Three Interpretations:

If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.
(Quality Software Management – Vol. 2 First-Order Measurement, p. 90)


Some weeks ago James Bach challenged me on a conversation about three example situations where being aware of the context at hand is unneccessary. The answers boiled down in general to situations in which the responsibility for the contextual decisions is taken by someone else like a swimming trainer takes the responsibility for the context of her students. One week later I was involved in a team, where I was wondering if the team members were being made context-unaware over a larger timeframe.


The team is working for a company which has made some changes to their development processes in the past two years. Beforehand each project team had a project manager dealing with the schedule and all the team issues, while software development and software testing were tracked separately most of the time each having their own lead in the project. During one larger project for an end-customer the problems piled up thus far, that the whole development team got stuck – really stuck. Everyone seemed to be involved into that project for one reason or another. Due to the high amount of escalation there was always a “topic of the day”, the most hurting issue, and it was rather hard to focus.

Some months later it was decided to organize the projects in a different way. Similar to a Scrum of Scrums teams were sub-divided into more logical teams with one team above them to steer the project towards its goal. Among the teams there are roles defined like Project Manager, Technical Lead, Architect or Quality Lead. The structure proofed to be better during the next few projects. Therefore a most recent project choosed that structure, too.

The Team

The team had to steer a project over four countries within two different timezones with a maximum of seven hours time difference. The customer gives feedback in a language that just a few of the team members understand and is not able to participate in requirements. The team that steers the project is spread around the globe. Team meetings are taking place over Skype solely due to technical problems at one location. During these meetings one person speaks about 80 percent of the time, rephrasing most of the remaining people. Most of the decisions are kept unaddressed during the meetings. There is little to no documentation, little to no planning, but the person speaking 80 percent of the time seems to have everything in his head. After half a year there is the first delivery to be made. One month before this date there seems to be little to no testing done on critical components of the software. The quality responsible person is a rather silent one, just speaking one to two sentences per meeting. Due to the separation of development and testing, the developers do not feel responsible to support the testing. Along the project there were just a few testers involved overall. The developer:tester ratio was about 2:1.

The Challenge

Given the informations from above, which particular situation would you observate to gather more informations? Suppose you got into that project, which three things would you change immediately? How? What would you tell your boss about that project? What would you tell members of that team? Giving the history of the company and the history of the project, which suggestions would you make? Feel free to provide your answers in the comments or drop me a line via mail. (Maybe I’ll come up with some follow-up questions.)

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.

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.

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.

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.)