Despite the ability of technology to allow developer teams to communicate while working in different locations, that still isn’t the ideal approach, says Paul Ramsay, of software developer Equinox.
Ramsay says it is better to have everyone in the same place and that this “co-located” team include at least one person representing the customer, to answer unexpected questions and make decisions, either on the spot or by referral to colleagues and supervisors.
Co-location facilitates interaction and communication among members of the team, which, as well as aiding the project at hand, hones social skills and knowledge of the quirks and styles of working of colleagues, he says.
Being together focuses attention on the project; if members of the team are working on their own, they will experience distraction, either from other work tasks brought to their attention or personal matters, Ramsay told a seminar on team-based development late last month.
Whether the team works on its own or the customer’s premises, doesn’t seem to impact productivity or quality of results, says Ramsay. “as long as they’re all together”.
Formation of a team that can work well together is more important than the specific processes or tools used in the development, he says. Another advantage of co-location is that reporting processes can be kept simple.
A team should preferably have a mixture of members with broad experience of a number of development tools and techniques and those with a in-depth experience of one or two such tools.
However, the problem of a complex network of people-to-people links, which grows “exponentially” with the size of the team, must be addressed through formal communication channels. To avoid too many communication pathways, a central repository to which all submit their code, other deliverables and progress reports is a good approach, he says.
A suitable software development environment can maintain such a repository and automatically keep track of the progress of each team member’s work stream. Progress reports fall out naturally from such a system and this means there is no need for constant checks on progress. Being asked continually by a project manager to estimate and report on progress can prove a distraction from work and a drag on productivity, he says.
One such suite is Microsoft’s Visual Studio Team System. Mark Carroll, architect for developer and platform Strategy at Microsoft New Zealand, followed Ramsay in presenting Team System’s capabilities, but took care to tie them back to a generalised team development model.
Carroll pointed to a new flexibility of Team System which, he suggested, makes it easily interoperable with other tools and environments development teams want to use. “Team System sits on a big island of configurable XML and below that is bog-standard SQL Server.”
Equinox has used VS Team System for several projects and Ramsay gave examples of three: a system for the QEII National Trust to monitor land protection covenants; one to manage scholarships for NZAid and one for Shering Plough Animal Health to monitor use of its customer loyalty rebate system.
All three were developed in about six months, by a team of six or seven people. This seems to be the optimum team size, Ramsay says. Clearly major projects will require a larger team, but it should be possible to divide the development into sub-projects to maintain small-team advantages on each sub-project — providing inter-team communication is properly set up.
There are a range of working styles from the more formal, working to a strict set of pre-set processes and the more popular “agile” style. The latter may produce a more flexible end result which will have a longer life as it bends with the future needs of the organisation, says Ramsay. However, with the Kiwi “number 8 wire” tradition, the merits of the agile style are sometimes overemphasised, he suggests, and can easily become “flying by the seat of your pants” — which does not usually produce a good end result.