Hilson说他的另外一个动机是不再想当“大池子里面的小鱼一条”了，在英国情况就是这样的。首先他去奥克兰(译者注：新西兰北岛西北岸港市)看了看，发现在这一点上和伦敦没什么两样。第二站他去了威灵顿（译者注：新西兰的首都，位于新西兰北岛最南端的库克海峡的小港内），这里他从2003年2月呆起，开始转移他的公司Visual Exchange和一些新西兰职员（Kiwi staff）。Hilson和Visual Exchange专攻使用DSDM (Dynamic Systems Development Method)方法的敏捷编程。这个方法的一个要点就是要在开发队伍和业务人员之间建立良好的交互。Hilson指出，新西兰人平等的工作方式非常适合DSDM。打个比方，如果你要去见某个高级主管，在英国要提前预约，在新西兰就并不总是如此。

Hilson指出，这样的延误（译者注：预约等做法）会给使用DSDM的项目带来很大混乱，因为这些项目通常时间都很紧张。事实上，Hilson建议至少要有一个业务代表和开发人员坐在同一间屋子里，即使是走过一个走廊来回答某个不是很清楚的某个问题，都会浪费太多时间。

上个月，Hilson在一次报告中遇到了听众的这样一个问题：对于一个大合同，往往客户会要求非常严格的规约（specifications），这是否会和敏捷技术产生冲突？。Hilson的回答是：“你必须和客户建立协作关系”，他并没有遇到这样的困难，即使对于严格定义的规约，DSDM方法的前15%的时间用来做计划，如果需要的话，在这个阶段结束时对于一个充分细致说明的项目，可以得到一个确定价格的合同，之后，为实现这个目标，采取什么方法就没有那么多关系了。

他承认，因为项目必须在指定时间内完成，必须要牺牲一些“nice-to-have”（有则更好）的功能。DSDM方法建议在最开始对功能的分类进行协商，分为“must have”, “should have”, “could have” 和“want to have”，“musts” 和“shoulds”是“coulds”中那些可以在指定时间内较容易完成的功能，当时间和需求的安排必须考虑项目中不可预测的困难的出现。为满足进度要求，一些“wants”功能将被牺牲。

另外，在对问题的责任上，英国人和新西兰人的态度也不一样。Hilson指出，在英国，业务人员只负业务分析，项目主管只关心项目的管理，而在他的新西兰团队中，则是“我们出现了这个问题，谁想解决它？”

过去通常认为敏捷方法只能适用于6个月以下的较小的项目，但Visual Exchange已经成功地完成了较大的项目。Hilson指出，一个例子是为BBC电视台做的脚本书写工具的项目，项目时间超过18个月，花费二千五百万新西兰$。这个项目非常成功，后来又被Granada公司购买了。