A while ago I joined a project and were part of a web developer team. This team had many different challenges on its plate.
First of all the project members were scattered among different regions of Germany and Europe, secondly an almost not talking development lead and thirdly problems communicating within the co-located team.
One of the developers for instance crammed earplugs into his ear canal, which definitely did not enhance the communication in that room – one guy with earplugs, the other one with almost 30 seconds of speech time within 10 hours.
The other developers would have been more communicative maybe, if they would have been working at the same time like the group of three which worked in the office. As for improving the communication I tried to introduce something like a Jour Fixe. Which was introduced, but under protest. Each and every hour was counted – and thirty minutes once a week multiplied by the amount of developers leads of course to unproductive several hours a week – that’s for sure.
Still – and that’s the surprising thing – the people where able to deliver some work. Something working work, one could say, if the grammar wasn’t totally wrong. This was due to high fragmentation. Every single member of the group had it’s specific area in which he had gathered experience in the past – and the project leaders were pretty much aware of the specific skill set. So every fragment was passed to the right specialist – and if there wasn’t one, then depending on criticality of the item, the cheapest, most available or most capable developer was chosen.
Standard operating procedures combined with a rare but still happening review lead to a certain quality of code, in terms of documentation and functionality.
Still there where also obvious problems. The fragmentation and the absence of communication lead to misunderstandings, double work, rework, triple work…and endless list could follow, which I will summarize as “waste of time and money”.
Another issue was that all these fragments must fit together nicely. This is achievable, if one uses a framework for instance. Unfortunately a dozen programmers need more than a framework to deliver code which fits together in terms of units, integration and system tests. It was daily routine to fix several bugs in the live environment of a highly frequented web application.
Team spirit was not present. So everything which an individual could achieve was achieved. Not more. Where as a team you would be able to generate something of greater value than the output of one developer multiplied by twelve, this non-existent-team of hermits achieved actually less.
What speaks for this kind of group technique is the fact, that you can clearly say: We do not produce administrative overhead. Every developer is 100% of his day programming – no talking, no endless meetings, just a requirement and he goes ahead. Calmly, somewhere on a hill, circumvented by his code which hopefully fits to the rest, once it’s finished. Of course one would have to admit, that these 100% are…slightly touched by the “waste of time and money” thing.
And one would have at least to think about the fact, that the team as such is in the best case developing as good as a dozen individuals, but not as good as a team consisting of twelve developers. The still amazingly average output after all is due to
- Good sizing and delegation of work packages
- A highly interested customer, with good basic understanding of the underlying technique and a good vision of the wanted functionality giving frequently feedback
I have to admit, that when I begun writing this article I wanted to smash that working environment verbally to pieces. But while writing this I think that even an in my opinion worst case scenario has its hidden assets.