Using Agile for financial services product development

Financial services product development is a dynamic environment that demands agile, flexible and responsive software teams.

What is Agile?

Agile is an umbrella term that covers a multitude of different approaches and formal methodologies like Scrum, XP and Kanban. What these approaches have in common is a simple set of principles first laid out in 2001 in a document called the Agile Manifesto.

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

Those four simple rules might not look like much but they caused a revolution.

In just 14 years there has been a sea change in the way that commercial software is produced and the way that software projects are managed. In the blink of an eye Agile development has moved from the fringes to the centre ground and has firmly established itself as the best way to produce software.

Agile was needed because traditional software and IT projects fail more often than they succeed and their failure tends to remain hidden until very late in the project where it’s most damaging and costly.

Traditional waterfall methods fail because they expect requirements, budgets and timescales to be fixed from the beginning and cannot easily integrate information that’s surfaced during a project. The industry’s default way of working simply couldn’t react to the abundant feedback from developers and users, changing market conditions or business opportunities that occurred as they ran their course.

Agile in a dynamic business environment

We use a fully Agile approach in all internal Product Development activities and utilise parts of Agile for our client implementation projects depending on client preferences. 

We operate in a dynamic business environment and projects built up from multiple, short iterations give us the flexibility to react quickly to changing customer, market and vendor requirements.

For example, if a new version of iOS lands mid-way through a project we can respond instantly, integrating the business and technology implications in a quick, structured and orderly way without derailing the project.

Adapting Scrum

The Agile methodology we use is Scrum and one of its features is that feedback from the project team doesn’t just change the project and the software, it can change the methodology itself.

It encourages customisation and localisation and whilst all Scrum teams start with the same set of principles they will naturally diverge as they gain experience.

Here are a few of the customisations to text-book Scrum that we find are working well for us:

Rotating Scrum Master

The Scrum Master’s job is to remove whatever impediments are standing in the way of a team getting its work done.

We’ve found that it’s natural for organisation, facilitation and planning tasks to fall to the Scrum Master too and we like to rotate the team members through the role.

Specialist Scrum Masters can become a single point of failure (and no self-respecting tech likes those) and rotating testers and developers through the role encourages empathy and stops the development of hierarchies in teams that are supposed to be self-organising.

Estimating with Ideal Man Days

How best to estimate an individual’s time in Scrum projects is a point of continuous debate within the Agile community. We’ve had good success with estimating the size of tasks and features in ‘Ideal Man Days’ – an abstract measure that quantifies the amount of work that can be done in a day free of interruptions and meetings.

Interestingly, our teams’ interpretation of an Ideal Man Day works out at about two normal work days.

Roles and skills

The ideal development team is a fully cross-skilled team that can apply any individual to any task. It’s a worthy objective but the journey towards a fully cross-skilled team isn’t a quick one.

It’s necessary to recognise strengths, weaknesses and career development opportunities along the way and encourage the team to self-organise and distribute the work to appropriately balance the short and long term objectives.

Rotation and movement of team members

Rotating members through different teams is an important part of our development strategy.

Moving team members at the end of every iteration is just too disruptive and keeping teams together for months on end can result in team members specialising, working against our desire for fully cross-skilled teams.

We’ve found a rotation schedule of around of six to eight works well for us – balancing the benefits of keeping high performing teams together and the flexibility we need to meet business and career development goals.