Agile for Finance

Agility is defined as one’s capability to think, move and respond to change easily and quickly. Business agility is the ability of a business to adapt and respond to changing conditions quickly and easily. The concept agility has been around in the IT and technology industry for at least 20 years. In the past few years, the concept of agility has been gaining more popularity in other business divisions.

In particular, many organisations are focusing their efforts in increasing the agility of their finance teams.  Various reports published by Gartner, Oracle and Accenture indicate the importance of finance team agility in organisations.

This whitepaper introduces the new Agile Finance framework by Sprint Agile. This framework serves as an operating model for finance teams to function in a more agile fashion and also to enable business agility across other business units and divisions of the organisation.

Agile finance teams not only have the capability to respond to change with agility, but also enable business agility by supporting other business functions to respond to change with agility

There are a different set of competencies that are required to be agile internally versus to supporting agility in business units external to the finance teams. First we will cover the competencies and processes that enable agility internally then we will look at how finance teams can enable agility across the organisation.

How can finance teams be agile?

There are certain attributes that are common among teams that can adapt and respond to change with agility. These attributes are:

• Have the capability to deliver end to end
• Collaborate on daily basis
• Prioritise and manage workflow
• Experiment empirically
• Dedicate time for continues improvement

To support these team attributes and increase agility, finance teams need to implement certain agile practices and processes. The top four agile practices that are essential for finance teams are:

• Be cross functional: cross-functionality will ensure the agile team has the capability to deliver end to end. This means they do not need to send requests to external teams and wait for responses. There are no handoffs and no queues between teams. The team can collaborate on daily basis to do everything that needs to be done to deliver value without having to wait for approvals and handoffs.
• Use Kanban Boards: Agile teams need to utilise Kanban boards to visualise the flow of work. This will create transparency on who is working on what and in what stage of the workflow the tasks are. A Kanban helps identify impediments and tasks that take longer. It will also enable the team to prioritise to ensure the focus on the most important task when facing with competing priorities.
• Run Daily stand-up meetings: A daily stand-up meeting is a short and sharp meeting where people discuss what they worked on yesterday, what they work on today, and if they have any impediments. This is an opportunity to ask or offer help to your team mates. Daily stand-up meetings create transparency, accountability, and promote collaboration. However, we must ensure these meetings don’t become a micromanagement venue. The team needs to work out what they need to do autonomously and collaboratively.
• Retrospective meeting: The retrospective is a protected focus time, when the team can stop working, take a step back, and come up with creative continuous improvement ideas. This is to ensure we don’t get bogged down with doing tasks all the time. We need to ensure that we come up with improvements to our ways of working on regular basis and keep experimenting to get better. We recommend agile finance teams spend 2-3 hours in a retrospective workshop every two weeks.  The retrospective meeting starts by looking at the past week; what went well, what went bad, and how we can improve. Then the second half of the retrospective meeting needs to focus on creative and free ideation. The facilitator can use design thinking techniques to ensure the team comes up with creative experiments to improve their ways of working.

Agile teams operate on an evolutionary and empirical cycle of plan, do, check, and adjust. This means, on regular cadence the team gets together and plan what they will be doing, then they deliver on the plan, then they observe and collect data, and finally reflect and adjust their plan for the next period. This period can be anything from 1 week to 3 months. Once a team decides their cadence they need to stick to that cadence.

How can finance teams enable agility in other business units?

Traditionally finance teams have been usually hindering business agility in organisations. The accounting and finance practices that have been working well in the past hundreds of years have been developed for mostly stable environments. In the past few hundred years going back to the middle ages finance teams have been funding projects that did not require high levels of agility. It is only in the late 20^th and 21^st centaury that we are seeing a desperate need for business agility.

This list indicates the main reasons that traditional finance teams have been hindering business agility:

• Project funding based on fixed cost and scope
• Yearly budgeting is not frequent enough to respond to change
• Traditional budgeting based on last year’s spending
• Lack of transparency
• Decisions are made mostly based on cost not value

In the past few years finance teams across the globe have been experimenting with changes to their operating model to address the above points. There are 5 practices that have been shown to increase business agility across the organisation.

Fund capacity instead of projects

In traditional project management, we start by defining the scope of the project and then deriving time and cost from that scope specification. This means that scope, cost, and time are interrelated, and changing one will result in changing the others. Once budgets are approved it will be difficult to respond with agility if we want to deliver those projects on scope, on time, and on budget.

To enable business agility, we need to shift away from project mindset to product or value stream mindset. This is also called inverting the so-called iron triangle

In this model we allocate funding to long-lived or permanent teams (fund capacity). Then these long-lived teams will pick up pieces of work and deliver them one by one according to the priority that is set by the business.

In this model the finance teams can still report on spending for each project, but funding and budget needs to be allocated to capacity (long-lived teams) instead of the projects.

In this model we can tag different projects (or whatever unit of work we use) as BAU, Change (project), and infrastructure and enablement so the business can allocate how much they would like to spend on each work type by allocating fixed capacity for those work types. The business may also chose to categorise work by other attributes e,g, horizons, innovation, etc.

Quarterly or half-yearly budgeting

Many organisations have their main budget allocation on yearly basis. Once annual budgets are approved it is difficult to change those numbers and respond to change quickly as things change during the year. Yearly budget conversations is not often enough to enable business agility in a fast changing world like today.

We need to enable the business to respond to fast changing conditions. Quarterly or semi-annually budgeting cycles are more suitable for the fast changing economy of the twenty first century. Some companies do their budgeting in their quarterly business reviews. And some companies prefer to do their budgeting every 6 months.

Clearly there is a trade-off decision that needs to be made here. More frequent budgeting cycle results in more agility but will increase overhead. While less frequent budgeting cycles are less agile and have less overheads.

Participatory budgeting

Traditional budgeting is typically performed by starting from previous spending habit of divisions and applying incremental increase/decrease. While this method is very efficient it makes it harder to ensure the divisions do the right thing.

An alternative model to this is Zero-based budgeting. In zero-based budgeting we start from zero (or a baseline) and ensure every dollar budgeted is justified for next period. While zero-based budgeting is a more empirical approach, it is less efficient and it may result in micromanagement.

Another alternative is Participatory Budgeting based on business demand. Participatory budgeting is a democratic collaborative approach to budgeting and follows these steps:

• The attendees are broken up to multiple tables: Each table gets representation form various divisions
• Funds are distributed: The available budget is divided equally between the representatives on the table
• Baseline is established: The table must first fund all the initiatives that are required to “Run the Business” (baseline)
• Change work is funded: The tables debate to fund the initiatives that are required to “grow the business” (change or project work)
• Budget is allocated: Based on the result of the tables the budget is allocated to various divisions (capacity) based on the demand that is fully or partially funded.

To learn more about participatory budgeting please see the following links:

https://www.scaledagileframework.com/participatory-budgeting/
https://www.participatorybudgeting.org/
https://en.wikipedia.org/wiki/Participatory_budgeting

Create transparency

One of the best techniques to create transparency is the use of information radiators. One of the most effective ways of radiating informaiton is using a Virtual Obeya (Japanese for a large room)

Ideally the finance team needs to visualise the following in a Virtual Obeya information radiator and make it accessible to the entire organisation:

• Value stream spend vs revenue
• Visualised budgets
• Capacity vs demand view
• Financial performance dashboard

Ideally anything that is not confidential (e.g., salaries) must be transparent for the whole organisation to view and challenge.

Another technique to create transparency is establishing a shared language. This can be achieved by creating a taxonomy of cost pools corresponding to general ledgers entries. These costs pools can then be mapped to products, services, and the value streams consuming them. Finally the product/service/value stream spent is rolled up to the business units and capabilities.

Frameworks such as Technology Business Management (TBM) provide a predefined taxonomy (only applicable to IT). The TBM Taxonomy is a great starting point but please be aware that contrary to their claim, TBM is not an agile framework.

Economic decision-making framework

Financial indicators (e.g., ROI) are typically lagging and estimating them can be highly speculative. To enable business agility, we need to use leading indicators for decision making. These are indicators that can be measured real time and will indicate if we are on the right track or if we need to course correct.

Some examples of leading indicators include Google’s heart metrics (measuring Happiness, Engagement, Adoption, Retention, Task Success) and Dave McClure’s AARRR framework (measuring Acquisition, Activation, Retention, Referral, Revenue). Another approach that can be very useful is Throughput Accounting.

When using the agile finance model sequencing initiatives becomes more important than ever. Since we are allocating budgets to capacity instead of work, the business needs to have a mechanism to ensure the right projects are prioritised  and get done first.

One of the most popular economic prioritisation frameworks is WSJF (Weighted Shortest Job Fist). In this model we define priority by dividing value by cost.

Please note that financial value is only one aspect of value. We need to ensure we quantify other aspects of value including end user value, compliance urgency, reputation, opportunity cost, and other types of value along with financial value.

We recommend using the following formula for calculating WSJF. However, it is essential for every company to define the right parameters for their particular context.

How about tools and technology?

The first statement of the agile manifesto states “individuals and interactions over process and tools”. Tooling and technology may help us increase agility but they should not be the focus first.  We need to first fix our organisation design, structure, processes, and ways of working, before looking to tools and technology. One of the most successful transformations programs that we have observed had 2 rules:

1. Don’t break the law
2. Don’t change IT

Once the transformation program reached a stable state then the organisation started to focus on their tooling and invested in technological uplift.

It is often too easy to look for a silver bullet in a tool hoping it is going to solve our problems. But investment in technology before making systemic changes typically results in increased complexity. We must first come up with the right model then find the tools that can help us operate in that model more effectively.

Copyright Sprint Agile. All rights reserved. Free to use but attribution is required.

This tool is not under Creative Commons Licence. If you reuse, reference, or use this model as inspiration for your own work, you must attribute and reference Sprint Agile.

If you are interested in learning more strategies for increasing business agility please check out the best selling book by Arash Arabi, The Wise Enterprise: Reshape your organisation for the age of uncertainty.

The Wise Enterprise is available on Amazon in Paperback and Kindle formats.