Bringing deep technology, business domain expertise and hands-on product development experience, Luxoft is a global product engineering and high-end IT outsourcing services company with the largest delivery capabilities in Eastern Europe.
It was recently announced that the CME Group’s Technology Department will be working weekends, as well as the entire holiday season, to integrate the merged Chicago Board of Trade and Chicago Mercantile Exchange onto one infrastructure by Spring.
Within bond trading the value of shares is changing not just every hour, not just every minute, but every second. If a company’s technology is not absolutely up-to-the-minute, they will be losing money to competitors whose systems will process information more quickly and effectively.
In any project, from a school assignment to the most detailed software development, you will know more about it at the end than the beginning, it’s hardly rocket science. So why, when thinking about the implementation of detailed software development plans, do so many companies map out every micro detail at the very beginning? Surely it makes sense to perform the first part of the project, define short-term requirements, examine results, come to conclusions and then plan again for the next stage.
For Agile Software Development, producing software in short iterations is the common sense approach to software development. Projects are developed in two to three week timescales at the end of which the user can see a working version of the software for sign-off before progressing to the next iteration. By constantly testing and integrating the results at each stage, the final product can be released earlier if it is ready, or changes can be made that will lead to an implementation that is both rapid and successful.
“Failure is not an option,” said Gene Kranz aboard the Apollo 13 and with the more traditional ‘waterfall’, process-led, approach to software development, this is perfectly true. With all of the stages of the project planned from the beginning, one malfunction in the whole process will cause the whole project to fail. Whilst failure was not an option for Apollo 13 or traditional software developments, slippage or mistakes can be reconciled with Agile Software Development as each project is broken down into smaller parts.
Imagine a writer spewing out a whole book without pause for thought or reflection. Whilst many of us must have questioned how much planning the likes of Barbara Cartland genuinely put into their books, the reality is that constantly going over your work and reassessing is part of the process. Because the Agile methodology is broken down into shorter projects, there is always time to reflect and make changes where necessary, as well as testing and integrating these changes.
In a more strictly planned development, such reflection is not always possible. Come the end of a waterfall project, there is the possibility of looking back and finding that the outcomes have not been in line with the original objectives. Additionally the results may not be in line with new specifications that the end user may have, particularly given the fast pace of change in the IT industry. In a constantly evolving business environment predicting only a few weeks in advance minimises wastage in terms of time spent on document writing at the outset and takes into account everyday variables like personnel and regulatory changes that may have an impact.
The London Stock Exchange has recently completed a four year trading system development project known as Technology Roadmap (TRM). TRM’s main objective was to introduce a next generation trading system that would provide more capacity, less latency and a reduction in the time and cost needed to roll out new services.
It is worth examining the impact that an Agile approach could have had on this project. TRM had a four phase release, so in this way it mirrored Agile Development methodology in the sense that the development was released and therefore utilised, before the whole project was complete.
However, the project could have been broken down into even smaller iterations, if for example, the first release (enhancements to the corporate data warehouse) had been done using agile methodology, a working version of the software might have been put out earlier and therefore the obvious financial gains of the system could have been maximised earlier. This is even more pertinent with release four - TradElect™ - which increases the speed and efficiency of trading, provides the framework for the rapid development of new markets and asset classes, enhances the market structure to better support order routing, settlement and clearing, also extends functionality for order handling, quote management and trade reporting. Every second counts and the fact that the third and fourth elements of the project took two years to release suggests that Agile could have delivered direct benefit to the bottom line.
But Agile isn’t all a bed of roses, it has its limitations. For one, it is very dependent on the structure of the clients’ organisation. Some organisations have particularly rigid, inflexible structures and therefore will not have flexibility to allow for constant change in a project. If a somewhat ‘pre-historic’ company has a rigidity of structure, whereby all projects are strictly planned (and therefore predictable) from beginning to end, then attempting to put in place a methodology that embraces constant change and development is likely to cause internal confusion and consternation.
The need to get customer buy-in at every stage can be a potential difficulty, particularly for customers who are inherently used to the waterfall methodology. Whereas in the waterfall methodology the customer involvement is limited to two stages – beginning and end - the requirement for on-going participation and input in the agile methodology may prove problematic for some organisations. If the supplier is trying to develop software using the Agile methodology, but the customer is not getting involved, the benefits are immediately lost.
Henry Ford believed that, “Coming together is a beginning. Keeping together is progress. Working together is a success.” Whilst the direct communication between supplier and end user is one of the key potential benefits of Agile, it can also be its downfall if complete buy-in from all sides isn’t achieved.
Faster, more up-to-the minute technology is, of course, beneficial to every FTSE 500 company. Insurance companies, hedge funds, private equity funds, broking and trading firms, investment banks, consultancy and accountancy firms, data providers, law firms, regulators and stock exchanges, all stand to benefit from a methodology that allows trading platforms and equity systems to be developed in the most efficient manner.
Agile is becoming more widespread and sceptics are being won over, whilst the waterfall method seems to be on the brink of freezing. The realisation that you have the most information at the end of the project, as opposed to the beginning, is infiltrating into mainstream software development methodology. Doubters amongst end user organisations are realising that a shift in internal ideology can create a more rapid and successful deployment of software. Although many organisations are tied to the more traditional waterfall methodology, whose main benefit remains the ‘illusional predictability’ of delivery, Agile the challenger methodology, is becoming ever more popular due its faster delivery and the greater involvement of the end user at each stage in the development process.
For more information please visit www.luxoft.com.
