The post-pandemic era has ignited monumental changes in the global financial realm, forcing financial services institutions into unchartered territory when it comes to digitization. Many startups and more and more legacy financial services institutions are reaping the benefits of employing an Agile methodology to digitize at scale and address the customer expectations of today. Agility not only offers institutions a path toward expedited change but a way to simplify complex operations.

In this blog, I define Agile, explain the key components of an Agile approach, and provide an example of a financial services firm leveraging an Agile methodology to create new products that contribute to elevated customer experiences.

What is Agile?

Agile is a development methodology that serves to help teams prioritize certain things over others in the pursuit of developing most efficiently. The Agile Manifesto declares that Agile works should value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

There are 12 principles that support the values exhibited in the Agile Manifesto:

In recent years, the Agile approach has gained popularity over its more traditional counterpart, the Waterfall methodology, which has a more linear structure. When following the Waterfall methodology, requirements and expectations are gathered at the start of a project, and a sequential project plan is created to accommodate those requirements. The drawback to this approach is that the customer often does not see what will be delivered until the project is close to completion, rendering it more difficult and costly to make edits in instances where the customer is dissatisfied with an aspect of what the team has built. The Agile methodology inherently creates more opportunities for periodic reviews than does the Waterfall methodology; thus, the customer gets to offer more feedback on the project.

Many financial services firms find value in this increased collaboration and are marching towards using Agile transformation on an enterprise level. According to Charles Darwin, “It is not the strongest of the species that survives, nor the most intelligent; it is the one most adaptable to change.” However, the shift to Agile from another methodology is usually one that institutions deploy gradually, and there are many crucial things to understand to implement an Agile transformation initiative smoothly.

Key Components of Agile

1. An Agile organization consists of many multidisciplinary squads, or small teams of individuals, that join forces to complete a specific aspect of a project. The four main roles in a squad are:

Product Owner: Product Owners define the product vision. They keep the team on track, and have a strong hold on what needs to be built, and how and when works should be carried out.
Team Lead: The Team Lead’s purpose is to facilitate open communication, act as a liaison between groups, and answer questions.
Development Team Members: The Development Team typically includes developers, designers, testers, and a quality assurance team. They are who build the products.
Stakeholders: Stakeholders are typically either external clients or some other type of interested party. They want the product that the team is building. Everything is built with the stakeholder, or end user of a product, in mind.

Although a one-size-fits-all approach does not apply when planning for squads, squads are highly encouraged to set working agreements, or guardrails, during Sprint Zero and constantly retrospect to make continuous improvements throughout a project. This allows the squads to be flexible while continuing to deliver within an Agile framework.

2. There are different methodologies under the Agile methodology umbrella. Before deploying a project, squads should agree upon the most sensible methodology for their needs. Here are a few most frequently used methodologies:

3. The Roadmap is a living document that determines the team objective and can be continuously added to and reorganized to suffice business needs. Business stakeholders utilize many different techniques and tools when building a Roadmap, such as market research and customer intelligence data. Defining a clear Roadmap is an imperative beginning step in an Agile project.

4. Once the Roadmap and team objectives are established, stakeholders should work with information technology partners to identify high-level solutions. Preferred technologies (UI/UX technologies, backend technologies like Java, .Net, ETL Informatica, etc.) for the backend and front end will be identified based on the Roadmap.

5. Agile works are executed through a series of “sprints,” which are time-boxed periods during which a squad works to complete a specific aspect of an overarching project. There is not a fixed number of sprints required for an Agile project; the amount of sprints in an Agile project depends on the scope of the project. A new sprint starts immediately after the preceding sprint ends. During a sprint, work is done to create new features based on user stories and backlogs.

User story: A brief description of what a user wants a product to be able to do for them, and why; eg., “As a banking customer, I want to better understand my finances, so I can feel more in control.”
Backlog: A prioritized list of deliverables that must be completed as part of a product’s development.

6. An Agile project begins with Sprint Zero. Sprint Zero does not have a prescribed duration, but it typically lasts two to four weeks. A few prerequisites must occur before Sprint Zero ends and Sprint One may begin, outlined in the checklist below:

7. After Sprint Zero is complete, Sprint One begins. The following should take place in each sprint from this point forward:

Sprint planning should take place first thing on the first day of a sprint to utilize the maximum time of work for the squad.
The backlog should be analyzed and prioritized at least once weekly to ensure it is based on business priority.
A stand-up meeting should occur daily, and be a high-level, fifteen-minute meeting that allows each project contributor to give a brief update on their latest progress.
Refinement/backlog grooming works to ensure the user story is fully and comprehensively understood by the team. If the user story is fully understood during this backlog refinement, and no follow-ups are needed, then the stories can be estimated for the amount of time they will take and the scope of work that must ensue to execute them. Development and quality assurance engineers can estimate stories in the form of story points, units of measurement that determine how much effort a piece of work within an Agile project will require to be completed.  Story points are to be mutually agreed upon by the team. All stories prioritized by the Product Owner that meet the definition of “ready” should be added to the upcoming sprint plan. Although it is not required to add subtasks to stories, it is highly recommended to do so during sprint planning. This helps ensure teams fully understand the stories; hence they can map out the steps for that story to meet the definition of “done.”

Refinement/backlog grooming should take place at least twice per sprint. For example, if a squad is set to start a two-week long Sprint One on Wednesday, the first backlog grooming should occur on Tuesday of Week One, and a final backlog grooming should occur on the Tuesday of Week Two, as the next day (Wednesday) will mark the start of Sprint Two.

If the squad is not fully cross-functional, it is recommended to measure capacity using working hours instead of only measuring based off of story points. Measuring capacity in hours allows each team member to log progress daily. This not only produces ideal burn-down charts but also helps the teams plan their work efficiently while not overcommitting. Overcommitting causes spillovers that do not go in favor of the team’s performance.

New teams should plan their work for 75% of their capacity while reserving 25% of their capacity for ad hoc tasks. For example, if a two-week sprint is 80 hours of work, a team should plan for 60 hours of power work per engineer. Twenty hours should be allocated to Agile ceremonies (sprint planning, daily stand-up meetings, sprint demos/reviews, and sprint retrospectives) and any ad hoc tasks that must be completed during the sprint. This allows the team to work on tasks that are unknown during sprint planning. Unknown/ad hoc tasks should not take up the majority of an engineer’s capacity. In case of issues that take precedence over planned work, the Product Owner must reprioritize the active sprint backlog, and then the sprint scope is changed.

Sprint demos are to occur toward the end/last day of a sprint.
The sprint retrospective takes place at the end of a sprint to reflect upon what went well, and what needs improvement, and establish the action items needed to make identified improvements.

Case Study: How We Leveraged Agile To Help a Financial Services Firm Create a Deposit Advance Product

One financial institution realized the benefits of transforming to Agile when it asked us to help create a deposit advance product (a short-term loan designed to assist customers in times of immediate need). Employing an Agile methodology to execute this project was extremely helpful when it came to determining how to best exhibit this product to customers and keeping the creation process organized.

First, we laid out the Roadmap to understand the features we wanted this product to have and how to go about constructing these features. For example, while creating the Roadmap, we had to determine the channel through which the customer would be notified about the product (phone, email, text message, etc.) because it would impact the user interface and user experience, and thus, the production process. We decided in the Roadmap that customers would be notified about this product via a pop-up message on their online banking account platform.

In the road mapping process, we created user stories that were groomed and refined by the whole team. User stories were written by Product Owners from the point of view of the end customer. A user story for this deposit advance project was, “As Customer A, I want to get this deposit advance so that I can have immediate funds put into my account.” During this refinement process, the team decided the best way to achieve the ultimate goal of the user story and how many tasks and sprints it would take to achieve the goal, prioritizing the order of each one and identifying which MVP made the most sense to complete first. Since we were using a pop-up notification method, we had to determine the segmentation of customers who would receive the pop-up, the process that the pop-up would take the customer through, and at which point in this process the customer was to be redirected to a different bank-branded page that included more specific product details and action items. Once these decisions were made, the project was deemed “ready.” Once the definition of “ready” was met, we had to estimate the story and the volume of work it would require to achieve it (one popular method to estimate a story is by using the Fibonacci sequence).

Once work ensued, our team had daily stand-ups where we discussed what part of the workflow or project needed improvement (i.e., do we need more Product Owner time, more capacity?), and then made the necessary movements to convert these pain points into action plans. Our team, as true Agile teams should, used the continuous improvement, continuous delivery (CICD) model.

We conducted each subtask’s sprint using this continuous feedback loop, and once each subtask or project met the definition of “done,” meaning its code accomplished what was intended and was demoed and approved by the Product Owner, we moved on to the next sprint until we had our final deposit advance product.

Perficient Can Help Your Financial Services Firm Realize the Benefits of Agile

The number one tenet of the Agile methodology is that every facet of development contributes to an overarching objective. Agile transformation is a complex effort that requires extensive coaching across various teams. And we understand that transforming to this way of working has a learning curve and often occurs gradually.

No matter where your financial services institution is in your transformation journey, Perficient’s subject matter experts can assist you in going through a successful end-to-end Agile transformation while ensuring delivery with quality. Many of the world’s largest firms trust us with their Agile transformation journey. As a result, their most innovative, highly visible, and resource-intensive projects have been successfully delivered to accommodate changes in today’s competitive market.