Change and control
The key problem they have, according to Ó hEocha, is with the idea that the design can evolve as the project progresses. This feels a lot like losing control.
“That’s anathema to many business people,” he said.
To make sure the interaction goes smoothly Ó hEocha works closely with the commercial side of a company to come up with ways to formulate contracts that can work in an agile environment. But he remains adamant that for both sides of the interaction to get the most out of it, the idea of an adversarial approach to outsourcing can’t work and needs to be dropped.
“If you set out not trusting your vendor or your customer and you’re locked into thinking about a fixed price, fixed scope contract through to time and materials contracts, then basically you’re saying you don’t trust your vendor to deliver what they should deliver,” he said.
“Usually companies start off mistrusting each other, especially if they haven’t had a long term relationship or there have been problems with that relationship, and it can be difficult to build the trust you need to work more productively together.”
But, said Ó hEocha, the whole reason companies go down the route of using the Agile methodology is to try to give better options to their customers.
“Whether that customer is an internal business unit or an external customer, you’re basically trying to give them better options, better value and more flexibility. So it’s our job to convince companies, customers and the business that this is good for them,” he said.
Old and accepted
The older, and frankly more accepted, method of conducting application development is known as the waterfall methodology, named after the way in which development should progress and flow naturally downwards like a waterfall.
This methodology has its origins in the manufacturing and construction industries, where it makes sense for one thing to follow on from another. However, the argument made in favour of the agile methodology is that the development cycle of applications has less and less to do with these old world models.
Application development companies find themselves expected to produce complex applications fast, in some case in hours and days rather than in weeks and months. Furthermore, they have to do this without always having a clear idea of exactly how the application will be used and how future iterations will evolve.
“In days past, we could sort of predefine exactly what a piece of software or a system should do. That’s no longer always possible now because things move so fast and technology has become so complex, especially with many more deployment stacks and cloud-based systems and so forth,” said Ó hEocha.
Ltd
