Saturday, June 21, 2008

Distributed Development Disappointment

In this post from last year, Mark Levison discusses some of the issues that arise from having a distributed development team. This really hit home for me, since I completed a project where we had an unusual case of working out of two distributed locations.

I knew that it was going to be a challenge and I did not like what I was getting myself into, but there was some history behind it, and before going further I should try to provide a little background to explain why a distributed strategy was chosen. Sometimes it sounds like common sense, unless you have a real deep understanding of software development, so I can see how this situation arose.

One team at location 'A' were strong in specific skills and had built up a product over a number of years. Our strategy was to change the direction of the product, introducing a new technology, which was familiar to developers at office 'B'.

The project was extremely tough but did manage to deliver a working product, but the teams at the different locations never really gelled. Its not surprising really -

From team 'A' perspective -
1. Felt threatened
2. Left out of important decision making
3. Couldn't hear many of the meetings on the phone call - effort led from team 'B' location (many more staff and office space available)
4. Didn't understand why some decisions were made when they had much better background knowledge


But, there were also some other reasons from the other team's perspectives.

From team 'B' perspective -
1. Team left to figure out integration issues on their own
2. Little help was forthcoming
3. Only one who wanted the project to succeed
4. Couldn't understand the resistance

Now, you're saying, so why not ship the folk at office 'A' to office 'B' - well family life and other commitments. Why didn't we do something about the communications problem - it was raised, a new phone ordered and then promptly turned down based on cost.

In my opinion, there is no simple one size fits all remedy for this kind of thing. It simply doesn't work. Yes, we managed to succeed, against the odds, but it was like pulling teeth and I wouldn't wish it on anyone. I do not blame or take sides at all in this, it was just circumstances.

Of course there are consultancies out there that claim they can make it work for you, and maybe they truly can make the experience less painful, but I'm guessing the real reason is because they want to bill you for their time.

Retrospectively, I would have ensured that all the information was in the hands of one location or the other, but I was not involved in the earlier stages of the project and there are a few uncomfortable hurdles to overcome before that suggestion could be a reality. As usual, everything comes down to people problems and how they communicate. Excessive use of email, IM and even the phone as poor second cousin to face to face communication has done more damage to human relations than anything else - especially in the corporate world. Having said that, the way my daughter miscommunicates over the web, maybe its really lousy in the social networking world as well. Guess I'm just from a different generation.

3 comments:

MoffDub said...

Amazing how what seem like the little things, like phones, can make a big difference in this field. Communication, particularly, is a hardly noticeable aspect of a successful project, but at the same time can sink you.

Aside from that, maybe the situation could have benefited from one of the following model-integrity patterns coined by Eric Evans:

* Shared Kernel: teams agree to share a subset of code and co-ordinate changes; in this case, the business logic of team A's product

* Customer/Supplier: team A agrees to be an upstream supplier of an API for downstream team B

* Conformist: team B conforms to the existing practices of team A

* Anti-corruption Layer: team B builds its own system with new technology and integrates with team A's existing, now "legacy", system, translating between models, if necessary

Mark Levison said...

Thanks for the link. I've just taken a good look around your blog. Along with picking up a subscriber you've also inspired me with a few new Scrum Smells.

Andrew said...

Mark, thanks for following. As with most blogs, its very personal and opinionated, but if my experiences can in any way get people thinking, then I am happy.