Bank gets agile about development

International bank BNP Paribas is getting faster return on investment from its software projects by using agile software development.

The bank is using the development methodology to cut the number of bugs in new applications and help IT to deliver the functionality required by the business faster.

Fred Tingey, head of risk IT at the bank, told silicon.com: "We didn't do this in order to get quicker. The main reason for doing this is because it's a more realistic way of developing software and more in tune with what actually happens."

He said agile software development provides applications that are a better fit with business requirements with less bugs.

Tingey said that with the classical "waterfall" style of development, the development team will work on a big upfront analysis and design, then do the coding and finally test the completed application. On some projects from beginning to end that might take two years, he said.

But this approach can run into problems as business requirements can change. Instead, with the agile approach, developers work out some of the requirements and do some analysis - and then start building.

"[The application] doesn't do much at the start but as you add more functionality the users can see the system [develop] and give you feedback," he said.

This approach means that important features can be developed first, giving faster time to market and thus greater return on investment, he said: "With the agile approach because you have a working version of the software where you are gradually adding functionality, if you add the high value stuff first you can go live with it."

The bank, which has worked with consultant Exoftware, is using the agile approach on development of risk management systems for things such as Basel II, and is beginning pilot projects in other parts of its IT organisation.

Because the development team is running a new small project every couple of weeks, this makes them "very confident that we can deliver to the timescale we plan," Tingey said.

"It puts quite a lot of pressure on the business to know what they want and why they want it and how important it is - and what it should do. The business has to be on the ball."

He added: "There should be no such thing as an IT project - there are only business projects done for business reasons which include various degrees of IT involvement. Things become IT projects but most of the impact is on the business processes."