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