Adequately Agile: Capital Markets Firms Embrace Agile Methodology

While the Agile software development methodology has been around since the mid-90s, it’s really only been in the last few years that capital markets firms have started to embrace various aspects of its Manifesto.


While some firms have enjoyed Agile’s benefits for an appreciable period of time, there is still some way to go before they can legitimately claim to be fully agile. In part one of this two-part feature, Victor Anderson looks at the Agile premise and what such a strategy might look like within a capital markets firm on a day-to-day basis.

Capital markets firms might consider themselves to be open-minded, forward-looking organizations, boasting some of the finest technologists on the planet, but when it comes to their software development—and specifically the methodologies underpinning and driving that development—the luddite moniker might be more pertinent than, say, that of the trailblazer or visionary. 

Some might argue that this assessment is a little harsh—especially given the quality of the technologists typical of the industry—and that there are numerous operational and regulatory constraints prevalent across the capital markets that restrict financial services firms from mimicking startups or lean and agile technology firms synonymous with Silicon Valley. Be that as it may, the Agile development methodology—a set of development methods and tools designed to provide immediate value through regular, close collaboration between self-organizing, cross-functional teams allowing for faster times to market, nimbleness and flexibility—is being used to various degrees by both sell-side and buy-side firms (and, naturally, third-party technology vendors serving those organizations) from the front office to the back office, and everywhere in between, even though inertia across the capital markets is significant and adoption of Agile is slower than it has been in other industries.  

Like nearly all business and development initiatives, the Agile methodology is not binary in the sense that you either use it or you don’t—it’s a continuum, a journey if you will, and all capital markets firms that have dabbled in it or cherry-picked aspects of its 12-principle Manifesto are somewhere down that road. Some have embraced its principles to a greater extent than others, but that doesn’t make them any better or worse—it simply means that they are further into their journey. 

It also means that they have made the all-important cultural and mental shift toward a more nimble and flexible development strategy, designed to be more focused, consultative and iterative than that of the Waterfall model, for so long the incumbent, dominant framework across most industries.  

Not Synonymous 

Like nearly all business and development initiatives, the Agile methodology is not binary in the sense that you either use it or you don’t—it’s a continuum, a journey if you will, and all capital markets firms that have dabbled in it or cherry-picked aspects of its 12-principle Manifesto are somewhere down that road.

The lean startup methodology, initially proposed in 2008 by Eric Ries, a Yale graduate and Silicon Valley entrepreneur, and Agile, while sometimes mentioned in the same breath, are not synonymous, although when it comes to the essence of both methodologies, there are striking similarities. 

Lean startup is about developing products based on customer feedback pertaining to what is known in the industry as a minimum viable product—“a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort,” according to Ries—as opposed to developing them based on what the producer assumes its target market wants. That might appear to be an intuitive strategy—establishing what you know the market wants, not what you assume it wants—but the financial services industry has witnessed more than a handful of technology firms throwing in the towel because their products or services simply weren’t able to find a viable, assumed market they were developed to appeal to. 

Swiss investment bank UBS is one such capital markets firm with a lengthy Agile track record, which, according to Rizwan Saeed, head of technology at UBS Delta, the firm’s buy-side focused portfolio analysis and risk management platform, can be traced back to Delta’s founding more than a decade ago. “I’ve been at UBS for a number of years now and I’ve seen the transformation from a traditional, highly program-managed Waterfall model to a more Agile methodology over the last few years,” Saeed says. “In terms of what it means practically, there are a number of facets that Agile promotes around automation, time to market, release cycles and engagement with the business. And in terms of the tooling and Delta’s productivity, UBS has initiated a number of processes to make that a lot quicker.”

Saeed explains that UBS has automated the provisioning of machines and its various release procedures, while it has also “gone lighter” on its approval processes. “We still have approval processes, but they’re automated now,” he says. “Obviously, as an organization, we are still highly regulated, so we still have lots of control processes and checks and balances, but there has definitely been a shift in automation and empowering developers to achieve things.”

Saeed explains that UBS Delta has ostensibly been using an Agile framework since Delta’s inception, a strategy that was born as much out of logic and necessity as it was from a conscious decision to embrace the model. “If you take the practices that Agile promotes—high levels of engagement from end-users, short delivery cycles, continuous feedback, iterations, etc.—those are all things that Delta has been doing since day one, it’s just that in the latter years a label has been attached to them. We operate using a scrum-style process; we have a monthly release cycle, which means quick time to market; and we have developers, marketers, support and client services people all co-located, which means we have high levels or engagement throughout the development process.”  

Smaller Chunks 

Michael Radziemski, CIO of Lord Abbett & Co., a Jersey City, NJ-based equity and fixed-income investment manager with approximately $125 billion under management, explains that while Lord Abbett typically has a 50/50 split between the Agile and Waterfall methodologies, Agile’s significantly faster time to market, its iterative nature, and its close consultation model between producers (Lord Abbett’s technology team) and consumers (the firm’s technology users) offer obvious benefits.      

“With the Waterfall methodology, each phase should be 100 percent completed before you start the next one,” Radziemski says. “So your requirements get fully documented and signed off, then you do the design phase—which needs to be completed and signed off—then you do the development, then you test, and then finally you deploy. Agile at Lord Abbett is all about breaking the problem into much smaller chunks and then working interactively with the end-users to flesh those out quickly and possibly even build them out. So you’re quickly cycling through smaller chunks of the application—it’s an iterative approach where you’re trying to develop something quickly that end-users can look at.” 

Researching the functionality and producing the specifications and documentation pertaining to what users want in a system—processes integral to the Waterfall model—tend to be complex, time-consuming, costly, and sometimes suffer from scope creep, while, when the product is finally deployed, possibly years later, the market and its consumers might well have moved on, rendering it largely obsolete. 

What Agile offers organizations is the ability to deliver applets early and often, allowing them to pivot if and whenever necessary, while encouraging valuable end-user feedback as an integral part of the release cycle. “Once users see it on a screen, the feedback becomes more specific and actionable,” Radziemski says, referring to how users tend to react when they are able to “play” with a piece of software on-screen as opposed to reading about its specs or seeing it described in a PowerPoint presentation. 

“They are able to describe what they want so much more effectively with a prototype in front of them than they are by way of a paragraph on a piece of paper,” Radziemski explains. “Feedback is better and we have a lower project risk because we’re delivering things in smaller chunks. If you really want to build a great system, you want your absolute best business people providing input. For example, take your best portfolio manager, your best salesperson and your best client manager; most of them are busy doing their day jobs and so they’re not going to want to read a 100-page document of just text describing a system. If you put an early-stage prototype in front of them, in 10 or 15 minutes you get very real feedback and there is efficiency in the communication that is incredibly valuable.” 

Total Commitment 

London-based $5 billion systematic hedge fund, Aspect Capital, is, like UBS Delta, a dedicated Agile user, committing to the methodology for all its development work. The fund’s CTO, Barney Dalton, explains that Aspect runs three sprints—a predetermined time period during which specific work, usually incorporating one or more “user stories,” must be completed and made ready for user-review—across its technology stack. 

“The first focuses on what we call research technology—developing new trading strategies and all the infrastructure you need around that; the second focuses on execution through to the middle and back office; and the third focuses on our infrastructure—server builds and new software installations,” Dalton explains. “They all run on two-week cycles, which are aligned. We have daily standups in each of those three sprints and then there’s a backlog prioritization process that takes place in the lead up to the next sprint. There’s a mix of skillsets in each sprint with developers in each of them, who will sometimes be pulled onto another sprint if it has a particular focus that requires a slightly different skillset.” 

Dalton doesn’t attend all the standups—they can run without him, he says—but if and when he does attend a meeting, it’s usually only as an observer. “They’re a nice way for me to stay in touch with what’s going on,” he says. “My involvement is more at the prioritization level and deciding what goes into the sprints. We divide the backlog into themes and each theme has a business owner who gets to prioritize within their theme.”

Must-have Methodology

Intelliware Development, a Toronto-based consultancy with a large capital markets practice, has, according to Keith Shiner, vice president, financial services, been delivering software solutions to the financial services marketplace for the past 25 years. 

Shiner explains that during the course of those two decades, Agile has transitioned from a “taboo and undisciplined approach” to a must-have methodology for capital markets firms to support the rapid advancement of their products and services. “For Intelliware, Agile has always been simply a core way of managing the inherent risk associated with technology projects and ensuring the delivery of high-quality and sustainable solutions with a faster time to market,” Shiner says. “In particular, the real discipline that is required to be successful at Agile lends itself well to the risk-averse nature of financial services firms.”

Third-party technology providers in many ways resemble capital markets firms’ internal technology departments, even if their raisons d’être differ. StatPro, a London-based provider of risk management, performance measurement and attribution products, uses Agile extensively to drive the development of its cloud-based Revolution platform, unveiled in June 2011. StatPro, like UBS, Lord Abbett and Aspect Capital, works closely with its clientele, although being a third-party technology provider, it has external clients in the form of asset management firms as opposed to internal ones. 

According to Scott Harris, head of StatPro Revolution development, the methodology provides his team with the focus and impetus to pull together constituents from across the business right from the outset of a piece of development work. “Agile is part of our development process, and the key is making it a highly iterative process through continual feedback,” he says. “It’s important to our cross-functional teams—it’s about bringing together financial and technical expertise right from the outset of a project and it allows us to adapt to functional changes if and when they occur.” 


Harris explains that StatPro uses Kanban—the Japanese word for signboard or billboard, an inventory control system developed by Taiichi Ohno, an industrial engineer at Toyota in the late 1940s and early 1950s, designed to manage the logistical chain from a production perspective—as the framework underpinning its Agile strategy. “Instead of stockpiling their inventory, Toyota matched it with demand. For us, it’s the same sort of thing—it’s about not overloading features that are currently in development and creating backlogs, and reducing work in progress. This allows more flexible planning because you can see who is working on what, developers can pull their own tickets, they have a clearer focus on what they are currently working on, there is faster output, and I think there is better overall transparency in terms of where you are in a project, which allows you to be more flexible and change the planning if necessary,” Harris says. 

Harris’ colleague, Neil Smyth, marketing and technology director at StatPro, outlines the significant differences between Agile and Waterfall at StatPro, allowing the vendor to be consultative in its planning and responsive to client feedback, with the added benefit of massively reducing its time to market for incremental changes. 

“When we had on-premises software, we came from the days of Water­fall, where we had big project specifications where development got locked away for months on end and then something was released,” Smyth says. But that all changed, according to Smyth, when, early in the Revolution initiative, the firm was presented with what was essentially a blank sheet of paper. “When we started developing Revolution, we wanted it to be a single version of the code. We thought that that was a great time to adopt a new development methodology. We’ve done 65 releases of Revolution since we launched it—we have a sprint process and the Kanban planning is the framework that allows us to see what’s coming down the line. We do it in bite-sized pieces, releasing early and often,” he says. 

Salient Points

  • The Agile methodology places end-users at the heart of product development, valuing their feedback and incorporating it into a product’s future look and feel. 
  • Agile focuses on releasing applets early and often, thereby providing immediate and ongoing value to its consumers. 
  • A key advantage that Agile has over the Waterfall methodology is that it supports flexibility, allowing developers to “pivot” when necessary to ensure that future releases stay relevant to users’ needs, especially in a changeable marketplace.   
  • Part two of this feature, to be published in the May 2016 issue of Waters, focuses on some of the process management and communication tools capital markets firms use in their Agile frameworks; the variables that underpin a successful Agile initiative; and the notion that Agile is as much a culture and mentality as it is a pure software development methodology. 
  • LinkedIn  
  • Save this article
  • Print this page  

Only users who have a paid subscription or are part of a corporate subscription are able to print or copy content.

To access these options, along with all other subscription benefits, please contact [email protected] or view our subscription options here:

You are currently unable to copy this content. Please contact [email protected] to find out more.

You need to sign in to use this feature. If you don’t have a WatersTechnology account, please register for a trial.

Sign in
You are currently on corporate access.

To use this feature you will need an individual account. If you have one already please sign in.

Sign in.

Alternatively you can request an individual account here: