When, in 2001, the Manifesto for Agile Software development was first published, it was generally ignored by the financial services community. Now, 18 years on, it is generally embraced and adopted. Or is it, really?
Even the briefest online research will yield multiple case studies of success; ING, Barclays, Standard Bank, Bank of America, DBS Bank of Singapore all feature on the first page of search results.
For those organisations who feel left behind, there are plenty of simple formulas and methodologies available on the same page. What could be easier than following the ‘5 Steps to Success’? You just need to download the free guide.
Allow me to dissent. I have been consulting in financial services operations and technology for as long as we have had the Agile Manifesto, and I still see a lot of elephants, and none of them dancing.
Ah but, I hear the challenge, what about my exemplary team? Yes, and that is the heart of my concern. I know there are some great teams, even in banks, satisfying their customers by the early and continuous delivery of valuable software. And I believe that they remain the exception and not the rule.
At one of my clients last week (who shall have to remain nameless), I was interested to hear a project team present their agile plan, as follows.
- Sprint 1 – engage stakeholders
- Sprint 2 – discover requirements
- Sprint 3 – develop the solution architecture
- Sprint 4 – build a Proof of Concept; and so on.
You get the picture. Old waterfall wine in new Scrum and Sprint bottles. And this is at a bank who are proudly claiming to have achieved successful Agile transformation.
Generalising, I believe that, despite significant investments in methodology, coaches and CICD tooling, the underlying behaviours too often remain unchanged. This is not to find any fault with talented and motivated developers, but rather a reflection of the culture and constraints in which they operate.
Individuals and interactions, working software, customer collaboration, responding to change are core values driving Agile. In terms of behaviours this means for example ‘business people and developers working together daily throughout the project’ (to quote from the Agile Principles). Changing behavioural norms to this degree requires a breakthrough transformation in the change culture of the organisation.
Agile transformation does not succeed when approached as a wholesale change in development practices, or as a radical restructuring how Technology is organised. In fact, in Davies, we would challenge whether this programmatic ‘Transformation’ model might itself be part of the problem.
The transformation that is needed, we believe, is one of modifying culture, mindset, capability and behaviour, engaging all of the parties involved in delivering change. For these reasons, our focus for Agile Transformation is to apply breakthrough thinking to drive behavioural change, starting with the most senior levels of leadership and extending across all the governance and stakeholding functions.
In practical terms, this involves building commitment and collaboration at the senior leadership level to:
- Convert ‘agile transformation’ aspirations to concrete outcomes and commitments
- Define the conditions of satisfaction that will sustain and evidence achievement
- Build the networks of relationship needed to achieve new levels of collaboration
- Create new openings and possibilities for ‘changing the way we change’
- Prioritise the opportunities for change
- Drive the action and track impacts
- Declare and overcome the obstacles and ‘breakdowns’ that will be experienced
- Evidence and recognise success.
This is not a simple eight-step plan. It is built on the understanding that culture change is complex, not merely complicated; that behaviour change is emergent, not predictable; that the challenges are adaptive, not technical. What it does is to start in the right place.
If the output is culture change, then you need input at the level necessary to succeed.
