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

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