Agile Development: It’s not that hard

Agile is one those lovely terms suggesting flexibility, speed and a dynamic way of working. In reality, it has come to mean many (unfortunate) things to many people:

  • I don’t need to write down business requirements any more
  • I don’t even need to plan, I can just wing it
  • I get to blame other people when things go wrong because they are not ‘agile’ enough

To us, agile means small cross-functional teams working iteratively to delivery technology in ’sprints’ of activity, enabling faster business and technology change.

When looking for ways to implement agile successfully in financial institutions, we think it is sensible to look to the people who have already done it successfully for decades: larger software product companies, who have been using the following key aspects of agile since the early 1990s.

Make friends

Get the right technology and business people working, sitting, having coffee, and socialising together in small focused teams. This may involve dismantling the brick wall, razor wire, and minefield that typically separates the business function from the technology function in many financial institutions. This may mean you must stop blaming each other when things go wrong or if there are delays – you are in it together and you are working closely together in iterative sprints.

Take ownership

Every product needs an owner who acts as a proxy for business users. In the context of financial services, a product could include:

  • a channel application such as online / mobile banking,
  • a system or platform used in branches to maintain accounts, or
  • an interest calculation engine.

Technology people now have someone who acts as a single point of contact to resolve business related questions, really quickly. This ensures technology build sprints are not held-up back lack of clarity in the business product requirements.

Love testing

Think about testing at the start. When you are implementing business change and developing software, you need to deliver both the software change and the code that automates testing the change. Once your testing is automated you can test in seconds if your code / platform / digital app is working as expected. Say goodbye to the end of month long manual regression tests – they simply do not work in an Agile environment.

Time for warp speed

More of this automation: automate a nightly code extract, build, and test cycle. Your teams should use tools and scripts to automate:

  • Extraction of code from a code repository
  • Compilation of that code
  • Execution of the automated tests to confirm the code is good
  • Deployment of the code to your production environment

If you’re working across multiple geographic locations, as many large financial institutions would, you can time your automation so that the output is waiting for your development team in India, for example, to resolve any bugs; who then have notes and questions ready for your team in the UK, for example, to respond to when they kick off the working day.

In this seamless operating mode, suddenly change is fast and quality increases.

Disentangle the spaghetti

Agile development works best for discrete code modules with well-defined interfaces. If your legacy systems connect everything to everything, which many do, you will need to try to disentangle the systems, to some degree, to build the foundations for success with Agile.

This can be done by rationalising and consolidating applications within the bank or by introducing a middleware service bus.

Plan for the long-term

Agile working in an environment with complex technology requirements needs a long-term approach. Think primarily about the long-term quality of the products you provide and how they serve the business; and less about do-the-minimum, one-off programmes and projects that have an inherently short term view.