Agile Banking Transformation

I was reading the agile manifesto recently:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

After reading the manifesto, I can certainly see how this works very well for small to mid sized software development projects but are these tenets applicable to a large banking transformation program with many stakeholders?

Is it possible to be large, complex and agile?  I’m not sure, but I think this needs to emerge as the new normal for banking transformation projects: nimble, flexible, and aligned to the business needs.

Here are some of the architecture and delivery concepts that can contribute to agile banking transformation:

  • Architectural layers that absorb change:  change happens, and having decoupled layers that are ready to address and respond to change helps to avoid complete redesign when this occurs.  A good architecture is a flexible architecture.
  • Collaboration breaks down silos in design and delivery:  Agile methods promote frequent communication and teams working together.
  • Reduce bureaucracy:  Large projects can become cumbersome and laden with processes that are not contributing to the end result.  Agile methods promote the idea of small groups of really good people working together toward a common goal.
  • Structure the releases into bursts:  by breaking up the work into smaller sprints the project can more easily adapt to changes and more quickly deliver benefits.
  • Design for use: An iPad can be used by most people immediately without reading any extensive documentation — and the same can be said about most of the apps available on the app store.  The reason is that the design is intuitive — if banking software works intuitively the team can spend less time trying to explain the workarounds and quirks.

Agile concepts promote good design and lean delivery.  Applying the spirit of agile can help support transformation, and blending some of these concepts into more established approaches has the potential to make banking transformation programs flexible and nimble.

2 Responses to Agile Banking Transformation

  1. The concepts of an implementation based upon agile is interesting, if it’s well communicated and part of the transformation process from the start, or at the very least as you pointed out, enough of the concepts are part of the process. I’d also be interested in your views about adding DevOps to a program. Could a core banking transformation handle both methodology changes?

    * The postings on this site are my own and don’t necessarily represent my employers positions, strategies or opinions.

  2. I think it is possible to incorporate both DevOps and Agile concepts — but a full core banking transformation initiative requires a methodology that also orchestrates the macro level activities and ensures that the right components are being built (using Agile methods) in the right sequence.

    In the end I think the program methodology needs to be well defined, well understood and the drum beat from which the cadence of the program emerges. Without clarity — regardless of the method — there can be major challenges.

Leave a Reply

Skip to toolbar