The Agile software development methodology is most commonly associated with building customer-facing, often web-based, front-end systems. But there are organisations that apply the practice to rather larger problems.
Zühlke is an engineering and management consultancy headquartered in Switzerland that has been using Agile since 1997. The company’s UK division primarily serves financial organisations in the City of London, building bespoke integrations for legacy systems.
“The days when companies could just switch off their old systems and start from a green field and develop a completely new IT system are over,” explains Wolfgang Emmerich, CEO of Zühlke UK and professor of software systems engineering at University College London. “Instead, if you want to evolve your IT estate, you have to do it incrementally, with newer IT components being integrated with old components.”
Applying Agile to integration is in essence no different from product development, says Emmerich, and the same principles must hold: there is a backlog of features that are prioritised according to business value, a working solution must be delivered at the end of each iteration of the process and software testing is ongoing.
Certain practicalities are rather different, however. “Testing an integrated service is more complicated than in product development,” says Emmerich. “You have to build a harness around the system so you can test its behaviour from
the boundaries.”
There are pitfalls that are unique to integration projects, Emmerich explains. “One example is that you might make incorrect assumptions about the other components that you must integrate with,” he explains. “If you have misunderstood the interface of that system, that’s a cause of great concern.”
But in an Agile integration project, Emmerich says, such an error would be less harmful than in a traditional ‘waterfall’ project management approach, as it would come to light sooner. “The earlier you detect a problem, the cheaper it is to fix it. If you go down the waterfall route, you might not even have the time or the money to fix it at the end of the project.”
Zühlke UK’s business is heavily based on the financial sector, and in 2008 it suffered a difficult year. “The banks shut up shop,” says Emmerich. “But 2009 was a very good year,” he adds. What changed, he explains, is the way Zühlke sells its Agile development services. It used to talk about technological leadership and quality of service. Now, the focus is on the ability of Agile to cut cost. “There are a number of ways that Agile reduces cost,” he argues. “The first is that you have a lower defect rate, so you spend less time fixing problems. The second is that you don’t deliver functionality that is not needed.”
Emmerich recalls the recent example of a financial institution that employed Zühlke to develop a trade settlement solution. The client asked that the system support a certain type of trade, and the Agile development team needed to find someone who knew about that trade to help them build the feature. “It turned out that that kind of trade was
just a rumour,” Emmerich explains. “Everyone thought they did those trades, but they didn’t. In a waterfall project, that feature would have been in the spec,” he says. “They would have built it, tested it and happily implemented it. And nobody would have ever used it.”
Agile is not infallible, of course. Emmerich says that Zühlke has learnt two important lessons in its 13 years of using the methodology. “Firstly, Agile projects will fail if you don’t get buy-in from a product owner who can speak correctly for the stakeholder community,” he says. “The ideal client representative is a technically versed user or a business analyst – somebody who really has a deep understanding of the business.”
“The second thing is that you can only be as Agile as your IT operations,” Emmerich remarks. “You may have successfully delivered a system in the integration server and in the test environment, but if your IT operations guys aren’t able to switch between development systems and live systems, then you won’t reap the benefit of Agile development.”
