Agile finance: beyond buzzwords

The responses span the full spectrum from ‘flexible’, ‘adaptive’, and ‘collaborative’ to ‘chaotic’, ‘buzzword’, and ‘just for IT’. Some see agile as a proactive, forward-looking way of working; others associate it with reactive firefighting. Many are simply unsure what it means for them at all. 

This diversity of opinion is not a problem, but a signal. It tells us that agile has not yet found a clear, shared meaning in the finance world. And that is precisely why we need to go back to first principles: what did agile actually set out to be, and how can we translate that meaningfully into a finance context? 

Adapting agile principles to finance 

It is clear that there is no consensus in finance on what agile means, so let us start by reviewing the original values and principles that underpin agile. Then we can see if this translates into something relevant for modern finance teams. 

Original Agile Manifesto 

In 2001, seventeen software practitioners gathered in Snowbird, Utah, and produced what became known as the Agile Manifesto. In just a few hundred words, they outlined four core values and twelve principles that would fundamentally reshape how software was built and, over time, how organisations of all kinds approached complex work. 

The four values of the Agile Manifesto state:

In addition, the Agile Manifesto provides twelve guiding principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 
4. Business people and developers must work together daily throughout the project. 
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
7. Working software is the primary measure of progress. 
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 
9. Continuous attention to technical excellence and good design enhances agility. 
10. Simplicity – the art of maximising the amount of work not done – is essential. 
11. The best architectures, requirements, and designs emerge from self-organising teams. 
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. 

Source: Agile Alliance. agilealliance.org (2001) 

More than two decades after they were written, these values and principles remain remarkably relevant, not just in software, but across any function that deals with complexity, change, and human collaboration. Finance is no exception. The question is simply how to translate them. 

Finance Agile Manifesto 

While the original manifesto speaks the language of software (developers, working code, technical excellence), its underlying logic translates powerfully into the world of finance. The core insight is the same: in complex, fast-changing environments, rigid processes and a drive for perfection can become the enemy of progress. 

Based on extensive work with finance and IT professionals, we have developed an adapted Finance Agile Manifesto. It reframes the original values and principles in terms that resonate with finance leaders and their teams. 

The language has been adjusted; the spirit remains intact.

The twelve agile finance principles: 

1. Deliver timely insights to support better decisions – early, often, and with value in mind. 
2. Be open to updated business priorities or assumptions – adjust plans, forecasts, and reports accordingly. 
3. Share work early and often. A rough answer today is more valuable than a polished one next month. 
4. Foster ongoing dialogue between finance and the business. Create partnerships, do not just report. 
5. Take ownership of outcomes, not just output. Understand and drive the business impact of your work. 
6. Talk to people – do not just email spreadsheets. Clarity improves with conversations. 
7. Business impact is the key success metric – not slide decks, perfect formatting, or the number of reports. 
8. Design for a consistent pace and predictable rhythms – consistency beats intensity. 
9. Maintain clean models, reliable data, and scalable tools. Good infrastructure equals faster and better support. 
10. Focus on what truly matters – cut redundant reports, avoid over-analysis, and automate where possible. 
11. If a workflow is broken or a process is slowing the team down, raise it, own it, and work with colleagues to fix it. 
12. Run retrospectives – review what worked, what didn't, and how to improve recurring tasks or processes.

To test whether these values resonated with the finance community, we put them directly to professionals working in finance functions at a large global organisation. 

The response was clear: the vast majority found the values highly relevant to their work. Many relevant applications where highlighted, including the ones below.

But relevance alone is not enough. We also asked how consistently these values were being applied in day-to-day practice. The answer was sobering. On average, respondents felt they embodied them only around 60% of the time, meaning that for four out of ten working days, the values were not really being applied. The gap between belief and behaviour is significant.

So, if agile is this relevant, what is stopping finance teams from adopting the values to a larger extent? When asked to rank seven potential barriers to more agile ways of working, the answer was unambiguous. Resistance to change ranked as the single biggest blocker, placed first by roughly 40% of respondents and appearing in the top three for two-thirds of them. No other factor came close. Behind it sit two constraints that participants tied directly to leadership behaviour: rigid timelines and a lack of leadership buy-in. 

Together, these top three describe a cultural and governance problem, not a technical one. Agile adoption in finance is held back less by what teams are capable of than by the space they are given to work differently. 

The implication is clear: an agile shift in finance will not be unlocked primarily by new tools or training. Instead, leadership must visibly create space for iterative work, loosen fixed timelines where the work allows, and model the change behaviours they want to see. The tools that follow are only effective in such an environment. 

From values to practice: agile tools for finance 

Values and principles set the direction, but they do not tell you what to do on a Monday morning. Even the most committed finance leader cannot 'be more agile' without some concrete practices to anchor the shift. To operationalise agile thinking in day-to-day finance work, we need to get practical. 

It is worth acknowledging upfront that very few organisations today apply any single agile framework in its pure form. The era of strict scrum-by-the-book or SAFe-as-written is giving way to something more pragmatic. Research confirms this decisively: a cross-industry study of 477 projects published in the Project Management Journal found that 52% could be categorised as hybrid approaches – making hybrid the single most common project management method in use today.¹ 

Crucially, the same study found that hybrid approaches are just as effective as pure agile, delivering equivalent outcomes on budget, time, scope, and quality, while outperforming traditional approaches on stakeholder success. In other words, you do not need to choose between rigour and agility. Instead of 'going full agile', finance professionals can selectively adopt the tools and practices that make most sense for their specific context. 

Three tools in particular stand out for their immediate applicability in finance:

1. Sprint-based work
2. Kanban boards
3. Minimum viable product (MVP) thinking

None of them require a wholesale transformation. All of them can be started this week. 

Sprint-based work 

Think about how most finance improvement projects are structured. A team of people is allocated 10–20% of their time over a twelve-month period. In practice, this means that on any given day, the project competes with month-end close, ad hoc requests from the business, and a dozen other priorities. Progress is slow. Momentum is lost. By the time the project delivers, circumstances have changed. 

Sprint-based work flips this model. Rather than spreading resources thinly across a long horizon, a sprint dedicates adequate, focused resources to a defined and meaningful chunk of work over a short, fixed period – typically two to four weeks. The sprint is protected: no scope creep, no interruptions, just focused delivery towards a clear goal.

The shift is conceptually simple but culturally significant: we are moving from long and thin projects to short and fat ones. More resources, more focus, shorter timeframe, and a real deliverable at the end of each sprint that can be reviewed, built upon, or course-corrected before the next one begins. 

Our work with the finance community revealed multiple good use cases for a sprint-based approach: 

• Process improvement: A finance team dedicates a monthly sprint to optimising a specific workflow. One reconciliation process, one reporting template, one control procedure. Over twelve months, twelve focused sprints compound into a materially improved finance function, with real progress visible at the end of each cycle rather than a big reveal at year-end. 
• Closing excellence: A finance team sets a two-week sprint with a single, focused goal: eliminate the bottlenecks that delay close every month. Backlog includes building a task-by-owner close board, standardising and automating the top three recurring journals, completing a pre-close checklist, and defining what ‘done’ looks like for each reconciliation. The deliverable at the end of the sprint is a repeatable close runbook, updated templates, and a visible close plan ready to run next month. 
• Cost centre clean-up: A finance team defines a series of one-week sprints targeting one specific outcome: make cost centre reporting usable for decision-making by removing noise and fixing mapping errors before the budget cycle begins. The backlog includes identifying the top twenty mispostings, correcting mappings and master data, agreeing a simple coding guide with AP and procurement. The deliverable is a cleaned cost centre structure, an updated mapping file, and a live exception report the team can run themselves going forward.

Kanban boards – workflow visualisation 

Every finance team has a backlog. The problem is that most of the time, that backlog is invisible, spread across individual email inboxes, shared spreadsheets, verbal commitments, and sticky notes. When everything is invisible, everything feels equally urgent. The loudest voice wins. The team ends up firefighting rather than prioritising.

A Kanban board solves this with radical simplicity: make the work visible. By mapping all work items, whether on a physical wall in the office or in a digital tool (or platform), a team can see at a glance what is waiting, what is in progress, and what is done. More importantly, it creates a shared surface for prioritisation. Not everything can be in progress at once. Work must be chosen, sequenced, and completed before the next item begins. 

Kanban boards truly come alive when paired with a consistent meeting rhythm, commonly known in agile circles as the daily stand-up. This brief, focused session, typically lasting just 10–15 minutes and ideally held in front of the Kanban board, helps the team align and maintain momentum. Whether a finance team chooses to hold these meetings daily, weekly, or on another regular schedule is less important than the commitment to open discussion and collaborative prioritisation using a shared visual workflow. The key is having ongoing dialogue and making decisions together based on what is visible on the board. 

The discipline this introduces is transformative for finance teams. Rather than reacting to whoever shouts the loudest, the team collectively decides what gets worked on, and in what order. Visibility creates accountability. Prioritisation creates focus. 

Our work with the finance community shows that Kanban is not an abstract ‘agile concept’, but a highly practical tool for day-to-day finance work. 

Here’s a few examples: 

• Managing the finance backlog: A finance team uses a Kanban board to consolidate all incoming requests (management questions, ad‑hoc analyses, control fixes, system issues) into one visible backlog. Items are explicitly prioritised during a weekly review, with clear entry criteria for ‘in progress’. The result is fewer interruptions, clearer trade‑offs, and a shared understanding of what the team is not working on yet. 
• Supporting business partnering without overload: A business‑facing finance team visualises all ad‑hoc requests from commercial and operational leaders on a shared Kanban board. Requests are triaged weekly against capacity and strategic relevance. Some move forward immediately; others are deferred or declined transparently. Business partners gain predictability and trust, while finance avoids being stretched thin by well‑intended but low‑value work. 
• Finance project portfolio management: A finance team runs multiple initiatives in parallel: system upgrades, regulatory changes, process improvements. To keep track they use a portfolio‑level Kanban board with each initiative visible with clear ownership, status, and current constraints. Leadership can see where progress is flowing, where work is stuck, and where support is needed, without requesting separate status updates. The conversation shifts from “Are we on track?” to “What is limiting progress, and what do we stop or finish next?”

In practice, Kanban does not slow finance down. It does the opposite. By making work visible and limiting what is in progress, finance teams regain control over their time, attention, and priorities – shifting from constant reaction to deliberate execution. 

Minimum viable product (MVP) thinking 

Finance tends to have a perfectionism problem. Because it is built on accuracy, auditability, and control, getting things right matters in the finance function. That said, the instinct for precision has a shadow side: reports that are delayed because one number still needs checking, models that sit in review for weeks, analysis that never gets shared because it is not yet 'complete enough'. In a fast-moving business environment, the pursuit of perfection can become a liability.

MVP thinking offers a powerful counterbalance without abandoning rigour. The idea, drawn from the world of product development, is straightforward: deliver the smallest workable version of a solution, get genuine feedback from your stakeholders, and then iterate. Build on what you learn. Improve progressively. 

The key insight is that you do not need to build the Lamborghini on day one. Start with something that simply gets your stakeholders from A to B – a skateboard, if you will. Then improve it based on real use: a bicycle, then a car, and only then, if needed, the full solution. 

The crucial twist finance professionals consistently discover when applying MVP thinking is this: very often, the stakeholders never needed the car at all. The bicycle was sufficient. The fully specified solution – the one that took months to design and years to implement – ended up solving a problem that had already evolved, or addressing a level of complexity the stakeholder never truly had. 

Our work with finance teams shows that MVP thinking is particularly powerful when applied to problems that are traditionally over‑specified and slow to deliver: 

• Management reporting redesign: Instead of launching a full reporting overhaul, a finance team starts with a single MVP: one page answering one executive question using existing data. The report is tested in a live management meeting, feedback is captured, and only then is it refined or expanded. In many cases, the MVP replaces entire legacy packs, revealing that much of the previous reporting effort was adding volume rather than insight. 
• Forecasting and scenario analysis: A finance team resists building a fully-fledged forecasting model upfront. Instead, it develops a lightweight driver‑based MVP covering the five variables that explain most performance volatility. The model is used immediately to support decisions and only enhanced if additional precision proves necessary. The result is faster decision support and less time spent perfecting assumptions that rarely change outcomes. 
• Policy, controls, and governance changes: When introducing new policies or controls, a finance team pilots the minimum version in one business unit or process – testing clarity, usability, and unintended consequences before scaling. Feedback from real use informs simplification and adjustment. Many controls never need to become enterprise‑wide standards, avoiding unnecessary complexity while still addressing the underlying risk.

Across these cases, MVP thinking shifts finance from designing the perfect solution to learning what actually works. It replaces certainty‑seeking with evidence, and large one‑off implementations with a sequence of small, deliberate bets, each grounded in real stakeholder behaviour rather than assumptions. 

The rise of AI has further enhanced the effectiveness of the MVP approach. With generative AI tools readily available, finance teams can experiment rapidly with new concepts, develop functional prototypes, and iterate swiftly in response to stakeholder feedback.