Agile methodology - how to get more done, with less, for less and still keep everyone happy

Financial services is a good example of an industry embarking on a significant period of change brought about by market demands for greater and easier access to products and services, as well as regulatory drivers like Solvency II and the Retail Distribution Review.

Traditionally, many organisations have used a Waterfall project methodology for delivering change within their organisation. Typically, requirements are understood and validated, followed by solution design, which is then developed and extensively functional and regression tested before being deployed. However, the challenge is that invariably the timeline of this cycle is dependent on the extent of change, and it can take over a year to deliver a working business solution.

For many organisations, this process is simply too long, meaning that by the time software gets delivered, the requirement has invariably evolved in response to market or operational demands. Another major challenge with this approach is that it is hard to change tack during the project to accommodate the changing requirements as they occur.

There have been many articles written about the Agile development methodology; some complimentary, some opposed and some downright controversial. However, as with any project approach, the key is determining when it's appropriate to use it, and even more importantly, when it is not.

For business process problems, coupled with a control tool such as AWD, we believe that Scrum is an appropriate methodology to achieve the more rapid implementation of business controls as it engages business subject matter experts alongside solution consultants as part of a collaborative team. But first, it is important to introduce what Scrum encompasses.

Scrum is an Agile framework for project delivery that supports an incremental approach to achieving business goals. A list of requirements created by the business is managed into the project backlog. As the details of the requirements are signed off by empowered business users, the ScrumMaster and the delivery team manage them into a sprint. A sprint is the packaging of requirements that can be delivered in a fixed time (usually around four weeks) and achieve a potentially shippable business solution.

So how does it work? Take a typical process example that is common to all financial services organisations, a policy claim. The aim is to produce a revised process within a few weeks, so the current "as is" process can be mapped out. Solution consultants work alongside the business subject matter experts to understand the customer journey, customer touch points on that journey, and incorporate this into a new process design, which is then configured within the business process management (BPM) project.

Our experience with the Scrum approach shows us that visualising the process as early as possible better enables the business community to understand its suitability. This will naturally draw out constraints, identify exceptions and finally determine an optimised path for the majority of transactions that will utilise that process. Once the design has been completed and approved, it is tested, and then, subject to normal governance and controls, deployed into production.

The Scrum approach has been successfully used to address specific short-term challenges, for example, reworking of an existing process. It has also been used for more strategic engagements that could incorporate a proof of concept as the first stage.

Projects where the scope is limited to system interfaces benefit less from an Agile approach, like Scrum projects, for example. Rather than a full process or methodology, Scrum is a framework of the Agile methodology. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team.

While definitely not a one-size-fits-all model, this approach has delivered benefits to a number of organisations. It really helps the combined solution/client team determine the art of the possible with process design, as opposed to merely incrementally building on what is in place today.

Interestingly, this approach is also helping to overcome one of the primary reasons why workflow/BPM projects fail, namely business engagement and ownership of the solution. The AIIM (Association for Information and Image Management) published a survey where they asked the question: "What were the four biggest managerial risks experienced during your BPM implementation?”

The top four responses were:

Reason and percentage:
* User resistance to change: 47%
* Lack of understanding of BPM/workflow: 45%
* Underestimated time to map and agree processes: 41%
* Extending ownership across departmental boundaries: 31%
(Source: AIIM, 'Business Process Management - are we making the most of content-driven processes?' 2009)

These results are surprising in that they highlight the "people" factor in projects, which is often harder to quantify and apply metrics around, despite being a key factor in programme delivery. Therefore, adopting a methodology that encourages business ownership and engagement right from the outset could certainly help mitigate some of the key challenges highlighted in the AIIM survey.

Another recurring question in the survey asks which methodology is more cost-effective. As is often the case, there is not a simple answer to what, in this instance, seems a simple question. It really comes down to how you measure cost, your approach to risk, skills of the people assigned to the project and various other factors. However, what most of the analysts/bloggers do say about Agile is that when utilised appropriately, it has a higher success rate when measured in terms of stakeholder satisfaction and delivers an earlier ROI and higher quality solutions.

Respected analysts have been reporting on the need for organisations in the financial services as well as other sectors to focus on the customer experience in markets where customers have more access to information, are becoming increasingly price sensitive, and are demonstrating less sensitivity to advertising. This is known as experience-based differentiation, or EBD, and emphasises the importance of a focus towards customer needs, reinforcing the brand and treating customer experience as a competence, not a function. Analysts position this not as a 'nice to have', but mission-critical to the survival and future prosperity of an organisation, where it is becoming increasingly more difficult to retain existing customers, win new ones and differentiate the organisation's products and services in the market.

In conclusion, it is not a question of either Agile or Waterfall. Both have their place in the delivery of programmes of work and can happily co-exist within an organisation. However, where the deliverable is a human-centric business process then Agile is worth considering. This is particularly appropriate where there is a need for new ideas and thinking, as well as representing a process from an end-customer perspective.

For more information click here