Agile Contracting and Application Development in Finance Industry
In this initiative, the main goal was to create a customized software solution to meet the unique business needs of a client in the finance industry, which is difficult using off-the-shelf solutions.
The main challenge was to untangle complex business logic from many existing software solutions that have never been documented. Also, the client was not sure what exactly the solution will look like, but they are convinced they need something completely different from their current solution. In this situation, our client was contemplating to either modify and scale up their current solution to accommodate their growing business needs or to buy/build a new solution to replace the existing system.
Prototyping and Validation were recommended as part of the project discovery phase – to solidify what to build and to determine if the market or users will accept it.
Dealing With a Big Surprise
At a point, we were on track with expectations, and we’ve had a portion of the product complete and about to complete the next planned increment in a couple of sprints. Then the news broke that their current payment vendor on the system is shutting down in a couple of months. Although we did not project this news to affect the new product, as we had found a new payment vendor, however, it was a massive problem for their legacy system, as everything was intricately connected to that payment solution.
Instances like this make agile suitable over the waterfall approach to managing projects.
Even though the timing was tight, we agreed to help the client resolve the new issue as quickly as possible.
Unfortunately, we all underestimated the interconnection between the legacy system with a payment vendor. To restore the client’s confidence and to alleviate their troubles, we collaborated and brainstormed with the client to establish the best approach to resolve the issue and finish the project work.
Prototyping and Critical Fixes
The team began with prototyping, as well as critical fixes to the client’s existing system. We continuously adjusted our product backlog to the highest priority: at first, this included critical fixes, but then quickly adjusted to the development of the product the client wanted the team to develop.
Development
The portion of the product we first built was something that could be released on its own, without any dependencies – MVP. This gave us time to figure out other needed functionalities so they would be resolved before development begins. Then, the client determined that rather than finding a vendor to fix one of the dependencies, the team should build it in-house. This was a result of the client’s confidence in the product owner to deliver a product that reflects the high priority business need.
While the team underestimated the amount of work involved in decoupling the client’s existing payment provider and integrating a new payment provider to the code in the original system, it led to the best result: client satisfaction. The team was able to pivot and adjust quickly and help out of a tight spot due to the flexibility in the methodology, which helped the team to develop a more profound sense of trust in our client relationship.
In the end, we achieved the main goal, which was to replace the legacy system with proper documentation so that when vendors change in the future, it doesn’t cause as much disruption – even if a different team will be working on the project.