Moving towards agility - EdgeVerve · Moving towards agility THOUGHT PAPER. 2 ... and tangible product increment is ... Agile is like a spectrum; banks have an

Anyone who has worked in the banking domain can tell that both IT vendor and bank face a dilemma when it comes to core banking replacement.

Have you ever thought why so many large programs face rough patches while walking the path of IT transformation? A fear of failure, rather than the anticipated joy of success, has gripped the IT transformation of the big elephants in the banking industry. The record shows that more than half of IT transformation programs do not see success. The reasons could be many, including the following, which we have observed:

Moving towards agility

THOUGHT PAPER

2 | Infosys

If the rate of success is so low and

challenges in terms of manpower, time

and money so big, should banks stop

looking at the opportunity to modernize

their core banking ecosystem? We believe

that transformation programs should

not be written off, simply because of the

fact that it is only through core banking

transformation that a bank can unleash

operational efficiency and acquire the

momentum to compete effectively. So

the question is not whether or not to

undertake a core transformation program,

but rather, how to do it and which

methodology and principles to follow.

Introducing Agile

Agile is one of the upcoming transformation

methodologies. However, like any other new

player in an established market, Agile also

received a lukewarm response gaining few

takers, especially in the product landscape.

Their biggest arguments – apples versus

oranges, and one size does not fit all. They

believed that Agile was suitable for the

service industry where projects are started

from scratch, but was not optimal for

products.

While the product companies lived in denial,

the takers of Agile grew in number and soon

it had success stories to show. Banks and

financial companies started to recognize

the benefits of Agile – that it pushed players

to rise above the mindset, which said that

financial products could only be delivered in

a Waterfall. IT companies started harnessing

the opportunity, realizing that Agile was

most applicable to the financial industry.

Why Agile?

What is it that makes Agile rise above the

traditional waterfall and why is it creating

a buzz everywhere? The answer lies in the

methodology itself, which from the very

outset tries to break down and simplify

the program life cycle. The basic principle

of Agile is to fail early, rather than succeed

late. It is a time -boxed iterative approach,

in which vendors logically plan smaller

releases, knows as sprints or iterations, at

the end of which a potentially shippable

and tangible product increment is

delivered. Banks apply the 80-20 rule, that

is, they try to identify and address high

priority items, but with small effort.

Simplification

Agile doesn’t believe in the Big Bang.

The whole idea is to break the complex

transformation program into multiple

simplified steps and harness early business

benefits for banks to gain their leadership’s

confidence.

Faster time to market

Agile attacks the problem of the typical

software delivery model, which is that

stakeholders cannot realize any tangible

benefits until the mammoth task of

transformation is complete. Agile helps

banks by quickly delivering a business

function with limited features and then

continuing to add more functions. This

helps in gaining first mover advantage.

Reasons for Failure of Core Banking Transformation

Complexity

in migration

Communicationlapses b/w

Vendor s andBank s teams

Change indynamicsleading to

scope change

Dependencyon Legacy

and itsin�exibility

Big BangApproach

Complexityof IT

Landscape

Lack ofOwnership

of Bank

Limitedvisibility and

control ondeliverables

IT CostsRun Over

Transition ofcore teamsof Vendors,SI and Bank

Lack ofoperational

readiness

EarlyIssue

detection

Faster time

to market

Adaptability

More

transparency

& visibility

Simpli�cationRisk Mitigation Why Agile?

Early product launchPrevents defect leakage

Re-plan and optimize Outcome traceability

Ea

rly

fe

ed

ba

ck

Pro

gre

ssive

de

live

ries

3 | Infosys

More transparency and visibility

The lack of visibility and control is resolved

by the deliverables for different sprints

or iterations defined in each release,

which are delivered by the vendors

to the embedded team onsite, which

does the required business validation

before acceptance. A working product

demonstration is made to stakeholders.

Adaptability

The “inspect-and-adapt” approach reduces

the risk of getting an irrelevant and

outdated product at the end of delivery,

and also rules out any change requests for

aligning the project to shifting business

requirements. Agile empowers the

stakeholders to continuously re-plan the

releases and optimize the plan to stay most

relevant and competitive in the market.

Risk mitigation

Agile helps to mitigate market risk to

a great extent. Early feedback from

stakeholders, progressive gathering and

building of requirements, greater flexibility

in accommodating changes to these, and

most importantly, early cancellation rather

than late failure help in making Agile least

risk prone.

Early issue detection

Since the deliveries are planned in small

iterations, the bank need not wait till the

end of the project to do operational/user

acceptance testing. Instead, the inclusion

of testing at the end of each iteration or

release ensures that critical defects are not

permeated to the end stages of the project,

but are captured and worked upon early.

The above diagram showcases a hybrid

Agile methodology in practice. Core

banking products undoubtedly operate

under a different set of ground realities

and hence different rules apply to their

implementation.

• Business comes up with requirements

and unlike in the Big Bang approach of

the waterfall model, business critical

requirements are prioritized and

segmented in the first few releases ,with

‘nice to have’ features and wish list items

relegated to the last set of releases.

• Based on factors, such as priority,

criticality, complexity and the sequence

if applicable, sprints are designed under

a given release. For example, to launch

and offer a product in the market, the

primary step would be to configure the

product, do customer onboarding, offer

the product to the customer and then

manage its life cycle.

• Under each sprint, tasks are configured

and tracked in the system in the form

of a dashboard. The dependencies

between sprints and tasks are marked

out clearly.

• The first release may not be realized as

quickly as Agile advocates would like,

the reason being the time required

to set up and configure the base

product with seed data on which the

customization or localization layer must

sit.

• Once the base product is deployed and

available, the subsequent set of releases

providing add -on features to the

existing set of products or for launching

new products can be controlled and

rolled out much faster.

• In a typical core transformation

program, the first release may take

somewhere between 3 and 6 months

Hybrid Agile Methodology for Core Banking Implementation

Re

qu

ire

me

nts

fro

m b

usi

ne

ss

Dis

trib

uti

on

of

fun

ctio

na

lity

in

to s

pri

nts

Critical Business needs

Release 1

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Plan &Develop

Feedback

*Includes Base Product

setup and con�guration Release 2

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Dis

trib

uti

on

of

fun

cti

on

ali

ty i

nto

sp

rin

ts

Priority 2 Business needs

Task 1

Task 2

Task 3

Task 1

Task 2

Task 3

Deliver

Validate& Evaluate

Release 1 : Relatively longer release

Acceptfunctionality

Go-LiveEarly Launchwith basic features

Go-LiveAdd-on features,New products

Release 2 : Shorter releases from hereon

Plan &Develop

Feedback

Deliver

Validate& Evaluate

© 2014 Infosys Limited, Bangalore, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.

About Infosys FinacleInfosys Finacle partners with banks to ‘simplify’ banking and arms them with accelerated innovation to build tomorrow’s bank, today.

For more information, contact �[email protected] www.infosys.com/�nacle

Varun Goyal Lead Consultant, Infosys Finacle

based on how many customizations

are prioritized and clubbed with the

base product release. From there on,

subsequent releases may be rolled out

every 2 to 4 months.

• Each release will have its independent

requirement gathering session and

solutioning, build and testing stages

followed by operational or user

acceptance testing.

• The releases need not be sequential

in nature. Activities between two or

more releases may happen in parallel.

For instance, while Release 1 is in build

phase, requirements for release 2 may

be gathered, and while testing of release

1 is going on, build for release 2 may

start.

• The bank is able to bring critical

business benefits to consumers much

faster as time to market is reasonably

short and cycles for go-live are iterative.

Unlike in the traditional model, the

bank need not wait years to realize the

tangible benefits of the transformation

program.

• The bank may designate some releases

as internal and others as business

releases with actial business go-live

It is prudent for large banks not to

shift their development methodology

paradigm to a new methodology without

the potential of formidable, measurable

business improvement and efficiency. But

in order to realize the benefits of the Agile

methodology, banks must time it right.

Agile is like a spectrum; banks have an

option to adopt selective Agile practices, to

the extent they want to, as well as identify

a sweet spot, which works best for them.

It is worthwhile to start with a hybrid of

existing methodologies and Agile elements

and tailor them to achieve the business

objectives in a time bound fashion. After

acquiring hands-on experience with Agile

methodologies and realizing its benefits,

once the ground becomes fertile for Agile

to nurture, banks can progress towards

extensive and elaborate Agile project

management and tools.

References

1. http://epmlive.com/articles/5-benefits-

of-agile/

2. http://en.wikipedia.org/wiki/Agile_

software_development

3. http://agile-only.com/master-thesis

4. http://www.versionone.com/Agile101