Kicking off the after-lunch slot was the COOLProfs team. Ton Koot and Joop Stringer from Holland started things off with a bang. COOLProfs is an OutSystems partner specializing in application development and CA Gen. They talked to us about how to execute an agile project on-time and on-budget. They shared their experience of their first agile projects and used two customer examples to show how things can go; both a project that goes well and as expected, and one that does not.

Ton Koot and Joop Stringer present findings from their first agile projects

The first project they discussed was with Schuitema, a new client - the Dutch retailer with 400 stores that each had a server with their own retail system. The project was to use OutSystems to add a new web-based mobile front-end to a legacy system that was built with CA-Gen and made available the existing inventory management system on Motorola PDAs (with a Motorola web browser that did not support AJAX) to the store managers and enable real-time inventory control. The intended application was to be a small one, estimated at approximately 700 Software Units.

First agile projects - a good sprint

The second project was for TNT (global transportation & mail shipment,) an existing client of COOLProfs - to build a new, stand-alone support-request system to enable users to register issues and establish a knowledge-base. Their sponsor was from the business-side and worked with COOLProfs directly to build the new system using OutSystems. A larger application, this was expected to be a 40,000 SU system.

Sprint 2 wipeout can happen during your first agile projects

Ton and Joop entertained the audience with two videos. One of an athlete hurdling with great ease and agility. The other, of "Total Wipeout" which is, for those who don't know, a TV show with a lot of different groups competing in a crazy obstacle course - and crashing around with less than agility or grace!

Can you guess which video represented the final experience of which project?

Their experience was that in Schuitema case, they expected ease and speed of a project but faced many surprises and great difficulty; with the TNT project - they expected a harder time with this new customer; but everything went extremely smoothly.

So, what worked?

  • Having the commitment of all stakeholders
  • Having the business person as your key sponsor
  • Direct interaction with the customer - so much so, they felt it was extremely important to be constantly on customer site.
  • They strictly enforced all agile principles - daily stand-ups, change requests, etc.
  • Applying common sense.

What didn't work and how to avoid the pitfalls?

  • Never underestimate the complexity of a system
  • Take a good look at the documentation to know in detail what you were working with
  • Be careful of proprietary devices (the PDAs they had to use meant hand-coding and big headaches in maintenance)
  • Having IT as the key-sponsors alone; get a direct line of communication with the business users
  • Be wary of knowing the target technology environment
  • Be careful when working with third parties who cannot keep pace with your rate of work and Agile practices.

How to Cope with Challenging Environments: First, the guys prefaced this next section with a warning not to end up back in the waterfall world by trying too hard to know everything up-front.

However, DO do the following:

  • Start only after you fully understand and feel comfortable that external factors are under control
  • Conduct proof of concept against the final architecture and technical environment
  • Practice risk mitigation in general
  • Convincing your customer that there is a trade-off between time, budget and functionality
  • Convince your customer that their on-going participation and understanding is paramount.

Key conclusions from their first agile projects:

  1. Size doesn't matter (the more successful and straightforward project was in fact the larger one by nearly 10x)
  2. But, infrastructure does matter! (e.g. a different PDA was presented to the team to be used than the one used for the prototype)
  3. Don't find yourself responsible for things you cannot control (like third parties or the support of handhelds)
  4. Be wary of using new technology to change archaic organizations.