Why financial enterprises need to take a more Agile approach [Q&A]

Adopting a more agile approach to development has allowed many businesses to speed up the introduction of new products and services.

But banking and financial organizations have tended to be more conservative in their approach and have consequently come under pressure from faster moving fintech competitors.

We spoke to Cliff Berg, founder of Agile 2, who believes that a new, more modern approach is critical for banking and fintech organizations to boost productivity and success, improving their work environments and customer experience at the same time, while also addressing technical risk management in a new way.

BN: Have more established financial organizations been slow to adopt an Agile approach?

CB: For older businesses the goal is often not to be agile as a startup, but rather to improve incrementally over where they were. And to me, that is an Agile approach, and it aligns well with the inherently and justifiably conservative nature of financial services companies.

Very recently I did DevOps consulting for a very large fintech company -- one that claims to be very agile and a big user of DevOps methods. I found that some divisions within the company were quite advanced in their methods, but others had what I call 'team-level Agile', in which they have Scrum teams, but everything beyond the team works like waterfall. That's significant given that digital products in that firm generally have around 30 teams each. For those products, their feature lead time -- the time to get a new feature out to users -- was stuck at about 100 days.

BN: How has the Agile methodology been affected by the recent shift in working patterns?

CB: First of all, Agile is not a methodology. Agile is like a quilt: it is a collection of odds and ends that include various methodologies -- Agilists like to call them frameworks -- as well as the 'Agile Manifesto'. Agile, encompasses a broad array of various methods that have become popular among the Agile community. An Agilist can tell immediately if something is Agile or not. That’s because it has become a culture or an art genre: just like you can look at a painting and know at a glance if it is cubist or not, or listen to music and say if it is jazz or not, you can hear about an IT practice and tell if it’s Agile or not.

The COVID-19 pandemic created a titanic shift in IT in a number of ways. One was that it became unequivocally clear that remote, distributed IT teams work just fine -- often better than in-person teams. But in that revelation, a core pillar of Agile as it is often explained by its most ardent advocates, was proven to be false. That pillar is that in-person teams, colocated physically, are the most effective.

The core ideas of Agile were not wrong. The reason that many Agilists have insisted on everyone being jammed around a single table in a so-called 'Agile team room' is that the 1990s approach of putting people into cubicle farms was pretty toxic. Agile was largely a reaction to things that did not work.

But the Agile team room is as much of an extreme as that, and just as toxic. Some people flourish in a team room. Those are the talkers. But the quiet thinkers don't usually like team rooms: they can’t focus. They can't think deeply. The Agile team room has destroyed work for introverts and quiet people.

COVID pushed everyone home, into their own space, and thus empowered the quiet thinkers. Those people are now just as visible in a Zoom call as anyone else. Plus remote work empowers writers: people who like to write their ideas down and share that, rather than compete for airtime in a face-to-face meeting.

This doesn't mean that Agile is dead but it's proved beyond any doubt something that many have been saying for a long time: that there are core ideas of Agile that are powerful and important, but some of those ideas are not quite right or have been taken to an extreme, and so we need to revisit Agile ideas and ask ourselves honestly, is that idea too extreme? We need a more mature, more balanced and more inclusive Agile.

BN: What particular benefits can Agile 2 bring to the banking and finance sector?

CB: For one thing, Agile 2 explicitly acknowledges the role of leadership and management. The Agile community is really quite anarchist, and even antagonistic with regard to management or any form of explicit authority. But in finance, which is regulated, there need to be accountable individuals, and authority is extremely important. Agile 2 embraces modern ideas about leadership, rather than dismissing it altogether.

Agile 2 encourages defining the leadership models that you want to propagate in your organization. It advocates thinking in terms of different circumstances and the different kinds and directions of leadership that might be needed. And it looks at leadership not in terms of only hierarchy, but also in terms of the many dimensions that today’s complex organizations must manage.

Agile 2 also talks about accountability, and the need to take responsibility for the quality and security of what we deliver to our customers: it explicitly mentions that 'those offering products and services should feel accountable to their customers for the impact of defects'.

Then there's data. Somehow data got left out of Agile. A friend of mine who is a machine learning expert was hired at a Fortune 10 firm to build models, and he tells me that he is hamstrung because the data in their data lake, data being pumped in by myriad services, is entirely uncorrelatable. They have all this data yet they cannot leverage it as an asset. Yet Agile says nothing about data, and so their teams feel that they are doing what they are supposed to do.

Agile also likes to treat everyone as the same -- it is innately egalitarian -- but not everyone is the same. A mature Agile needs to recognize that. Machine learning teams that build custom models consist of mathematicians. They can program but they're not programmers. Those people work differently than Scrum teams. Agilists often don't know how to interface with such teams of experts, but Agile 2 embraces the many different kinds of groups that complex organizations have.

BN: What's the key to creating an updated Agile approach?

CB: There are two key lessons. One is that senior leaders should not assume that Agile is 'an IT thing', or 'a team thing'; and they should not assume that they understand it unless they truly do, because if you issue overly simplistic dictums to 'make things Agile', you can do a lot of damage.

Shifting to the use of Agile methods is not a process change. Agile is a philosophy, a way of working, and it doesn't work unless the environment surrounding the teams is Agile. Merely making the teams use an Agile framework like Scrum won’t do it -- it will cause chaos and conflict for a long time.

The other lesson is to always start with your business goals. Why Agile? What are you trying to improve? If you are trying to reduce IT cost, don’t look to Agile: it is not a direct cost reduction tool. But look to Agile methods if you want to make things work better, so that delivery is more reliable, and products are more successful. Start with your goals, and work backward from that; and use a team of highly experienced Agilists as a source of ideas for how to accomplish them.

Agile 2 is a mature Agile. It is what those who do Agile well are already doing. It's not some new theory, rather a collection of ideas that actually work, at scale.

BN: What opportunities will Agile open up in the next few years?

CB: Business is becoming more complex, more multidimensional, and more fast-paced. Business has largely moved to technology platforms, and that trend will continue. That means that the platform is the business: you can’t separate it anymore.

The real product is no longer what the customer uses: it is the system that produces what the customer uses. The reason is that the end product is now changing all the time. Tesla doesn’t wait for a new model year to introduce changes to their vehicles: when you buy a Tesla, you get the latest version. The car is always improving. Tesla's factories are their real product; their design and engineering teams are part of that, the system that continuously improves what the customer uses, and pushes those new versions out to the market. This is what makes them strategically competitive.

In other words, the way that the product is made is now just as important -- sometimes more important -- than what the customer is using, because if you can get rapid feedback on what the customer likes about it, and if your system for producing the customer product is agile, then you can rapidly adjust the product.

Organizations need to be agile so that they can compete, and that trend will continue to grow more acute. And it's not just for software, today, most manufactured hardware products are defined via digital artifacts. These enable the use of Agile methods, including DevOps. The ability to 3D print, for example, means that you can validate design changes rapidly, and then use those same files to generate manufacturing instructions for more traditional and scalable methods simply by clicking a mouse.

Short time to market is the big win that Agile gives you -- but only if you do it well.

Photo Credit: Karashaev/Shutterstock