Budgeting

Budgeting in a typical organisation where you have a few teams of full-time developers can be counter-intuitive. The monetary cost is fixed; your developers get the same salary whether they're building products, fighting fires, or goofing around on Facebook. What you're actually budgeting is opportunity: making sure that everyone is working on the most valuable thing they could be working on.

Is your budgeting process (or lack thereof) working well? Indicators that it might not be are:

• Development teams spend a lot of their time working on vanity projects, polishing burning platforms, creating software that never makes it to market, or writing variations on the same failed idea over and over.
• Development teams are always looking for something to do, or in extreme cases being dissolved and their members scattered due to lack of budget.

Sound familiar? Read on...

Project pipeline

It's impossible to talk about budgets without talking about the project pipeline. This is, at the most abstract level, the list of things you want to do as a company. Some of them will be big things, like building an integrated sales platform that links all of your disparate products together, or launching a product suite in a completely new vertical. Others will be small, like refreshing a few embarassingly '90s images on a website.

The important thing is that each project needs an outcome. Think of it as a level above epics (which are themselves a level above user stories). It's the answer to the question, "what should this project achieve?" That could be a simple financial metric like delivering £50,000 of incremental revenue or reducing server costs by 20%, but it could also something less immediately tangible: "get a foot in the door at a new client", "make it easier to upload new content", "learn about a new technology". All that matters is you have a simple, one or two line statement by which you can tell whether the project succeeded or not.

At this stage most companies will have projects that fall into three main categories:

• Low-risk, immediate gains - contracts already signed with the client, billable development time, known cost savings.
• High-risk, long-term gains - new product ideas, expansion to new verticals, products which have no client lined up.
• Self-improvement - learning, fixing processes, being able to deliver faster.

You should also be able to put very rough estimates on these. There's no point trying to be accurate, because at this level of detail you'll fail, so all you're looking to do is work out whether each project is 2-4 weeks, 1-3 months, 3-6 months or 6+ months for a team to get to the outcome, plus an order of magnitude stab at any hosting or software costs you expect to incur.

Assigning the budget

With both outcome and time cost, you can start deciding whether any individual project is worth it. This is good old-fashioned MoSCoW analysis: dividing things into categories of Must, Should, Could (if we have time) and Won't. Half a year for £5k of incremental revenue is probably a Won't. A couple of days to get your development network into shape and save time on all future projects could end up a Must. This is where the process is closest to traditional profit and loss reporting; you're balancing the potential payoff with the effort required to get there.

There's some judgement required here on the layout of your organisation. If you're a small company, you might skew more toward the low risk, immediate gain projects because that's what you need to keep the lights on. With VC or money in the bank, you might think more about the long-term payoffs. Keep in mind size vs. risk as well. Doing six one-month projects that might pay off could be better than doing one six-month project that's lower-risk, but with a smaller potential payout. You're looking to balance (time taken * chance of payout * size of payout) to be as large as possible.

At this point, you now have a list of projects, ranked in order of importance. You know what your top priority is, and therefore you know that needs to be assigned to the next team to become free.

But what about detailed cost estimates?

What about them? What we're doing here is getting rid of things which don't matter. All you need to decide whether a project is worth doing is a rough idea of how large it is. If you need an exact cost to decide whether an outcome is a success or a failure, then you may as well shortcut the entire process upfront: it's going to be a failure.

Detailed costs and timescales aren't the input to your development process, they're the output. This is one of the things people new to Agile really struggle with, so let me put it in basic terms: saying something will take precisely 3 developers precisely 26 working days does not make it so any more than Canute can turn back the tide. You need to get the feedback from actual, real-world development before you can get that level of accuracy. Once you accept that there's always going to be uncertainty, you can also start managing it effectively; measuring deviation, and making intelligent decisions on scope and delivery dates in response.

Scheduling the work

Before we get too far into how work gets scheduled, let's recap two crucial facts about teams:

• Existing teams are massively more effective than newly-formed teams; the people working in them know and trust each other, and understand how to communicate.
• The most efficient number of projects for a team to work on concurrently is one.

The net effect of that is that if you want your teams to work at maximum efficiency, they will remain relatively static (not dissolving and reforming between projects) and they will work on a single project at a time. You might need to add or remove people from a team from time to time to add key skills or simply deal with turnover, and this isn't a huge deal providing you understand it comes with a moderate productivity hit, but do not ever, ever, ever be tempted to have a team work on two things at once. Task switching will utterly destroy your productivity. The best outcome you can hope for in that scenario is for the team to concentrate on just one of the projects so at least one thing gets done to a reasonable standard.

So you have n projects you want to get done, and m teams, with n usually being greater than m. How to deal with that?

The key is to prioritise well and manage deadlines. You'll have some things which are critical and need to be done by a certain date, and these will top the list, followed by the still-critical but less time sensitive projects. The trick is that while your teams are busy building products, you keep making sure the priority list is up to date. What was top of the list to be picked up in April might be pointless by October. That doesn't matter; what matters is that everyone was working on things that were more important to the company than what you didn't pick up. (For example, you might decide to pass up an obvious but time-limited revenue opportunity to work on something of longer-term value.)

Aftermath

Like everything in agile development you need a feedback loop, and the one you're looking for is this:

Did we achieve the outcome we wanted at the cost we were hoping for?

This is where your detailed tracking of sprints, expenses, rate cards and all the rest come in. The reason for that is because now you're working with known values. You're not saying, "a team that's maybe an architect, a senior developer, a designer, three devs and a QA might work on this for 12 weeks" - you're saying "a team of this composition did work on this for 12 weeks". You're not saying, "this might make £50k of revenue in its first three months", you're saying "revenue for the first three months was £48,675".

Asking this question is a vital part of a feedback loop that keeps you working on the right things. Between successes and instructive failures, you're looking to build up an organisational body of knowledge - things like:

• "Expensive projects tend to underachieve compared to our expectations."
• "This client rarely takes us up after a trial."
• "We tend to do really well when we target this demographic."
• "Working with ITIL-heavy organisations is almost always slow."

Key is that it's a feedback loop. You learnt that working with an ITIL-heavy organisation really slows you down, but all the clients on your top-priority projects are massive ITIL shops? Time to update those time estimates, re-evaluate priorities and maybe look at doing something for a customer with a leaner process.

Why this works

It's simple:

At any given moment, every developer is working to achieve the outcomes which are most valuable to the organisation at that time

This is important. Nobody is doing something because it was cheap, or because it had a deadline, or because they needed something to occupy themselves with. They're working on the things you want to do as an organisation: the products you want to build, the process improvements you want to make, the future you want to prepare for. And on the occasions you do misstep, what you learn goes straight into your feedback loop; you don't keep building the same failed products because they look profitable on paper.

Remember: no matter what your budget says, the amount you're spending on full-time developers is pretty fixed. What you can change is how much return you get on that investment. Budget for opportunity, not cost.

_{Image by Matt Kimber CC-SA 3.0}