On the walls of office cubicles around the world, engineers of all denominations have the famous 'requirements' cartoon pinned up. It shows, in the form of a tree swing, the divergence between what a customer wants, and what a company delivers.

"The cartoon has been around for many years, but it persists like all good jokes, because of the truth at the heart of it," says Charles Weir, managing director of software development experts Penrillian.

The development process for any product, hardware or software, is often flawed. The more times the objective has to be communicated, and the more interests that become involved, the further the end product is likely to diverge from the picture the customer had in their head at the beginning.

In fact the direction of development can be skewed even before the development team is briefed, if the customer fails to describe their idea in sufficiently clear terms. Even when they do, it is highly likely that what is produced will not fulfil the need. Not because the developer misunderstood or deliberately altered the design, but because over the time of the product's development, the requirements had changed.

In fast-changing markets like software, this is increasingly the problem. With outsourced development often the norm for many organisations, the chances of a breakdown in communication leading to a worthless end product are amplified.

"If you have a very clearly defined set of objectives, that the development team understands, and that you are sure are not going to change during the lifecycle of the project, then the 'waterfall' approach is an appropriate way to approach development within a tightly controlled budget," comments Bill Templeton, mobile software consultant and former business development director of Zi Corporation. "But if you are in any way unsure of what the outcome might be, you need a different approach."

In place of the traditional 'waterfall' approach, more and more companies are turning to Agile development.

The difference between Agile development and waterfall can be likened to the difference between a modern missile and a medieval cannonball. With the right information and calculations, the target of a cannonball could be accurately plotted. But once fired, there was no way of altering its trajectory. If the calculations were wrong, or if the target moved, it would miss. By contrast the modern missile can follow a given target with a series of incremental changes to its direction. It can even be given alternative targets when in flight, if the original is no longer appropriate.

Led by Charles Weir, Penrillian has taken wholeheartedly to Agile development. The company is employed by software developers, handset manufacturers and mobile operators to create a huge range of products for portable devices. One such customer is Zi Corporation, the creator of intuitive mobile interface Qix.

Qix was the brainchild of Bill Templeton while he held the role of business development director with Zi Corporation. He turned to Penrillian for the prototype's development.

"In the early stages of a product's development it can be difficult to get the internal commitment you need to get a prototype developed. In any case, the development staff you have are probably committed to supporting products that are already generating revenue. I've often found that looking to an outside company has been a faster and cheaper way to prove a concept, and it doesn't require you to use up political capital inside the company to get resource redirected."

Bill worked with Penrillian in close collaboration to begin to turn his initial sketches into a working product.

"It's a cliché, but the idea was actually sketched out on a napkin! What I needed to do was to turn this sketch in to something that I could prove was valuable enough for the company to support. And I needed to do it on a small budget and in a tight time-scale while continuing to do a full-time day job."

Penrillian's Charles Weir picks up the story:

"Our first challenge was to get the nuts and bolts working. Only when that was completed could we begin to think about any of the bells and whistles that Bill had suggested. Given his limited budget we had to ensure that we were as lean as possible; that none of the budget was wasted."

To make maximum use of the available budget, Penrillian worked on daily deliveries of new code. At the end of each day, Bill would receive a new build of the prototype and take it home to test. The next morning he would call Charles with the feedback. The constant interaction was key to the process.

"If we'd waited a week I would have spent some money and not necessarily liked what I got in return. Being able to test the prototype every night meant that the Penrillian team was always focused on solving the next most important problem or adding the next most valuable feature. And one it started to look like a product, I could steer the development with feedback from my colleagues."

After constant refinement, the Qix prototype was taken back to Zi Corporation and Bill could make his case for the strength of the product. The case was clearly compelling: Qix has become an established product, featured on a range of handset platforms, and is now a core part of Zi Corporation's product set.

Bill summarises his experience of agile development.

"Agile can be daunting if you're used to the staid and steady world of waterfall development. But, done right, Agile is a much superior process producing consistently more valuable results."

The word 'process' is key. Agile development is often perceived as something of a free-for-all, but executed properly there are very well-defined rules underlying the process, and the process should be no less well documented than in the traditional waterfall approach. This is particularly important when the process is being handled by an external development partner.

"If you're willing to take a truly collaborative approach, then I'd highly recommend finding a skilled outsourcing partner that understands Agile processes. With the right level of trust in the relationship, they can not only respond to your requests but help to steer them based on their expertise - something you won't always get from colleagues inside your company who will do what they're told rather than what needs doing. Be prepared for a different way of interacting, and enjoy the opportunity to change mind constantly. And at the end of the development process I'm sure you'll find you have a better quality of product."

Further Information:

For further information about Penrillian, please contact enquiries@penrillian.com or call Rachel Johnson on +44 (0) 1768 214400. Further details about the company can also be found at www.Penrillian.com.