Development Methodologies in FinTech: Can Startups Live on Agile Alone?
FinTechs are very different than most traditional financial institutions. They use the world’s most advanced technology and strive to make financial services accessible and clear to everyone. Traditional financial institutions, however, tend to maintain legacy architecture, are often bad at end-to-end integration, and usually lack the motivation to change. As you might imagine, these two entities don’t often mix well.
But strangely enough, an ultra-modern, tech-heavy FinTech startup that utilizes Waterfall isn’t a black swan in the financial sector. Throughout FinTech, one encounters any and all mixtures and modifications of Scrum, Kanban, Lean, or even proprietary methodologies (we will explore one such case later in this article). In this piece, you’ll learn how FinTech CTOs reconcile discrepancies within their projects.
Agile with a pinch of Waterfall
It’s a rare occasion that a company gets its optimal methodology right from the very start. Roland Collins, former CTO at InvestEdge, says that they used their own proprietary methodology that resembled Waterfall from day one. As the company shifted toward a product-based approach, it became clear that the old product-management methodology couldn’t keep up with the fast decision-making process and flexibility that was required of them. So, the product-management team became fully Agile. Collins says that they’re going to shift back to the Scaled Agile Framework.
Sometimes, startups chose the opposite motion vector—going from Agile to Waterfall. Mark Worsey, Vice President of engineering at MyVest, says that they’re using an agile software-development process and deploying it for more discreet waterfall events. This is because most of their customers are regulated financial institutions that tend to have their own deployment and acceptance processes.
MyVest adopts best practices from agile development processes where relevant. At the same time, they still operate under “waterfall-ish” influences driven by their customers’ acceptance protocols, so the company uses a combination of approaches that work in tandem. Thorough sprint planning, MyVest conducts classic two-week sprints and daily Scrum stand-ups.
“We’ve got rules around how we think about the number of story points for a particular feature and its technical complexity, as well as what areas of the application it touches that allow us to accurately assess our development backlog.” –Mark Worsey
For client ease, companies often choose to make a trade-off; they ask clients for feedback and implement a methodology that is beneficial for both.
Matthew Rennie, Vice President of engineering at Jemstep, has implemented development squads comprised of multiple development engineers and dedicated test engineers. The teams typically consist of full-stack engineers with broad skillsets, so that within each squad, there is a comprehensive set of skills. Rennie explains they aim to minimize documentation with a fast-paced collaborative and self-organizing attitude. This allows them to build a working product early and then iterate on top of the minimum viable product.
Jemstep’s development is feedback-driven and agile, and they work with their clients— including banks, credit unions, broker dealers, insurers, and RIAs—to ensure that their core values are aligned, and that they can collaborate to create a platform that fits their needs.
“They are more traditional in the way that they obviously treat various development projects. I think that what we do in those particular cases is look to overlay the more traditional project-governing structures over our more lean and agile job practices, and that’s a continuous evolution.” –Matthew Rennie
The “limited work-in-progress” principle at its best
There are a few alternatives to various mixtures of Agile and Waterfall only, and optimized team organization contributes to the overall development process. Chris Nicola, CTO and co-founder of WealthBar, utilizes the Kanban approach for product-development flow and work-tracking systems. They apply limited work-in-progress, a principle of Kanban, to avoid creating a large backlog of work that can’t get completed on time. The team focuses on top priorities, meaning that only when the first task is finished do they move on to the next. By building different queues for different areas of the product, the company doesn’t just focus on one aspect of development improvement but improves other internal processes as well.
Nicola’s enthusiasm for lean manufacturing led him to apply these principles to the company’s software-development process. He tries to create a culture of continuous improvement for the product team in which they can constantly see, observe, and measure themselves and get better with each process cycle.
Each company understands and implements this principle in its own way. David Briand, Head of Software at Nest Wealth, utilizes so-called “product pods” to prioritize and implement their “startups-within-a-startup” development model. Each “pod” comprises one product manager, one product designer, and a number of engineers who are responsible for both building and testing the features they deliver to the platform. Some pods are more focused on functionality, some on end-user scenarios, and others on platform enhancements.
“We’ve been able to come up with a fairly effective marriage of new-age software-development theories with the more traditional […].” –David Briand
These autonomous pods take responsibility for planning their workflow, coming up with new ideas, and developing new features and products. In addition, the pods manage their own timelines and release cycles. All three pods use the same tools such as source-control management and testing tools.
Although this pod approach is novel to most tech companies, it gives Nest Wealth a big advantage in moving rapidly and innovating financial service and wealth-management solutions. Briand also pointed out that Nest Wealth uses a hybrid approach, acting more agile internally while helping their clients comfortably adopt a more modern approach to consuming software.
Being global means being miscellaneous
Everyone has their own truth, and every company has its own optimal methodology. Can we say the same about individual teams within one company? Agile is an important attribute for companies with development centers worldwide. Greg Eisenberg, Director of Engineering at Laserfiche, says the company has dozens of software teams in three different locations—Long Beach, United States; Toronto, Canada; and Shanghai, China. Their software-development teams are primarily agile and generally follow the Scrum methodology. Eisenberg says that Scrum is not a requirement, so some teams utilize Kanban more than they do Scrum.
“We emphasize cross-functional teams with developers, user-experience engineers, user-education engineers, and testers working together to focus on user needs. We focus our development process around user stories that are derived from use cases.” –Greg Eisenberg
But what if you seek to run several products with different goals at the same time? What methodology would you choose? Vasyl Soloshchuk from INSART FinTech engineering, says they successfully mixed Scrum and Kanban methodologies in one of their projects. They created this methodology gradually, but it can be used for any project under certain conditions.
“In our situation, the model was efficient because it appeared under several conditions. Developers never hesitated to suggest enhancements, UI improvements, and new features. The product owner had complete confidence in the team of developers. The efficiency of each developer could be monitored, and unproductive developers did not stay long in the team. The team leader and product owner knew the developers’ abilities and were able to estimate their effort.” –Vasyl Soloshchuk
Among Scrum elements, they adopted Product Backlog, Planning and Daily Scrum meetings, as well as Product Owner and Scrum Master roles. The main Kanban feature used in their model is the modified Kanban Board, a great work- and workflow-visualization tool. Soloshchuck says that this approach gives them a range of advantages:
“The product owner doesn’t require exact estimates; this is why each developer can maintain the quality of development. Based on workflow visualization, it is easy to find out who has caused a QA or code review failure, so everybody understands their responsibility. The team is motivated. Their proactive attitude usually [gets] a positive response from customers, which arouses the team’s interest in the results.” –Vasyl Soloshchuk