Real-World Agile Budgeting

Originally presented at SoFloDevCon 2022, this article explores different strategies internal and external teams can use to communicate budgets and roadmaps to stakeholders.

First, Some Background and Caveats

We are a custom software development company (https://tsl.io/), so I’ll use the term “client” a bit more than someone who works for an enterprise making internal tools. Other types of enterprises of course have clients, but the relationship between their projects (software or otherwise) has people called “executives” in the decision-making roles. I will try to use “executive” but for this presentation, they mean the same type of person or committee.

Why we use Agile

NOT because it is better than waterfall - waterfall works great in many industries. If we lived in a waterfall-friendly environment we’d be having a discussion about Six Sigma right now.

NOT because it is fashionable ;)

NOT because it empowers teams, but just the act of having a retrospective with the people who do the work and acting on the issues brought up is almost transgressive in some other environments.

BECAUSE we live in a complex, ever-changing world and we need a framework that allows us to embrace change as a part of life.

This is not a discussion about “how to be a change agent”, this is going to be a discussion about the realities of planning projects in a Volatile, Uncertain, Complex, and Ambiguous (VUCA) world.

On to Budgeting

First, who is doing what?

• Who’s paying
• Who decides how much something costs?
• Who really decides
• Who decides how much something is worth?
• Who decides the priority order?
• Who decides what’s a bug versus a new feature?
• Who really defines when something is done?

Example: A team might have a definition of done that everyone agrees to, but if “who’s paying” is running low on money, items that were done six months ago might suddenly find their done-ness challenged.

Second, what’s the goal?

Executives/clients want to know “how much everything will cost”. They don’t like being told that this is literally unknowable unless you can see the future, so we have to do our best to try to get them to define “everything” and use the tools relevant to your organization to:

Organize a planning document describing the roadmap to an MVP, prototype, first phase, or whatever the relevant term is for the first milestone (major or minor).

Depending on your organization's resources, you may use some combination of:

• Hiring an outside design firm to assist you with defining your product
• Use only spreadsheets and post-its
• Work mostly in email and Word

Ask a representative from all stakeholders for feedback, prioritization, and questions:

• Legal may have some compliance requirements
• The sales team may want to be able to track some metrics
• The customer service team may be aware of “dark patterns” to avoid
• The development team will have technical questions and solutions
• The bookkeeper will ask for a Quickbooks integration

Depending on the culture of your organization, this document might be very large with many images and design files and flow charts, or it may be a list of bullets.

In any roadmap, there’s a risk of hand waving away a huge black hole of complexity and expense.

This is just a planning document, because something is “just a button” on a mockup, or just a box on a UML doesn’t mean it won’t take a team of PhDs to develop the feature.

What’s the Goal? Some common pain points

• Client/Executive doesn't know how to describe what they want. This will make “when is it done” very hard to define.
• Client/Executive doesn't know specifically what they want
  • Don’t want to know (what they want is illegal and they don’t want to accept this). If they accept a legal version of what they want, they may perceive the final solution to be more expensive than what it should have been and feel like a project went over budget.
  • Just uneducated
  • They want A, B, and C but need a budget in order to be able to determine ROI
  • They want A, B, and C but need to know what some clarifying questions (for example - competitive analysis) are so they can focus their path
• They really don’t know what they want
• Client/Executive wants something, but it's not possible
  • without a team of PhDs - robot child that reminds you of your dead grandma
  • without significant venture capital investment - recreate Uber (really recreate it, not just make an app with a map)

Now that the overall goals have been defined

Defining the MVP / Phase 1 / First Milestone / Foundation

What an MVP should be:

A meaningful viable product that takes the project into a version of viability with an acknowledgment that it might not be the scalable final product it will grow into

What the “Executive” hears:

How many features can I get with this amount of money? I don’t really need an “MVP”, I want the whole thing, and an MVP sounds like paying for a half-baked solution. They’re literally telling me it won’t be “done” at the MVP level. I would have bought off-the-shelf software if it were available, but now I have to build this custom thing.

What if Executives do not accept the concept of an MVP?

If the Executives do not accept the concept of an MVP, don’t call it an MVP - call it “First Milestone” or “Version 0.1”.

After all, an MVP is just the first step on a longer journey, and it will signal to the executives that their budgetary concerns are being taken seriously and that you will be estimating beyond the MVP.

At this point, you will have to take some time to define the next phase after the MVP as much as is reasonably possible.

Executives do accept the concept of an MVP

If the executives do value iteration, we can plan for the phases after the MVP, but know that our executives will understand that as we learn more about the project we are building, we will be able to give better estimates for future features.

Estimating the MVP / Phase 1 / First Milestone / Foundation

**Warning** This will be different for each organization

Estimation of MVP Backlog Items

Using whatever metrics your team uses for estimating complexity and translating this into time or money, address each item of the MVP backlog and add these to the first version of the budget.

Identify Research Tasks (Spikes)

If any of the backlog items will require research or experimentation, try to address these tasks ahead of time with the executives. Although it is often the case that research has to be done “just in time”, the time spent on researching doesn’t have to be a surprise.

Identify Third Party Risk

Every third-party integration has the potential to make your development flow more complex.

Add a realistic buffer for bugs (or “bugs”), firefighting, “emergency changes from the sales team” and other miscellaneous tasks

Prepare a Budget and Roadmap

Using your estimates, knowledge of how the work is valued (in money), and the team’s estimated velocity, create a budget and timeline, describing deliverables at each stage.

Present the First Version of your Budget to the Executive Team

Result A: Decision-makers are happy with the budget.

They approve the whole thing and the team starts working. About halfway through, the team realizes that integrating with one of the third-party dependencies, a task that should have taken a week to complete and test, is taking a lot longer than expected and is still not done.

Option B: Decision-makers are shocked at the budget

Armed with the budget, the team and the executives re-prioritize tasks (some items are not worth the cost) and sync up to see where the disconnect is. The process begins anew.

time passes ...

The project is Over Budget and still not “Done”

Scenario: Team hits road bump - Team feels things aren’t done

First Aid - Try to not go off the rails

• Don’t blow out the budget on a death march
• Have mechanisms for identifying a time suck (“will be done today” for a week) and addressing it as soon as noticed
• Be able to differentiate between “actually not possible” and “we went in the wrong direction and will have to refactor”

Prevention

• Open book management (team knows the budget, the team or organization profits, and some form of profit share is enacted)
• If the team is really aware of how the budget works and how it impacts their personal bottom line, there is a lot of motivation for success
• Strong mentor program: If a teammate is going down the wrong path, mentors should be supported in being able to check in and guide their teammate towards a more productive path, without burning out as mentors.

Scenario: First phase has been “Done” for a while now and Executives are complaining about the continuing budget and asking “when will it be done” and “why is this so expensive” - Communication Issue

We talk a lot about the “definition of done” at the team level. In organizations with a robust UAT scheme, it is usually clear across the board when something is considered officially done.

However, it does occur that a stakeholder who previously considered certain items to be “done” is now complaining about things not being done. This may be a symptom of:

• Lack of “real” user testing
• Scalability issues
• The organization is running out of money
• Lack of stress or volume testing
• Communication issues
• Outdated documentation

First Aid - Maybe they’re right, Check

• Reassess your QA and testing scenario, is there some miscommunication?
• Re-assess your DevOps and stress-testing scenario
• Review those items literally celebrated as declared done, has something changed that is not reflected in the user manuals or training materials?

Prevention

• Stakeholders and decision-makers change over time, make sure to have a good relationship with decision-makers so these changes don’t come as a surprise
• If you are an agency doing work for an outside client, have a strong contract and do table-top exercises about disputes
• If the team is doing work that is “outside” of the roadmap - for example, assisting the support team as they learn the product, make sure to include this in your reports to decision-makers.

Conclusion

Hopefully, this was useful! Check out more of our Agile articles.

Photo by Niklas Bischop on Unsplash