Using Agile for Vendor Implementations: Good idea or bad? (Part 1)

Has this happened to you? Your firm decided to use the Agile methodology for the implementation of a vendor product, like your trade order management system (OMS). You’ve obviously heard of Agile before, and perhaps even worked on a team using it, yet you still find yourself engaged in the proverbial Google search to learn more about it.  Your gut tells you it just doesn’t fit right with projects having little to do with development. In your search, you get lost with the numerous flavors of Agile from ones that use Post-It notes for requirements, to no written requirements at all. You ask yourself “If Agile is for development projects,  why are we using this for an implementation?” Well, you are certainly not alone.

A brief history

The Agile methodology framework has been a key product management methodology leader for software and product development since Jeff Sutherland and Ken Schwaber invented it in the early 1990s.  There are numerous flavors of it such as Scrum, Kanban, Extreme Programming, and so on. In the last decade, many firms have been morphing and adapting it in creative ways across non-development projects, which was not technically the original intent. 

Why are more and more firms leveraging Agile you ask? The advantage of Agile lies in its twelve fundamental principles that were agreed upon at the turn of the century (see  While these principles are noble in their cause, the reality is, not all projects align perfectly with them.  In addition, as the interpretation of Agile has expanded over the years, many of these core principles have lost their punch with the day-to-day mechanical operations of running an Agile team taking priority.

Should you use Agile?

If your firm is utilizing or thinking about using Agile for a vendor implementation, there are 3 key questions to ask yourself. 

Step #1: What is the “criticality” of the system we are implementing?

Ask yourself, if you were tasked with the configuration and implementation of the life support software system for NASA’s first manned mission to Mars, would you forgo detailed requirements, documentation, research, and detailed use cases, in favor of more frequent project sprints and deliverables?  Is it even feasible to deliver something in those short time frames? Generally, Agile methodologies sacrifice documentation and rigorous requirements in lieu of delivering faster and more frequent releases. This does not necessarily work for highly intertwined critical systems.  As mentioned, the folks at NASA know this too well, and critical systems (like your vendor trade order management system) are the lifeblood to execute your investment objectives in the markets. As an implementer of a vendor system you must be able to trace the functionality and configuration of the system back to the detailed requirements from the business (portfolio managers, traders, compliance, operations, etc.). A conversation in the hallway followed by a 5-minute demo an hour later does not count.

Step 2: What does the risk meter look like with your system?

Proposed compliance regulations and controls on how software providers and managed services providers are held accountable is an evolving topic.  Proposed regulations like “Regulation AT” which may potentially give regulators access to audit software code for automated trading is clearly a controversial topic. In a world of tighter regulations, can you produce the documentation, requirements, and a robust implementation plan that clearly demonstrates your project was bullet proof and that the software you implemented had a risk averse approach with all stakeholders in mind?  If you had a trading error, can you prove without a reasonable doubt that your project team conducted thorough due diligence through requirements analysis all the way to testing, parallel, and go-live? If not, you have a high risk project under a microscope. You may want to re-think how to best implement Agile.

Step 3: What is the timeline of your project

Agile methodologies general support the 2-3 week “sprint” approach versus longer milestones in traditional waterfall methodologies.  The challenge with sprints is similar to dumping a bucket of Legos on the floor and burning the instructions on how to build the Lego house. You are incrementally building small disjointed pieces every 2-3 weeks based on conversations, learning on the fly, and very light documentation or user stories. You may lose sight of the overall requirement and how all the pieces are related in the grand scheme of the project. Imagine how different your Lego house may look in 6 months versus the detailed plan? In addition, tasks may take much longer than a sprint requires. You have to ask yourself if you want the administrative and time burden of chopping long term tasks apart. As a result, your backlog can also become larger than the tasks in the sprint (and project) itself, and you are continuously trying to re-link the effort back to the basic requirements, which are loosely defined to begin with. If your project is a marathon, you may want to re-think how to best implement Agile.


In summary, Agile methodologies were designed for “building” and not necessarily for implementing and configuring pre-built vendor systems. If you are implementing Agile at your firm for a vendor installation, it is important to assess the criticality of the system, the risk of your system, and the timeframe. In many cases, a hybrid approach may be the best solution, where you take Agile’s greatest qualities and combine them with a traditional waterfall methodology, or whatever methodology your firm uses. It’s never a one-size fits all.  If your project has well defined development parts (like interfaces or custom reporting), slices of the project can often be conducted in an Agile form and, in fact, can work quite well.

In part 2 of this blog we will take an in-depth look at Agile’s twelve fundamental principles and break down how you can get Agile to work for you, instead of Agile working you.