To be truly agile, solve for the least common denominator

Why tell someone to work ‘agile’ without giving them a great understanding of what that means? (Tom Whitbrook, Senior Strategist, The App Business).

Like our good friend Tom, my fellow Envizagers and I have been exchanging eye roll emojis over Slack every time we’ve come across a misplaced call for teams to be ‘more agile’.       

‘Agile’ is simply an approach to work favoured by many beer-enjoying, table tennis-playing, JIRA-loving dev teams, much like PRINCE is a way of working favoured by suited public sector project managers who happen to prefer logging their progress on Microsoft Project. What makes the Microsoft Word app, for instance, ‘not agile’ is it’s static nature – everyone has different versions and edits on their own computers, as opposed to making real-time updates about work with a tool like Google Docs. 

The agile methodology and the everyday definition of the word (flexible, innovative and so on) are now used interchangeably, which can cause confusion and give the impression that ‘working agile’ is some cool, trendy new thing and is somehow more superior than other ways of working. 

I have met a number of senior executives who like to talk about how ‘agile’ they are because their companies are ‘innovative’ and have labs or sandbox-type opportunities in which their staff members are encouraged to experiment. This type of rhetoric is now also common within management presentations and finance meetings, as though C-Suite bosses will be automatically impressed by a liberal sprinkling of the ‘A’ word and conclude that the person giving the presentation has their hands sufficiently ‘on the pulse’. 

Most don’t realise that agile, in practice, is about identifying the least-common denominator and here’s why – if your procurement function isn’t truly agile, no amount spent on labs, fancy workspaces and branded hoodies will make a difference to your ability to move at pace in a rapidly-changing world. 

Quite a few attributes (more about which in future pieces) that have historically made traditional financial services firms resilient and primed for external partnerships can be a liability in this brave new digital, AI-powered new world. 

For example, if your target test audience for a pilot is a group of internal colleagues, how many resources do you really need to allocate to preparing contracts and mitigating for risk? 

Similarly, if you point a procurement process that was created with Microsoft and Accenture in mind at a 20-person start-up, are you doing either yourself or the start-up a service? This altogether-too-common scenario reminds me of the old joke about trying to set a pig’s tail straight – you probably won’t succeed, but you probably *will* annoy the pig.

When smaller, tightly-focused fintechs find success, there is usually a pattern that goes something like this – they meet a senior business sponsor who truly understands how to ‘work agile’ and is empowered to flex the pertinent variables in their organisation. This sponsor allows them to collaborate with institutional firms that have the means (although sometimes, not the will) to be first to market with innovative tech, by minimising procurement red tape, in order to deliver a desired result for their business at a faster rate than some of their predecessors. 

Making good and exciting things happen with little to no bureaucracy, using whichever tools (external and internal) allow you to get the job done quickly and with due quality and attention, to me, is how large firms can be truly agile. 

Request a demo of the Envizage API by contacting the Envizage team.

No Comments

Sorry, the comment form is closed at this time.