For a long time, most banks thought that their strategy was their key differentiator. You look at any investor presentation and it goes on and on about the unique strategy the bank has to build primary relationships or to attract switchers or for something else. In the process, the banks paid millions to various consultancies to help formulate these strategies. Every new director brought his preferred consultants with him to junk the former strategy and create a new one.
On the ground however, there was very little difference in how all of us were thinking. The same people moved between various banks, they went to the same industry forums and shared similar ideas. To anyone with even an iota of brain, it would have been fairly obvious that we were all saying and doing the same thing, only labelling those differently. I am embarrassed to admit but it was only after doing the same tango for several years did I realise that our strategies were all the same – which is typical of companies stuck in utility mode. The real differentiator is the ability to deliver innovation and change. If implemented properly, that’s indeed what Agile enables you to do.
Agile – What it isn’t
There are many good resources for what Agile is so I am not planning to cover the same ground again. In a nutshell though, agile is about delivering software in small increments. But herein lies both the strengths and limitations of Agile.
In most companies Agile is indeed used only for software development, and since software development in most companies is performed by the IT department/team, by extension Agile is only used in that area.
So a typical agile model that I have seen applied in most banks looks something like this (or a variant thereof)
I call this model Pseudo-Agile. Like democracy in North Korea, it sort of gets the process (there are elections and people vote) but it doesn’t get the underlying concept. For that matter, I think that even the Agile Manifesto does a very poor job of communicating what Agile working is intended to accomplish. Like badly articulated strategy, it focuses too much on the process (cross sell more anyone?)
There are many things wrong with the model in the image above, some are obvious to see and some not so much. So instead of critiquing the model above, which may or may not be same as what you use, I am going to explore a generic framework that can be used to evaluate the Agile maturity of most organisations. However, since Agile working is intrinsically linked to personal motivation, we need a common understanding of what actually motivates people. Thankfully a Ted talk by Daniel Pink does an incredible job of explaining that in all of 18 minutes. If you haven’t watched it already, I highly recommend doing so. And if you have already watched it, watch it again to remind yourself.
In essence, scientists discovered that financial incentives work well to improve performance when the task is simple and the answer is clear – think a standard process that needs to be repeated. However, when people are asked to solve problems where the solution isn’t obvious, and lets face it, most problems in mature organisations fall in this category, the financial incentives actually reduce the performance (Yay for banking bonuses!). Let that sink in for a minute – beyond a reasonable salary, increasing financial incentives to solve difficult problems actually delivers worse outcomes.
So if the years of standard compensation practices don’t work, what actually works then? Well the secret sauce is a combination of
- Purpose – Knowing how what you are doing contributes to something bigger
- Autonomy – Knowing that I control my own destiny, or in other words being able to shape things myself or in a small group. In essence, not being stuck in approval hell and multiple steering committees.
- Mastery/Expertise – The desire to get progressively better at something that matters to you
The four pillars of Agile
Agile takes the motivation pillars and adds one more – breaking down the silos, or as I call it, the Troika model.
Purpose – At the beginning of the post I said that it’s not about strategy but actually about implementation. Let me now qualify that statement. It all does indeed start from strategy. Good strategy gives purpose, bad strategy gives targets.
Mature Agile organisations also don’t force a standard interpretation of the purpose throughout the organisation but rather let people define what their own purpose should be – of course in a way that it contributes to the bigger purpose. In the next blog post, I will share how we do this at ING and share some examples.
Autonomy – How often do you hear “its no longer in our hands” in your organisation? Can people take code to production or make changes to customer journeys without seeking lengthy approvals? In most cases I have come across, the answer is a resounding no. This is true even for organisations that pride themselves on their Agile transformation. For instance in one large UK bank, the agile team has representatives from 7-8 different subject matters. The double whammy is that if such a large team can indeed come to a decision somehow, every decision then needs to be approved by the line management of each of those areas. So much for autonomy!
Unfortunately, this is not just a big bank issue – smaller banks can sometimes be worse at delegating responsibility. For small banks, every change feels like a big deal. So the management, most of whom have risen through the ranks of Product Management or Marketing, seems to justify its existence by reviewing every change in minutest detail. Just think about the impact this has on the moral of the people, who often feel powerless. The phrase I hear most often in such places is “Doesn’t matter what we put in the proposal – X is going to change that anyway”. Sounds familiar?
Anyway, what Agile working means for the senior management is topic for a future post but suffice to say that Agile needs the management to set the course and then get out of the driving seat.
Mastery – Think about the last time you were using a product or service and had a wow moment. It could be something that completely blew you away, though that doesn’t happen very often. More likely though, it was probably something that made you think “Huh, this is kinda cool”. For me it happened on a recent trip to Germany. I was staying at a hotel and like at most hotels I got a key card that opens your room door and is also used to operate the lift/elevator. So I got into the lift and tapped the card on the reader. I was expecting that I would then have to press the floor number. To my surprise though, the lift automatically selected the floor where my room was. That was kinda cool, right?
Now take a step back. What this hotel did was not technically hard to do. However, most hotels don’t take that extra step. The same applies to most banks. Because we want to do so many things, we never go beyond the bare minimum needed. Is there any wonder then that most of our banking transaction screens look something like this?
Now if your purpose was not to build a transaction screen but to improve people’s understanding of their spending, do you think you can do a better job at how information is presented on this screen? I bet you could. I call this process Innovation through Iteration. Yes, you start with the basics but you keep iterating until you are satisfied with the end result. At the same time, every small iteration makes it to production so you constantly receive feedback that makes the next iteration even better. In the process, you become an expert on the topic and when you think you have achieved your purpose, you move on to the next one.
Breaking the Silos or the Troika model- Of course you can’t do it all alone – so a mature Agile process also gets rid of the silos between Business, IT and UX. You work together as a team, you build mastery together and you all contribute to solving the same problem. And you question the hell out of each other! You all need a common understanding of both what the problem is and why are we solving it. The actors could of course differ for different tasks but three is pretty much the magic number – beyond that it causes skill overlap and adds too much coordination effort to bring everyone to a common ground. Goes without saying that the three need to have the autonomy and authority to make decisions without seeking multiple approvals.
Let me give a real life example why this model is important – We were building a new Customer Journey and the UX designs, which let me tell you were absolutely fantastic (Thanks Mr Trump), had buttons with rounded edges and shadows. We found that the simple rounding of edges and shadows would mean having to build the button from scratch and that would have taken us two months to build. In the Psuedo-Agile process IT would just build the buttons without questioning. However, in our case the developers came to the UX guy and showed him a button that we could get out of the box from an Open Source library. Yes, it didn’t have round edges but still looked very nice and was highly configurable – and most importantly of all IT understood that using the button wasn’t compromising on what the team was trying to accomplish. The result was that we ended up using that button and it meant that we could spend that development effort on solving a problem that was more important for the customer.
This also addresses a criticism I sometimes hear from the Finance department on working Agile. Overall resource is fixed so surely iterating means you can’t do as much.
Yes, you are right, we can’t do as much and this isn’t cost efficient in the traditional sense – you do spend longer on one problem rather than continuously changing focus. That’s why I said in my last post that Agile may not be best suited to a utility model where you want to take as much cost out of the system as possible. Having said that, the expertise and working together in cross functional teams does make you significantly more efficient at solving problems. The small iterations and constant feedback loop also means that you don’t end up with massive investments in bad ideas. So yes, on paper it looks inefficient, but in reality it actually ends up being much slicker. However, it does need a leap of faith that we will end there.
Anyway, this is enough for now. In the next post we will explore what Agile means for management in a bit more detail and how we are implementing Agile at ING.
53p1c6