Is there Anything Special when Adopting Agile in a Bank?

Ever heard about large or mid-sized bank which is a fully lean or agile organization? Hm…

For the last 12 years I work in a bank. Also, for the last 4 years I push hard agile adoption with some other colleagues. During this period I gave some conference talks and discussed with colleagues how to overcome resistance and to break barriers that lurks when adopting agile in banks. But recently, I found myself thinking is there anything really special when adopting agile in a bank or not? Is there something that should be treated as a special case or banks are only a prototypes of a large traditional organizations?

The first “special obstacle” candidate that came to my mind is a traditional project management. Oh yes, banks have a very long history of project management and most of them are doing it in a very traditional, non-agile way. Since this traditional roots are very deep and Project management offices (PMO) are very important, it is very hard to change things and introduce agile development. Many people think that their skills will not be needed once an organization shift to agile, so resistance is very strong. Of course it’s not true, but it lasts long to break this misconceptions. Because all of this reasons, traditional project management in banks is a large obstacle for agile adoption. But, it is not unique for banks only. I can imagine a lot of other organization types with a same problem. Just to mention a few areas: masonry, science, state administration,… So, zero points so far. Our first candidate is a high hurdle to jump over, but is not special for banks.

Any other candidate?

Yes, Regulatory Compliance. From the first moment when it came to my mind I had a feeling that is much more “bank special” then the first one. For those of you unfamiliar with this term (lucky you:), corporate regulatory compliance is an obligation to follow rules defined by governance or by some internal acts. In case of banks, you can imagine that there is a lot of such rules to follow. Recently, when financial industry was a cause of some economical problems, these rules became more strict. Also, fighting against terrorism and against organized crime added more rules to follow. The result is a lot of regulations that slows down business process. So, there is a great impact to agile development because you cannot remove impediments. Yes, the bad news is that it’s almost impossible to eliminate this waste from inside organization. Regulatory compliance is like a phase of the moon – you cannot avoid it. These rules are here to follow. Sometimes rules will change, but not because of agile coach wish:). So, our second one is a real beast. It is not 100% special to banks, but almost it is! I’m not aware of any other industry which is so much under pressure of regulatory compliance like financial industry.

Let’s try to find some other special obstacles. Here comes a weird one – reputation risk. What? How’s that connected to agile adoption?! Patience, you pure and simple bank client, you’ll find out soon:). Reputation risk is a “mother” of all risks (or at least an “oldest brother”:) in a banking industry. There is not a single bank invulnerable to reputation risk. So, every single thing connected to a possible reputation risk is treated as a high priority. For those with no experience in banking it may be unusual. For example, imagine that avoiding one hour downtime of branch offices is more important then launching a cool product. Weird, ha? Now imagine that external agile coach who is leading agile transition, unaware of importance of reputation risk, produce a big one… What would happen? A whole transition process could fail because of discredit…

Maybe the last one is a bit overstated, but it shows these little differences that could be extremely important. And for sure, there is more such specials. Some will say that all industries have its own differences and they’re right. But, banking is different in a different way. This differences are often unexpected and possibly very harmful for an agile transition. So, knowing this special cases can be of a vital importance for agile transition process.

Coexistence Model between Traditional PMO and Agile Development

I know there is a lot of debate if coexistence between traditional PMO and agile is possible. A friend of mine usually say that being agile or not is pretty much the same as being pregnant or not – you are agile or you are not. Instead in this way, I like to think of this topic like agile is an art of possible. Sometimes is just not possible to adopt all agile practices, because of a thousands of reasons. At least is not possible in short time and for a whole organization.

A month ago I was involved in an initiative to establish such coexistence between traditional PMO and agile  development. It is a quite large organization where agile development grown bottom-up, so a number of development teams already practicing agile (mostly Scrum) for some time. Because of a good results, a consensus in high management resulted in initiative to better organize work between PMO (which is still organized traditionally) and agile teams. After a discussion, I proposed a model like this:

An idea is to enable agile teams to function as much agile as it’s possible inside large organization which is still mostly organized in a traditional way. So, let me explain this idea:


Every agile team is responsible for a single product (application). Notice that I did not say project, but product. Every agile team has Scrum master (SM) and Product owner (PO). So, this part is fully agile and use Scrum.

From the other side, there is a PMO. A PMO will designate a Project manager (PM) for every project they decide to start. PMO is influenced by stake holders, some boards etc. This is a traditional side of story.

So, where is the bond between these two sides? An idea is that PMs will work with all POs whose products are related to a particular project. PMs will influence POs to adjust their Product backlogs to fulfill project goals. Also, PMs will do all administrative project tasks and generally all job that they are familiar. At the same time, development team is isolated by SM and they do their job in an agile way.

Some early results of such approach are very good. A good thing is that only PMs had to modify their behavior, but only partially. Another important thing is to look at this model only as a step in a process of making all organization agile. Any other goal doesn’t make sense.