At the beginning of an agile transformation, there’s an impetus to change workflows. Or at least, that’s the hope. The trouble is that budgeting often creates an adverse incentive system.
How we manage agile budgets and how we fund our products is usually one of the last things to change as part of the agile transformation. But the earlier you do it, the more successful your transformation is going to be.
The first step: Stop tying success to outputs.
Yeah…that’s far easier said than done.
Traditional funding incentivizes what I often call “wrong” behaviors.
As opposed to agile funding models, traditional funding typically follows annual budgeting cycles. You know the drill. A project manager or a company decides how much is allocated, or someone puts together a budget for the thing that needs to be built. That project is heavily scrutinized, and all the estimates are pushed up front to do the whole thing.
We incentivize getting the money over finishing the work.
Before you can even evaluate the value of the product, you have to wait until the entire project is done. When the scheduled termination point for a multi-year project rolls around and the product is incomplete and over budget, the tendency is to just provide more money to get the thing finished. During that entire process, the team rarely invests time and energy into evaluating if the customers or stakeholders really got what they wanted. When we emphasize starting the work—or worse, simply getting the work done—that’s how we get budget and schedule slips.
Estimating this type of work can be really hard. At the end of the day, we rarely know how much a project is going to cost. And so, when we estimate, we’re usually wrong.
The fallacy here, and the biggest stumbling point of agile, is that you have to accept up front that you may be wrong. The tendency is to try to find the ONE right answer, when that may not even exist.
What we need is the flexibility to fail.
Instead of output driven budgets, make them outcome driven. This means instead of deciding how much its going to cost, you decide how much you’re going to invest to try and achieve this outcome. Then:
Creative professionals inherently get this. They invest periodically (ad buys, content plans, social pushes, blog content) and then measure how that money is being spent.
Creatives start the work with some assumptions about what will work (creating targeted blog content to drive traffic to the website) and then use measurement tools regularly to determine how well that’s working (what traffic did it drive, is it the audience that we want, does Matt still get to send us his ideas for blog content or not, etc.).
Risk and creativity are a critical part of the equation, but so is readjustment.
If you’re not moving the needle, then it’s time to stop and reevaluate. Even if a product launch goes off exactly as it’s planned, without any stumbling blocks or interruptions, the initial set of assumptions or the kernel of the plan might have been a little off. So, even if you’re in the middle of executing the plan, you still have time to pivot and reallocate funds appropriately.
In agile, we fund value streams. If value streams have X amount, we always start with the goals. I had the chance to deploy this strategy recently. We were working with a pet food manufacturer that would allow their customers to put Snapchat-like filters on pictures of their dogs.
The more we dug into it, we ran into more complications than we anticipated. Firstly, facial recognition of a dog (as it turns out) is very, very complex. Which makes sense, right? A dog’s face isn’t quite as “standardized” or predictable as a human face. Dogs don’t hold still, it’s hard to get a square portrait of a dog face, etc. That meant the initial engineering and design was far beyond the scope we’d anticipated.
The first iteration didn’t (couldn’t, in fact) do the filter, but we figured out that we could allow users to put stickers (like funny eyes) on a dog’s face. As soon as we saw images of dogs with silly eyes and comical mouths, we realized it was funny…and we continued with the project.
That sounds like a simple, even trivial, example. But it makes my point. We could have pushed forward with something complicated without knowing its value. Because we had the time to pivot, what we came up with was valuable for the client.
Remember, we’re funding value streams. Allocate a certain percentage of your budget to creative, radical ideas or you’ll never change the face of what you’re doing. Everyone is always wrong to a certain degree. How you acknowledge that determines how you move forward. When you admit that wrong-ness is built into the formula, you can reposition yourself to learn.
Think of it this way: It’s not a matter of if you’re wrong, it’s when you’re wrong. With agile funding, if you’re wrong early on, you have more time to course correct, and you’ve invested far less financial and human resources on that plan. The closer you remain to the desired outcome (increased brand engagement through a hilarious app), the more you have time and money to try another idea (funny stickers!) if the first one doesn’t pan out.
We almost are never in the position to treat projects like a venture capital (VC) firm does, which is a shame. VC firms provide incremental funding (like a series A) for a smaller period of time to test drive an idea. If it doesn’t work, the firm has minimal risk exposure. If it does work, they invest more resources.
So, internally, you have to come up with something measurable to see if you’re getting that return on investment back. Remember, we’re trying to move a needle. If you didn’t get what you needed, ask: Was it the idea, or was it the scope of the initial funding or the resources that you originally allocated?
With agile funding, we use the right amount of investment to validate whether or not your idea was good. Put a box around the “wrong” idea, measure, observe, continue.
Traditional funding models create a false sense of security. Even with best practices, there are always unknowns. The short answer to this paradoxical issue is really simple. It’s “trust.”
The biggest barrier to this more agile way of working is the need to embrace failure. Failure has to be okay. Share the experience and make sure the entire organization knows why something didn’t work, and it makes the failure shared knowledge for the entire company. You’ll always get some value as long as you’re willing to invest in the experiment from beginning to end.
When teams are just taking orders from leadership, they don’t share in the failure when it doesn’t work. Give them the authority and the shared accountability—right where the direct knowledge is.
The trust has to be mutual. If you’re going to ask for people to trust you, you have to earn it. Create a culture where someone can trust you enough to feel safe trying something new. Leadership has to trust those teams to take those measured risks:
Throwing a ton of money at something is not a guarantee of success. If it were, everything that was well-funded would work. It’s very rare that the first time someone does anything it’s successful right out of the gate.
There’s value in the learning. If something doesn’t work (facial recognition for dogs), there’s still value in that experience. It also creates affordable, managed risk for the organization (funny stickers that still make the project worth it).
Failure has value when it has intent behind it. If you’re not measuring what you’re getting out of it, you’ll never know, though, if that risk is worth the failure. When you’re not tying your investments back to measurable outcomes, you’ll never figure out if it’s working or what’s wrong.