Keeping up with customer expectations - with Agile ALM

In the crowded, hugely competitive and increasingly digitally driven FS sector, software is being developed and rolled out faster on an unprecedented level.  I’m not just talking about implementing whole new IT systems, but all the software updates and new features that are happening at an increased cadence. The financial firm that fails to keep up with all this is at risk of not meeting customer expectations.

The problem is that while there is not the luxury of months to spend perfecting a software release, equally it is important not to send out software into the market with too many bugs.  This is why Agile – that popular methodology that stemmed from the software world and is now being adopted across all kinds of industries – is increasingly being applied to ‘application lifecycle management’, often abbreviated to ALM.

ALM does pretty much what it says on the tin: controlling each software component at every stage of its life, from ideation right through to on-going maintenance.  Given that in the financial services world, software is not only frequently updated but also needs to last decades (to support legacy customers and also compliance requirements), this long-term view is essential.

ALM has been around for some time, but it’s currently going through a resurgence and evolution, with organizations appreciating the need to look at the whole software lifecycle, but to have a form of ALM that is more in tune with today’s fast-paced, highly collaborative and – yes – Agile software environments.

Apply Agile to ALM and benefits can include: faster delivery of quality software releases; improved collaboration across times; and prioritization of customer needs.  Sounds impressive, but what does it involve?  Put simply, Agile ALM is the practice of using Agile processes to manage software requirements, issues and tests, which are all integral and well-established parts of the software development cycle. 

While ALM is all about tools, Agile is all about people, so a logical starting point for understanding Agile ALM is looking at the four main principles within the Agile Manifesto:

Individuals and interactions over processes and tools

Traditional ALM is typically governed by steps for product completion, which can unfortunately create siloes.  Agile ALM instead focuses on cross-functional team interaction, because gathering requirements is fundamentally a collaborate process.  Products are built and tested in sprints, which supports better collaboration throughout that process.

Working software over comprehensive documentation

Traditional ALM is typified by lots of documents, while Agile favours fast releases instead of documentation.  In industries that need extensive documentation, Hybrid Agile bridges that gap by providing the documentation that’s needed, but still follow Agile principles.

Customer collaboration over contract negotiation

Customer feedback in traditional ALM is delivered as requests for bug fixes of features and it does not inform requirements, whereas in Agile ALM, customer feedback is often included in requirements gathering.

Responding to change over following a plan

In common with other older software practices, traditional ALM is focused on having a plan, which is set at the beginning and followed through to deployment.  That doesn’t work in today’s very flexible world, so Agile ALM is designed to respond to change, with any plan allowed to be in a state of flux.  Team members can be more productive by delivering the right functionality at the right time, which in turn can help reduce costs, while giving customers something that fits their actual needs at that point.

Going from theory to practice

While the theory of Agile is elegantly straightforward, putting Agile processes into practice takes some effort, plus making the transition from traditional software development processes like Waterfall takes time. 

Agile adoption needs to be iterative: don’t try to do it all at once and, don’t give up at early hurdles, such as people trying to do Agile too quickly, becoming disoriented and discouraged from thinking that Agile can be organization-wide (it can).  In our experience, we’ve seen how individual team members become more comfortable with Agile processes as they go along and Hybrid Agile – practicing some parts of Agile but not for everything – can aid smoother adoption. 

Agile requirements

A good approach with Agile ALM is to introduce Agile to each of the traditional software lifecycle phases.   For instance, collaboration on Agile requirements, which unlike traditional requirements, are set in user stories, when they are needed and constantly reviewed, refined and reprioritized.  For example, a traditional requirement might be to comply with a specific ISO standard, while the Agile equivalent will say why that’s needed (for instance, to manage risk more efficiently). 

Another lifecycle phase is issue tracking, where traditionally issues are found by testers and resolved before the software is released.  If a customer then finds a bug, it is added to a list of pending fixes, assigned to someone and at some point, resolved.   In Agile issue tracking, the team works through a backlog of issues, in a collaborative way and as fast as they can, based on issues being prioritized according to impact. 

Next up is Agile testing, which unlike traditional testing – which takes place after a software build is completed and are often manual – happens continuously.  Test cases are set based on user stories.   When new ones are added, so are new test cases.  Testing is typically carried out in sprints, often involving test automation to keep up with the pace.  Another difference is that Agile test plans are constantly reviewed in line with changing needs.

Right tools for the job

So that’s the theory, the next thing to consider is finding the right Agile ALM tool to support all those tasks.  Above all, it needs to be tightly integrated into the organization’s development environment and easy for teams to collaborate on requirements, issues resolution and testing, but also easy to use: there should no heavy-duty learning curve.  Something else to consider might be the need to support both traditional and Agile development processes, particularly if Hybrid Agile is being used, and to support the transition to full Agile when the time is right.   Finally, make sure that the tool can scale up to keep pace with demand, be that changing or increased software complexity, new software platforms, users or locations.