Managing the Development Process in a Global Environment

Introduction

There are, in my experience, 2 major issues that need to be taken into account when assembling regionally disparate development teams – team dynamics and time zones.

I'll also present 2 alternate ideas on dealing with global development teams to elicit further discussion.

This paper will not cover topics such as the methods, tactics and strategies that comprise the process of the project itself; rather it is about the people that are at the heart of any project and how to encourage them to work as a cohesive unit regardless of their geographic location or time zone.

Neither will it offer analysis on the cultural, language or vernacular differences between differing regions and countries. Although the primary focus of this paper is the US/UK relationship it should apply equally to any instance where a project is undertaken using teams located in different geographic regions.

There are, of course, some obvious and stereotypical differences between British and Americans such as work ethic, sense of humour, living environment, etc., but those are also outside the scope of this document.

Global Isolation vs Global Integration

This encapsulates the most difficult of all the problems that can arise with development teams separated by both distance and time and where contact is primarily by passive communication modes. It tends to foster an 'us vs them' attitude where, for instance, code becomes jealously guarded and any criticism is deeply resented by having been offered by 'them' and where, perhaps, applications that were seen to be the children of 'Team Ohio' are opened to 'Team Leeds' who then find a myriad reasons to suggest or make large changes or generally criticise the code thereby alienating the other team.

There is little that management can do to mitigate this for 2 reasons…

1. If it is a legitimate response then the decision has to be made to take over the work and bring it to the team that found the problems or revert it to the team that wrote it and ask for a rewrite. Either way the original team will be slighted and dispirited by this – they are demeaned.
2. If it turns out to have no validity or is trivial then the team that made the criticism becomes dispirited through having been seen to make a bad or misjudged call – they are demeaned.

This is 'Global Isolation' where regionally located teams, ostensibly working toward a common goal, are isolated from each other and run as disparate and, usually, competitive teams. This can be exacerbated by large differences in the size or age or experience distribution of the various teams especially where the only contact is by e-mail or telephone so that communication streams remain, essentially, faceless.

There is no compelling reason for one team to feel an affinity toward another where there has been no social contact.

The opposite of this is 'Global Integration' where there has been good social interaction between the teams and where faces have been put to names. It is much harder to criticise or put down someone you consider a friend and colleague and you are much more likely to help and have that help accepted as an objective criticism offered to further the goals of the project, when you have a personal relationship with that person.

This must be balanced with the somewhat banal aphorism that you will not like everyone you meet and not everyone you meet will like you. However, the fact that you know this person and have spoken with them face-to-face, have sat in meetings with them and, perhaps, had lunch or a drink after work, even in a group situation, ensure that the competition between groups becomes healthy competition that is predicated on successfully completing the project in cooperation with another team and not in spite of them.

The way to achieve this is straightforward – members of the team need to spend time (doesn't have to be too long) with the other team. Even if only one member of each team swaps roles for a period of time, this can have the same effect since they will bring their shared experiences and relationships with them.

I have seen many large projects fail because not enough thought was put into the people that make the project happen. It is far too easy to concentrate on the logical, physical and abstract requirements of the project whilst dismissing the people that make it happen.

In at least one project with which I was involved, the teams were actively discouraged from interacting and large swathes of code were isolated. No one developer had a full overview of what was going on and the managers seemed disinclined, until it was too late, to involve us.

Another failed because, whilst we had contact, only the developers from US City Team 1 and UK City Team 2 (I have, to this day, no idea why this was) were allowed to travel. This, eventually, caused huge resentment and a commensurate drop in productivity and morale since we were never offered a plausible explanation of why this should be so or what would be done to address it.

Workers may nod their meek acceptance of any diktat that arises – it does not mean they are happy with it and this spells doom for any project since, as morale drops so productivity declines.

Whilst the complexity or timescales of a project can drive the personnel choices as well as locations, technologies and management styles used to complete those projects if not enough attention is paid to the people that make all this happen, then it is a disaster waiting to happen.

Simply managing the project is not enough, particularly where the scope is regional or global. It must be seen that the people on the ground that are creating the project; developers, business analysts, testers, etc; must also gel and be a creative and disciplined team. This cannot be achieved if team spirit is not created at the outset. This may mean spending more budget up front to create and then foster this spirit but it will certainly save money and pay dividends as the project nears the critical path milestone where a decision would have to be made to stop throwing good money after bad, or, worse, after this time where it is difficult to stop the train even though more money has to be spent to put it right.

There are, in my experience, 2 solutions to this problem that I have seen work and work very well and they only happened after some of the disasters mentioned above took place and project post-mortems took place.

The first I have briefly discussed earlier on. This entails region swapping for periods of time, both ways. i.e. John Smith from London swaps with John Doe of Los Angeles for a week or 2 then another developer does the same thing until everyone has had a chance to meet and work with everyone else. Morale goes sky-high at this for a number of reasons, some more obvious than others. One, the opportunity to travel, if only for a short period, is usually seen as a perk for the traveller and, secondly, it is seen as a measure of implied trust of them and their abilities from the management.

The second was when I was appointed 'Global Development Ambassador' and, yes, I hated the title. This meant spending an initial 4-week period in New York evangelising about the project and helping in the team selection process. I then spent 1 week per month in the New York office during the course of the project – mercifully it only lasted 6 months. My job was simple after the initial period – to be in the office and carry on developing and doing my regular job whilst acting as a conduit between regions. It also meant that there was a single point of responsible contact to ensure that issues were resolved as locally as possible. However, I was not undertaking a management role; I was merely a straight and impartial line to that management, if required.

I also undertook a similar job several times before. Once, in particular, for a London based European bank where I spent 2 days a fortnight in mainland Europe for a few months and successfully undertook to meld an initially hostile team of highly proficient German & East European developers with a similar team of British developers (fortunately for me they all spoke excellent English).

I firmly believe that however the situation is handled, the key to managing developments across regional boundaries comes down to managing the people first and ensuring that there is team spirit and good morale. It is also vitally important that skill-matching takes place so that the teams, wherever possible, do not feel that the other team is either more or less skilled than they are or treated any differently.

One Team

There is, of course, another solution to this conundrum… simply put; it is not to have global development teams.

Whilst one obvious benefit of having a global team is the addition of their localized knowledge for applications that span differing regions each of which has its own requirements within the total structure this can, in any case, be acquired and applied to a project.

Therefore it can make economic, logistical and practical sense to have a single development team that produces a global application from a single location.

The Third Way

Finally, from a budgetary perspective, the case could be made to have the entire team off-site thereby cutting costs even further.

Outsourcing – not popular with those whose jobs it directly threatens. However, depending on the circumstances, it can be made to be effective. A distinct disadvantage to outsourcing is the loss of control and skill base that accrues.

If the project application is presumed to have a long shelf life then you don't want to find yourself at the mercy of a third party for many years and, at the same time, have no internal skill base to carry out support and enhancement functionality.

The desirability to maintain internal control over a project and its code-base must be weighed against the economic advantage to be had from, for instance, outsourcing the entire development process to India where there is now a great deal of proficiency and costs are much lower.

So, whilst there is no direct user contact required during the development process and you're only interested in the development prowess of a team then this is an obvious answer.

Time Zones

The time zone issue is difficult to overcome and can cause resentment amongst team members if too much reliance is placed on another team to carry out basic administrative tasks where, for instance, a member of a team in Germany may be kept waiting until a member of the team in San Francisco arrives to alleviate a problem that the team in Germany has no rights to resolve.

Nominating one member of each team to form an administration committee where each member has global administrative access and can resolve issues without recourse to a team thousands of miles and many hours away could address this problem.

There will, of course, always be issues that require a global response but if these are well documented and a specific course of action pre-determined and every team member is aware of this, then the resolution should not cause a problem.

Another solution is a team housed at a specific location for problem solving and administrative purposes that will cover all of the hours that teams are working within their own environments.

Summary

There are a large number of ways in which a global development can be managed to ensure that it is effective, goal oriented and focused and that the teams will all feel that they are playing for the same side.

1. Transplant developers for short periods of time to foster good relations
2. Adopt a 'Development Ambassador' approach
3. Abandon global teams and have a local team ethos
4. Outsource the entire process to either free up the team for other duties or to get rid of the teams completely

There is also the thorny subject of time zone differences to take into account and for which all but 1 above would help to resolve.

Conclusion

There are, I am certain, many other ways of dealing with global or regional team dynamics but I hope I have shown that however it is dealt with, the most important component of any team are the people within it and the way in which they are nurtured and handled to ensure that teams mesh and the project can be brought in on time and on budget.

Note that these observations are based solely on my own experience of working practices over the last 30 or so years in a variety of environments and industries but, predominantly, in the practice and execution of IT development and management over the last 15 odd years as tyro, developer, manager and business owner and where I've had the opportunity to work and live both in the UK and abroad on numerous occasions.

If you are currently planning a geographically diverse project or have already begun, I would be happy to discuss it with you on a consultancy basis. Contact me for details: mark at merrens dot com