The sign-off paralysis lurking under the surface of agile projects
CFOs can’t make investment decisions every five minutes - there wouldn’t be enough of those minutes in the day.
Instead, they need to think bigger picture and assign monetary investment to teams across much longer timescales - like a year.
Agile teams by definition don’t know exactly what they’ll be doing months ahead of time - if they did, they’d be running waterfall not agile. For the same reason, they also can’t state with certainty what they will have delivered by when.
This is expected behaviour but can lead to considerable delays (in my experience often 30% or more of the total project time) when the two sides clash, throwing the usual budget process off track and locking the team in a form of sign-off paralysis.
It can lead to some awkward conversations:
“So before we invest, tell me how much / how long will it cost to build the MVP”.
The question should elicit some peculiar looks around the table.
“We’re not sure, it depends on what happens with our experimentation, on the accuracy of our technology estimates (expected to be low) and on the feedback from the market and internal users”.
Well, that’s going to make providing for the team’s funds in the annual budget cycle a little difficult. “Can you at least tell me what I’m going to get if we invest 1M USD?”.
“We’re not sure, we have a current vision, but it depends on what happens with our experimentation, on the accuracy of our technology estimates (expected to be low), and on the feedback from the market and internal users”.
Ah. Then no budget or investment for you.
Of course in reality that won’t be what happens. There will be many pained looks. The CFO may cry a little - and then the team will come up with some kind of time prediction to try and get sign off.
When that plan turns out to be incorrect (which it was always going to be) the stakeholders who were not entirely convinced about this great expedition the first time around, will hold a big fiery stick to the team’s feet.
Think like a VC
Wouldn’t it be better to just do away with long term planning cycles? Wouldn’t that be more agile?
Yes, but it wouldn’t help our investors and CFOs who need to draw at least some lines of certainty over the upcoming plans to prevent their own feet being held to the furnace.
This is not a new problem. In fact, whole debates have already sprung up on this very topic (searching for #NoEstimates will get you some background) with key thinkers pointing out the obvious flaws in trying to fit an agile project into a standard budgeting process.
A good option is instead to have CFOs and investors think more like a VC - investing in teams and broad goals rather than specifics, whilst viewing the whole roster through a probabilistic lens.
What would this look like in practice though? I’ve been puzzling for some time on how we might pull the threads of this together - and one day, during a recent corporate Fintech project where this exact problem was slowing us down, I had a flashback to a meeting with a wise man during the early days of my startup, laZook.
A meeting with Matt Robinson
It was a mild 2013 Tuesday on London’s South bank. Dan (my COO) and I had wondered over from the office in Holborn and were making a date with an introduction from our investor, Robert Dighero of Passion Capital.
The meeting had no specific purpose that I remember, but I suspect Robert just wanted Matt to share some sagely advice from an experienced entrepreneur to those still wet behind the ears - and frankly I’ll take that kind of meeting whenever someone offers it.
As we sat drinking mint tea at Pain Quotidien (this was so long ago now that London still considered this the type of cool place startups might hang out), I remember Matt listening to our story to date, which was at that point neither a stellar success story nor an unsalvageable mess - and asking a single question:
“What is your Zombie milestone?”
Dan and I looked at each other quizzically - trying to gauge whether this was a part of the startup lexicon that we were already meant to know.
“What’s a Zombie Milestone?” said Dan taking the hit for the team.
Matt had been expecting this I think and embarked on the tale: “When Tom, Hiroki and I started GoCardless we were brutally aware that our chances of success were really very limited - just like every other startup. We weren’t super stressed about this, what we were stressed about was continuing for too long, when we could have invested our time and efforts in something that would prove to be more valuable”.
The fact that they had understood this important “founder opportunity cost” challenge out of the gate rather than committing their body and soul to their new brain child already had my attention. It was something I also held very close to my heart.
“We decided to give ourselves a time box. We thought: We don’t know exactly what we’re going to do or how long it’s going to take - but if something can be made of this, then we should certainly be able to find it and generate some traction within a year”.
“We decided if we hadn’t reached X customers by that point, we would abandon the concept and try something else. We called it a Zombie milestone”.
Now unfortunately the sands of time have occluded to me exactly how many customers X was - although I note that in the end the team didn’t have to make this call. They had by that point become a highly innovative solution to a real problem in the UK market.
I mulled over Zombie milestones significantly for the next few weeks - knowing that I myself didn’t have one.
We already time box at smaller scales
It also occurred to me that at smaller scales we’d been doing this for some time.
At the micro, I’d been using this technique as a developer to avoid a common pitfall. Countless were the times I sat down to do something “easy”… something that would “only take me the weekend” only to find some hidden depths to the problem that cast me into an endless black hole of diminishing returns.
I liked to use the term rabbit hole as a description of this risk, and outside of coding, I’ve seen it rear it’s ugly head in an even more pronounced way with data science and machine learning: “Let’s get a model running that will simulate this, it’ll only take a few days”.. uh huh.. I’ll see you next Christmas then once the data doesn’t play ball.
To counter this problem, we time box by saying: “If this is really solvable in the way we think, we should have a proof of concept working in a couple of days - let’s make sure we don’t go down the rabbit hole”.
Going up one level to sprints, time boxing is certainly nothing new. It’s an integral part of many agile methods like Scrum. We ask our teams: “Let’s come up with a sprint goal that seems reasonable to hit during the the next few weeks”
Why would we not continue this time boxing upwards to the larger cycle times?
Zombie Milestones in agile projects
What if we were to take the insightful thinking from #NoEstimates and the VC view of the world, and merge it with some more budgetable, metric driven controls?
We could even steal the term Zombie milestones from Matt Robinson.
CFOs, investors and entrepreneurial teams would then ask themselves the following questions:
- What specific metric change will make this team’s work sufficiently valuable that it would have a tangible impact? We would call these “Ambition metrics”.
- Based on previous projects, what would be a reasonable, ball park time box for the team to show some traction (this would usually be in the 6 month - 2 years range and should take no more than one day to come up with)
- What capabilities might the team need?
From these questions, a high level budget number for the first iteration can be put together.
Note the key shift from:
- What will be delivered / how long will it take to deliver X?
- How are you tracking against the specific features you agreed to deliver up front?
- How are you tracking against your ambition metrics?
- Will the team continue automatically into the next cycle or will they hit the Zombie milestone and expect significant scrutiny over any further investment with a default judgment of winding things up?
Possible good reasons for continued investment would be, for example, a clear and data backed pivot into a new segment or technology:
“Our learning so far has demonstrated that Microsoft Dynamics is how we should tackle this problem - can we have another cycle to validate this?”
This would be a simple, data driven process that brings the VC mindset to life and makes it easy to understand what happens at the end of the period if there is no traction against the ambition metrics.
A focus on team responsibility for value creation via ambition metrics rather than the execution of a list of specific features.
Clearly, not all the answers
This still doesn’t answer all the questions and I’ll admit that some key points offer challenges:
- How do we incentivise a team to keep working at full speed even when hope seems lost that they will make traction against the ambition metrics?
- How can an investment committee really make a good decision on whether to continue funding a non tracking value stream vs letting it die?
- What if the teams discover they need further funding that wasn’t accounted for?
Ultimately however, we’d at least have found a way to bridge the gap between longer planning and budgeting cycles and a proper agile mindset.
Perhaps we’d avoid weeks or months of budgeting paralysis - often at just the moment our entrepreneurial teams are getting into their stride.