Working for a major UK bookmaker, the ZUUK Consulting team led the move froma waterfall off-shored development approach to Agile, the success ofwhich prompted Agile's full scale adoption.

Very often things have to reach crisis point before people accept the needto change. The situation we found was pretty typical, no real plan,analysts struggling to define requirements, no user involvement, andcode returned from the off-shore supplier that bore littleresemblance to the specifications. Effectively the project was deadin the water

Calling what we were about to do Agile was too politically unpalatable forthe senior IS managers, who had advocated off-shore development.Instead we called it ?prototyping?, took over a corner of theopen plan office with space enough for twelve, screened it off to theoutside world and went to work.

The first job was to select a team, we needed good people ? technologywise, problem domain wise, usability wise, test wise ? including agood customer representative that senior stakeholders could trust. We made a shortlist, went after them, fought the battles, didn'tcompromise, and ended with all bar one of our first choices.

The second job was to agree a plan, not a Gantt or Pert chart plan, butan agreed set of objectives and an approach to meeting them. And wehad lots to do; develop the overall navigation; determine thetechnology; design the framework code; and understand therequirements, but our overall goal was to gain the trust of the usercommunity, a community that had been badly let down in the past.

We set about it using weekly build iterations, each one with a scenarioto be developed, designed to increase our understanding of both therequirements and the eventual solution. Our iterations started on aWednesday with a discussion between the development team and theusers about their tasks and what they needed. We used anything wecould to provoke the conversation, partially developed businessprocesses, use case documents, demos of the existing systems, etc.etc.. When we arrived at the point where we thought development couldbegin, the meeting would stop and we'd get on with the doing. Everyday at 9:30 we'd take 15 minutes to discuss what we'd achieved theprevious day, what was planned for today, and the issues thatremained. The following Tuesday, without fail, we'd demo what hadbeen produced and sought feedback. The feedback would help drive thenext week's work.

Very soon the mood of the project changed. The users, presented withworking, dynamic code, saw their feedback and suggestions embeddedinto the functionality and felt able to add value. The developmentteam, their work being appreciated, become happy to accommodatechanges requested, and add their own suggestions. Senior businessstakeholders, after months of waiting, suddenly saw real progressrather than status reports they had little faith in. The IS Director,keen to show off this new approach to his fellow executives, began tovisit our screened off zone more and more often.

The system began to evolve and grow until, over the course of nineiterations,the navigation framework was ready, the technologies hadbeen proven (with some discarded along the way) and major areas offunctionality had been explored, developed and demonstrated to alevel that would have been impossible using a traditional approach.More than that, we'd developed into a single team with no delineationbetween IT and the business, and together we felt confident that weunderstood what needed to be developed. We'd achieved out main goal.

One problem still remained, we'd gained permission to complete the RUPelaboration phase through ?prototyping? but the Constructionphase was still due to be off-shored. However the reality hadchanged. The enthusiasm and momentum the team had engendered hadinfected the rest of the programme, and it would have taken a braveand foolhardy person to advocate going back to off-shore. The fullscale adoption of Agile had begun.