An Advent series - Finance and Budgeting in a world of Agile and Continuous Deployment
All software development should be agile and code delivered through CI/CD. A bold statement but one thought by many people. Agile gives the engagement between all involved stakeholders from the developers through to the user and helps everyone understand what is wanted. CI/CD helps to ensure that you can make small changes with next to zero breakages or impact - note that I did say helps and not just ensures there. These simplifications of the full reality are generally accepted by teams but for mid to large organisations there is a bigger question - how do you budget for an agile project?
How does budgeting usually work?
From experience, many organisations have a run the business pot and a change the business pot. The run side caters for keeping the organisation running with support teams and server costs for existing applications sitting there. For new projects, enhancements and new ideas, the budget comes from the change the business side. Apologies to any finance folks out there that I have over simplified the notion.
Many of the issues with budgeting comes as mid level managers have to make decisions about what is essential and work out how to expand what is considered to be run so that they can fit in projects considered to be important. Nice to have projects are then fought over in the change the business pots.
How are agile projects any different?
In some ways they are not. As long as you consider them run the business projects and accept that a certain level of enhancement to continue the application being effective is key. The problems crop up when user groups decide during the year (as budgets are generally run annually) that something larger needs to change. This could be because of a business opportunity, a regulatory change or just the whim of a senior director.
Agile projects are generally open ended with user stories gathered constantly and prioritised. The notion of a project with a defined end point disappears as you continuously enhance your product, adapting to change as you go along. At the start of each sprint, you look at the resources you have, compare with the stories in the backlog and get cracking.
A new way
The key to budgeting in an agile world is to have agile budgeting. Bring the review periods for budgets to smaller increments. Have sprint style committees to discuss the upcoming roadmaps and use planning poker for teams to be able to re-allocate budgets. Teams often hold budget for longer for fear of losing it so remove that fear and allow the flow between different areas more dynamically.
Retrospectives offer the perfect oppurtunity to see if budget is well spent and to steer future spend. Review the cost per sprint velocity and whether this is dropping. This is also a change to review hardware and cloud spend, allowing devs the opportunity to see the impact of their architectural decisions. With cloud computing, it becomes more instant to see the cost reduction of better performing code.
Sounds like utopia but will it actually happen?
If the willingness to change is not there then it certainly won't. This reckons more realistic discussions and more openness, something that can be lacking from large organisations. It puts more exposure but over funded areas that are not performing but also puts more pressure on constantly justifying work done. This may lead to more stress for teams but the aim should be to make rational discussions part of the new normal, reducing the constant stress of it.
Metrics will show that less money is wasted this way so the will should be there. Large enterprises are like juggernauts so it won't change quickly but more organisations like ING are adopting agile and so will be adopting more techniques like this. Time will tell.