Category Archives: Leadership

Technical and personnel leadership

Leadership, Testing

Inter-company collaboration

Leave a comment

Over the past few weeks I realized a problem in one of the projects I’m currently involved in. Our customer is located in Brasil and has contracted an external company for the integration into the legacy software system culture and accteptance testing of the delivered solution. They maintained the legacy system for the last years and have very good business knowledge about it. This company has contracted us in order to deliver that system. So far, sounds great, doesn’t it?

Not that much. What has happened over the last one and a half year is the following. Our company just gets vague informations regarding requirements from the customer. We give lots of information, but they often do not make sense. The company that contracted us knows more about the legacy systems, but does not provide this information to the competitor – to us. Therefore it was a torture to get the system right after long chains of late change requests over the past month which basically ended up in rewriting everything we had. Sounds worse, now, doesn’t it?

But I’m not quite finished. What now unfolds is the need for my company to deliver the system in order to make money with it in this very year. The end-customer has some money he wants to spent for a new system and we are in long term relationships with them. In order to finish this off together with data conversion in this year, we need to deliver the system until midth of September latest – we thought until last Friday. Now the middleman company made the proposal to postpone production date for two weeks and asked us to deliver any priority one blocker bugs in three calendar days – while dealing with the pending change requests, too, of course. All together they have sucessfully exercised over the past few months five percent of the tests they planned. The others are blocked or got some errors. Curious, isn’t it?

It gets better. We have so far around ten bugs from the opened in our bug tracking system, five currently fixed of these, three fixed by tomorrow and the remaining two should be dealt with over this week. Now, the question today arose, how come we just get this few number of bugs back if just five percent of the tests were sucessful with about 75 percent being blocked? (An unfair question to ask, but let me continue.) A colleague today arrived back from on-site visit and he explained that the middleman company seems to open twenty bugs, if we fix ten. When we fix those twenty, they’ll probably open fifty new ones and so on. Sure, this is an absence of trust due to remote location of implementation teams, etc., etc. The point that strikes me, is that the end customer who will be paying both our companies in the end, is listening to them. Therefore we are asked to do massive overtime on the weekends, in the late nights (5 hour time difference is a tough working.), etc.

Oh, of course, we already tried the obvious: Working together with the other company. So far it did not work. We’re continuing to try, but with semi-success so far. When put aside their testers a technical expert for our system just gets asked questions about how to export a shell variable or how to use that key combination in vi (should use emacs from my pov). The striking point is that the other company does not realize the mutual benefit situation we should have. Now comes the interesting part. Today I was reminded on the negative aspects about metrics like “how many bugs do you find?” Some weeks ago the founder of the Miagi-Do school, Matthew Heusser, pointed myself out to a paper from Cem Kaner on metrics: Software Engineering metrics: What do they measure?. Today I was very, very surprised that in case of that other company, you don’t seem to need those metrics to do harm to a project. All you need to do is basically give that middleman company the feeling that they won’t be needed any longer in mid-term.

This reminded myself of some terms of some of the manifestos around:

… and certainly there are more of these. But what I noticed today is quite the opposite. Please share your comments with me.

Leadership

Meeting Principles

Leave a comment

Yesterday I ran over a list from Esther Derby on how to improve meetings when you’re not in charge. Funnily I had compiled a similar list at our company some time ago divided into participant improvement actions and moderator improvement actions for meetings. The list is thought as a motivation compiled of optional things I can do to improve the meeting. The basic principle behind this is that I am allowed to do this and that with the intention if I’m not doing these things, I should not complain about ineffective meetings. Here is the list. I appreciate any kind of feedback.

As a participant of a meeting I am allowed to

Preparation

  • … ask for a meeting agenda
  • … prepare contemporary for the meeting
  • … decline an invitation
  • … look forward to the meeting

Performance

  • … ask for an introduction of unknown participants
  • … reflect on the agenda and the goal of the meeting
  • … visualize
  • … value contributions of other participants
  • … get clarification on contributions of other participants

Wrap-Up

  • … offer appreciation to the moderator or facilitator
  • … work through the protocol
  • … reflect on the course of the meeting
  • … discuss personal discomfort

As a moderator/facilitator of a meeting I am allowed to

Preparation

  • … provide a meeting agenda
  • … communicate intentions and goals of the meeting
  • … choose participants wisely and personally get in touch with them
  • … prepare myself for the meeting

Performance

  • … feel responsible for the success of the meeting
  • … welcome participants
  • … repeat the goal and the agenda of the meeting and ask for feedback
  • … help meeting participants work effectively and efficiently
  • … remind participants on agreed conversation rules

Wrap-Up

  • … ask for feedback on the grade of success from participants
  • … thank everyone for the investment of their time and knowledge
  • … take care to monitor follow-up actions
  • … reflect on personal facilitation and moderation abilities
Leadership, Software Craft

Misunderstood metrics

Leave a comment

My Miagi-Do school mentor Matt Heusser placed a blog entry on metrics today. Since I haven’t got the clear problem with metrics, I needed to contact him to fulfill The Rule of Three Interpretations. In our conversation I realized that he was referring to a concept, which I haven’t been experiencing in my three years of working as a software tester.

Generally spoken I was referring to metrics as using FindBugs, PMD or cover coverage tools on your software. For some time we have been using these for the framework that we grew on top of FIT for testing our software product. In combination with Continuous Integration you can see improvements and you can see where your project currently is. Is it in a good shape? Where might be holes? Which codepaths are not tested well enough? This feedback is essential for management to make the right decisions about the risks when delivering the product against your test results.

On the other side Matt refers to metrics on a different level. If your annual reviews and your salary gets decided upon management metrics, these are evil. The struggle I have is, that I am in the situation that I never worked in such a system where my personal performance and salary was based on some metric. Basically I can think of situations where this is evil. Here are a few:

  • A software architect getting paid by the number of architectural pages written.
  • A software developer getting paid by the number of lines of code.
  • A software developer getting paid by the number of software products finished.
  • A software tester getting paid by the number of tests executed/automated.
  • A software tester getting paid by the number of bugs found.

Speaking as a software tester, I would use a tool for generating the easy test cases that are easy to automated (I have been down this rabbit hole, I just realize, but wasn’t getting paid based on that) or use a spell-checker on our logfiles (I always wanted to do this, but didn’t because there are more severe problems than the correct spelling of some debug log messages). As a colleague uses to put it: When you measure something, you change the thing you’re measuring. Be careful what you measure, because it just might improve. When I understood these different meanings of metrics, I also got the problem.

Some time later I found the origin for the discussion. It is a recent statement from Tom DeMarco reflecting over 40 years of software engineering and measurements. Take the time to read. Here is the portion which I found most interestingly:

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

I believe that this will work. At least it will keep the team from being micro-managed and over-measured.

Leadership

Team and coaching challenge

Leave a comment

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)

Prequel

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.

Introduction

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

Journal, Leadership, Software Craft

Grading, evaluation and good code applied to apprenticeships

Leave a comment

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.

Leadership, Retrospectives

Facets of an Agile Team

Leave a comment

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.

Journal, Leadership

Stuck in mind models

Leave a comment

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.

Leadership

Mapping practices for Personnel development

1 Comment

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.

Housekeeping

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.

Development

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.

Conclusion

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