David Blair has had the privilege and pleasure of working on an Agile software development project this year. He says there were many similarities between this and his time working in small treasury teams. Here are some of his further observations on how Agile relates to treasury.

To me, Agile seems to be primarily a mind-set. This is characterised in the four key values outlined in in the Agile Manifesto – a document drawn up based on the combined experience of several software developers. According to the Manifesto, Agile is built on:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

But there are also several common themes across the many styles of Agile, including:

• Small (single digit) tight-knit cross-functional teams.
• Efficient communication (eg daily stand ups).
• Short (typically two week) sprints delivering working functionality.
• Bite-sized chunks of work for quick delivery.
• Try – sometimes fail – learn.

This way of working was born from the frustration of coders with the big project engineering-based approach that was previously the default called “waterfall”. This sequential approach to building software can be slow and rigid and can sometimes lead to an unsatisfactory outcome for both software provider and client.

Agile business

As noted, Agile started as a software development methodology, but it is now being adopted by all kinds of businesses and is even becoming a management fad. A quick scan of the web will show that marketing, customer service, and even audit (which sounds odd but why not?) can be Agile.

In spirit, the desire to be nimble is not new. Policies and processes help ensure consistency but often at the cost of corporate sclerosis.

Some banks are embracing this way of working across the entire organisation. Commonwealth Bank of Australia, for instance, recently announced that it will be 100% Agile within a year. Dutch lender ING is also undergoing its own Agile transformation. Yet while the desire to be more nimble and customer friendly is laudable, it is not clear how this will work beyond project teams. “Agile compliance” sounds like an oxymoron!

Agile treasury

For me, one of the joys of treasury has always been working in small tight-knit teams. Of course, there is a downside in terms of being under-resourced and over-worked, but small teams are inherently nimble (because they have no choice) and (I think) more fun.

Another aspect of treasury I enjoy is making things happen and delivering results. Since I am not a very patient person, I like to see quick results. In fact, I need quick results to keep me motivated, otherwise I lose interest. So Agile is an easy sell to me – small teams delivering a regular flow of concrete results, and responding fast to changing circumstances.

In fact, as I learned more about Agile, I came to see that I have been doing (unstructured) Agile for decades – largely by force of circumstance and functional necessity. Based on my observations of treasuries I have worked in and with, small teams and fast changing requirements are quite typical in all but the very largest companies, so I think other treasurers will find Agile reasonably comfortable.

Learning from Agile

Even if treasury is great and arguably intrinsically agile, I found there is a lot to learn from Agile. This way of working was an early product of this century, and has blossomed in the past 17 years, producing countless branches, and generating a wealth of experience and knowledge – not to mention a whole new industry of Agile coaching.

Some of the Agile practices that impressed me include:

• Small teams.
• Sprints and bite-size tasks.
• Velocity.
• Rituals – stand ups and retrospectives.

Small teams

Agile requires nimbleness and dense communication, so it works best with small teams. It is none the less scalable by combining small teams (called squads or scrums) into larger units.

Spotify built a corporate structure out of Agile teams by combining them into tribes (related squads), chapters (cross squad groups by skill set), and guilds (cross squad special interest groups). Matrix organisation re-worked for Agile – with accountability firmly anchored at the squad level.

Sprints

Agile is characterised by short sprints – usually one or two weeks – with concrete and defined deliverables. Sprints are key to Agile’s adaptability; if the work does not satisfy for whatever reason only two weeks have been lost, and the squad can change tack appropriately.

Sprints require that work is broken down into small chunks that can be done quickly with few people. This is a great way to manage progress and reduce risk.

Velocity

Velocity is a key metric in Agile. Velocity is the amount of work a squad can deliver sustainably within a sprint. It is critical to sprint planning – keeping the team fully loaded but not overloaded. Overloading results in poor quality and eventually diminishing returns as motivation flags.

Obviously, treasury has to respond to externalities that are often beyond its control, even if some (like quarter ends) are predictable. Nonetheless, the concept of velocity is a useful management discipline to rigorously understand the capacity of the team.

Rituals

My favourite Agile ritual is the stand-up – a daily ten-minute team meeting which is traditionally done standing up to prevent people from getting too comfortable and to encourage brevity. A stand up is a concise progress report – squad members basically share any blockers (things that might stop them delivering within the sprint) and possibly ask for help. Stand ups are strictly process oriented. Any deeper discussion is scheduled for later and normally in a smaller subgroup.

Of course, for a few treasurers in a small dealing room, stand ups may seem redundant. It is OK to be agile about Agile but I do think that sharing progress across the team is a great discipline. And I have always found that focussed communication leads to better and quicker outcomes.

Another Agile ritual that impressed me was the retrospective. A retrospective is a squad discussion at the end of each sprint about how things went and what can be improved. The team typically looks at things to stop, start and continue doing. Retrospectives act as a good prelude to sprint planning which is when the team decides what to do in the upcoming sprint.

Integrating Agile

I enjoy working in the Agile methodology. As noted above, it is perhaps more than anything a mind-set. It has a lot of discipline and great risk management, but Agile discipline and risk management can appear chaotic to colleagues and partners. Integrating an Agile squad into a non-Agile organisation and with non-Agile partners can be hard.

The Agile approach is very nimble which means it is fluid. Not all partners like this. For example, an external vendor may find the fluidity feels like delivery risk to them. It also requires trust, and trust requires understanding, and this is not always easy to achieve. With external partners, the squad also must accept that the work may not be specified in the traditional detail, and therefore the cost will be variable. This tends to go down badly with procurement colleagues. These kinds of challenges ripple out from Agile teams embedded in non-Agile organisations.

Conclusion

It will be clear from the above that I am a fan of Agile. I have really enjoyed working in an Agile team – helped no doubt by the quality of my squad mates. While small treasury teams tend to be nimble by necessity, some of the practices the Agile community have developed over the past 17 years can help anchor treasury agility and make it more robust.

For example, rituals like stand ups may seem unnecessary to treasurers who feel they are spontaneously agile. None the less, stand ups can systematise communication that mostly occurs naturally, and the structure makes the team more accessible for newcomers. I am suspicious of rituals becoming rote process, but properly done stand ups are designed to avoid that – if all is going swimmingly, a stand up only takes five seconds per person – enough time to say “OK”.