Working in London, English software developer Stephen Hilson found 18 out of the 20 staff he had recruited for his company were New Zealanders. Since they were all good at the job, he says, he was motivated to come to New Zealand to find out what made for a superior quality of developer.
The other major motive, he acknowledged, was a desire to be less a “small fish in a big pond” than he was in the UK. He looked first at Auckland and decided it was too much like London in its big-city thinking. “I thought ‘I’ve done this; I don’t want to do the same thing again.’” So the next stop was Wellington, where he has stayed since February 2003, in due course transplanting his company, Visual Exchange and some of those Kiwi staff.
Hilson and Visual Exchange specialise in agile programming using DSDM (Dynamic Systems Development Method). One of the essentials of the method, he says, is a responsive interaction between the development team and the business. Here again, he says, the New Zealand egalitarian working style fits well with the work; if you want to see a member of senior management, you don’t usually have to make an appointment in advance as you might have to in the UK.
Such delays play havoc with a tightly-timed project, he says, and projects under DSDM are structured to fit in a tight “timebox”. In fact, Hilson recommends having at least one business representative in the same room as the developers; even walking down the corridor to get an answer to an unclear point wastes too much time, he says.
A member of the audience at an address Hilson gave to the Computer Society late last month [May] asked whether the tight specifications often demanded from the supplier in an RFP for a large-scale contract worked against agile techniques. “You have to have a collaborative relationship with the customer,” Hilson said, and he has not found this difficult, even with a tightly defined spec. The first 15% of the DSDM timebox is allocated to planning, and if required it is possible at the end of that period to agree on a fixed-price contract for a substantially well specified project. After that, the exact method by which the target is attained should be less relevant.
He acknowledges, however, that to bring in a project within the timebox, it may be necessary to sacrifice some of the “nice-to-have” functionality. DSDM recommends initially agreeing on what functionality qualifies as “must have”, “should have”, “could have” and “want to have”. The “musts” and “shoulds” and typically some of the “coulds” should be easily implementable within the timebox, but timing and ranking of needs should be arranged so that in the case of unexpected snags, some of the “wants” can be sacrificed to meet the schedule.
UK and Kiwi attitudes also differ when it comes to taking up responsibilities for problems, he says. “In the UK, a business analyst only does business analysis; the project manager only manages the project. With my Kiwi team, it tends to be a matter of ‘we have this problem, who wants it?’”
Agile methods are often said to be suitable only to comparatively small projects with a development time of six months or less, but Visual Exchange has successfully achieved larger ones, says Hilson, for example a scriptwriting tool for BBC TV had extended over 18 months and was valued at NZ$25 million. It was so successful that it was subsequently bought by commercial producer Granada.