Traditional vs Agile budgeting I of II - Planning

For quite some time I've addressed the budget topic from different approaches. 
I recently had the opportunity to read some things from Kenneth Rubin, who had a few things quite clear in that regard, but with a different approach, that I hope I rephrase and state here in the most truthful way I can to you, with a few drops of my perspective and experience on the matter.

Traditional Budgeting

"We need to define the yearly budget per cost center. Remember to be as precise as possible, you are going to be measured against that"

You might realize that this process.

  • Requires detailed up-front financial projections and business plans.
  • Promotes greed for finite resources.
  • Instills a use-it-this-year or lose-it-next-year mentality.
  • Leads to utilization-based planning and execution.
  • Fosters rigidity - Budgets are hard to change.
  • Complicates things in a project-based environment where the projects touch many cost centers.
  • Biases teams towards least-risky solutions.

Annual planning assumes long term stability in a complex world:

Planning the entire next fiscal year up to 15 months in advance. Could be unrealistic to assume we know all that will happen and we are reducing our chances to be flexible and redefine a new course if needed.

Belief that planning in one large batch has economies of scale.

In software that's not entirely true, if you fail you fail on a large scale. software is not a mechanized repetitive work so long batches won't give you the benefits you are used to.

Assumes master budget/portfolio

And we are doing all this work with the worst possible information.
"Please give me the details, and you can't change them later".

Gantt chart: Assumes we got it right.

Where you are going to be in 9 and a half months from now, and what you are going to be doing is something you do not have a realistic level of precision to be able to communicate.

To derive a master/budget plan we need to understand complete resource allocation. We usually aim people to be 100% utilized.

WATCH THE BATON, NOT THE RUNNERS 

Largest cost is people and we tend to optimize the resources allocation. It's the most easy to spot.

People is the most expensive resource, so unused resources seems like waste.
A guy with 60% allocation will be spotted as one not working all that we are paying, and a manager that handles him will be measured on how allocated does he have his resources.
So, let's add that guy to a second project, now he is on 90%, that seems better.  There's still 10% waste... let's have him looking at the smaller idle projects. So clever, now I've eliminated waste.
Underutilization went to 0. But... Are we taking effectivity from somewhere by doing this?

Let's try the same strategy with a four by one hundred meters relay race runners.
I pay a 100% salary to the runners but they run 25% of the race. I will look to eliminate runner under utilization. "Let's keep them racing another race". That would completely miss the point.

  • That won't give you a gold medal, what will instead is them getting the best of that 25%.
  • If the baton ends up on the ground you don't win the gold medal. Going back to our line of work the baton on the ground would mean that the work that is blocked, delaying our deliverable.

"We are waiting on something your team needs to do, until your team does this, my team is blocked."
This kind of conversations happen all around product development. Work blocked not moving. The end result is severe economic damage.

What causes the damage in organizations isn't idle workers, is idle work.
On budgeting and planning we are optimizing the wrong variables. by optimizing resource allocation we are under-optimizing work allocation by placing it in queues all over product development. This causes severe damage.
Queue size = Cost of delay.


AND it's expensive to maintain all of that budgeting/planning inventory.


(Excel for all the budgets everywhere, Resources allocation tracking, Gantt plans that need to be up to date constantly).
You would need an army of people that needs to have this updated for no particular good reason.

Assumes budget and plans are correct, so stick to them.

"Default deviation means you have bad teams: better get a project manager to put this back on track."
The more likely assumption is to have a bad plan. In agile we constantly re-plan.
"When hiking and the map does not match anywhere with the terrain, believe the terrain."
Should we follow a plan that we got at the beginning that most likely is wrong?. We should re-plan.

  • We think that plan deviations are result of poor management and execution.
  • We ignore insights that are generated as conditions constantly change.

Experimentation might show initial assumptions about cost and value are wrong.
Following an original plan -no matter how well conceived or how skillful execution- can be a recipe for disaster.

Leads to time consuming and often mis-focused variance analysis.

When you cross a variance threshold finance involves on it. Agile inspect-and-adapts towards finding the true goal, not to follow the original one.

Variance analysis:
  • Reactive - Only if variance is large enough. Why I crossed the line? Because was the correct action at the time.
  • Forces an explanation for why things are varying from a presumed original correct target.
  • Not a value adding activity.
  • Slows down rapid response. You'll think twice before taking action to not cross the threshold.

DO YOU WANT TO BE RIGHT OR SUCCESSFUL?

On cost centered budgeting 

Budgets often align with cost centers, but projects can span across cost centers. It's hard to imagine that this is going to be agile.
What if you realize less of the work is here and more there? This will become in a major problem under that organization.

Agile budgeting/planning dealing with uncertainty

There's no reason to assume the agile values cannot be applied to finance (and even everyday life). Let's try to understand how can we apply them.

  • Start understanding as an assumption that you can't get budgets and plans right up-front. 
You might receive an: "Ok, fine I'll fire you and find somebody who can".
I'm not saying we don't do it, we do it up to a helpful amount. Up-front budgeting/planning should be helpful without being excessive. It would never work for you to go to the CEO to tell him we won't budget and plan at all.
  • Keep budgeting/planning options open until last responsible moment. It'll be less likely to make a mistake. Economically decided (when the cost of making the decision is more or less the same cost of not making the decision).
  • Plan roughly for the long term and more accurately for the short term. You should have better visibility on a short plan. (Allocating money for 100% of the next quarter but not 100% of the following ones, to be able to maneuver).
  • Prefer experimentation (knowledge acquisition) over a desire for precision. "When will you be done?" Assumes a level of info I just don't have now."I don't know exactly that date but I exactly know what experiment I can do to acquire the knowledge that can give more precision in my answer". You can then aim to reduce the range. Buy information: PoC, Prototype, experiment, study; are all ways to reduce uncertainty.
  • Focus more on adapting, re-budgeting and re-planning than conforming to the original plan or budget.

Agile budgeting/planning - batch size


  • Budget and plan in smaller batches with horizon-adjusted precision.
    • Will get you some kind of overarching effort, but will reduce the unknowns.
    • Big companies define a budget for the area top down and after that the negotiation goes con how much work can you get that people will be happy with its output.
  • Budget and plan in more frequent increments (releases).
  • Optimize budgeting and planning at levels above teams and projects. In terms of ability or features.
    • Avoid micro planning. You can maneuver then without needing to ask permission to do things.

Accountability: "Did I get good value with this sprint?"
If I don't, I have a conversation with the team. Then either I change my expectations towards value or terminate the contract, which I'm always allowed to do.

Agile budgeting/planning - decentralized decision making


  • Empower "mission command" - fast, additive, de-centralized decision-making rather than having teams delay waiting for permission to proceed.
Each line defines the things they know best and defers to lower levels how to get there. Trust replaces need for wasteful and ineffective top-down command and control.
  • Culture of transparency regarding what we know and what we don't know.
-"Leadership don't want to hear bad news"
  -"So you what, communicate only the good news? Bad news don't go upwards?" 

You can't be agile without transparency. (Transparency, Inspection and Adaptation).
It would be really hard to get that continuous improvement under a non transparent culture.

  • Fast and flexible resource allocation to swarm to emergent value.

Say you happen to face a billion dollar revenue improvement opportunity, wouldn't you like to have the possibility to swarm on it?.
"No, that will break the budget we have for this year, we have all these things to do, we'll have to let that go, see? here's the threshold we can go to."

  • Focus on removing bottlenecks rather than explaining variances to original effort estimates.

Get rid of bottlenecks and explain why you are moving forward due to that.
"Explain to me why did you went through the threshold of 10k USD"
Will that really buzz the budget alarm for your organization?

I do have a lot more to talk about, next time I'll talk about the impact of the strategic initiatives in the budget, it's organization, a few agile budget approaches, and "cost accounting under agile: capital and expense".

Part II >>

Comments

Popular posts from this blog

Communication, one of the agile pillars

The glass ceiling: Water-Scrum-Fall

Measuring success in companies pivoting to agile