Friday, May 28, 2010

Agile Adoption in the Banking Industry

I was organizing my email today (large backlog as usual, need to put in a policy where I purge things after 6 mths) and came across a summary I had from an agile adoption survey a few of my colleagues conducted with several large banks. This is by no means a scientific survey, just one that was conducted with senior leaders from several different banks. Thought it was interesting to share. Here are the key findings:

1) Banks are using agile in tactical ways

2) Their usage is largely limited to applying two practices “iterative development” and “co-located teams”

3) Architecture is not interested

4) Business and development are interested with QA on the fence

5) Compelling reason is reduce time to market

6) Main barrier is cultural, looks like there is a strong culture factor against it

7) Key challenge is estimation, they are unable to apply it within their current budgeting model

8) Key success factors are executive sponsorship with appropriate coaching

This aligns with a general observation that I have noticed as well. The movement is largely developer driven with business wanting to get in but challenged by their budgeting model. Architecture and QA are largely not bought in.


  1. From the people I know in the Architecture end of things, most of them don't get it. They have that same misnomer that Agile doesn't involve design or architecture. These are the same people I know though that spend their time designing systems but have no idea of actually how to implement them. I'm a developer and in my generation (the younger guys) of developers that I know, it's somewhat foreign to us as to how you could develop software in a non-agile manner.

  2. We are currently in the process of transitioning a large bank and our strategy was to start with #8 (Key success factors are executive sponsorship with appropriate coaching) and move to middle management training and coaching. Results to date have been positive. I expect to share some learning on my blog shortly.

    Thanks for posting.

  3. I can see where QA is coming from (especially with tightly coupled environments which in turn increases regression efforts). QA folks know they are the last line of defense for quality. Any defects discovered in production is another X against QA.

  4. It seems like a good (and natural) start to me. Your points show both curiosity and a willingness to explore within the organizations. #8 to get executives approval is the key. If you get this, then the approach becomes an expectation and resistant functional areas will need to start adapting.