I’m Dave Lockie, CEO of Mojo Soup and for over 17 years, we’ve worked with government and private organisations across health, education, infrastructure and beyond, often partnering with local and state government teams to deliver and improve digital project outcomes.
That gives us a pretty practical view of agile: what works, what gets in the way, and where the theory needs to flex to suit the project in front of you.
If a government leader told me they wanted their organisation to innovate faster, one of the first things I’d ask them to do is look at the projects they’ve delivered over the past couple of years.
How long did they take? How much did they cost?
Then, for the next initiative, I’d seriously consider starting with half the duration and half the funding.
Use that first half to get something valuable into people’s hands. Keep the second half available for what you learn once they start using it.
Why? Because the beginning of a project is the point where we know the least.
We can research, plan, document and consult. We can make well-informed decisions based on everything available to us at the time. Then people start using the thing, and suddenly we know a lot more. I think our funding should leave room to act on that knowledge.
There comes a point when the only way forward is forward
Good agile delivery still involves plenty of planning.
Talk to people (yes, this is more important than ever!). Understand the problem. Capture requirements. Map processes. Work through risks and dependencies. Some of that work might look quite traditional, and it serves an important purpose: every useful piece of discovery reduces uncertainty.
I tend to think about this through the Cone of Uncertainty, a well-established idea in software delivery.
At the beginning of a project, there’s a wide range of possible answers because there’s still a lot we don’t know. Discovery, requirements, workshops and design work help narrow that cone. AI helps a lot here with ability to rapidly prototype and mock-up solutions.
Eventually, though, you reach a point where another workshop or another document or another mock-up iteration gives you roughly the same level of certainty you had before.
That’s when the only way forward is forward.
Build something. Put it in front of the people who will actually use it. Learn from what happens. That progress gives you information you simply couldn’t have had at the beginning.
Then you plan again, with a narrower cone of uncertainty.
That cycle – learn, make progress, learn again – is where I think agile becomes genuinely valuable.
What if go-live was the halfway point?
The same idea can shape how we fund projects.
Imagine an organisation has $500,000 available to solve a problem.
I’d be interested in what the team could confidently deliver for $250,000. Get that version live. Get people using it. Then use the remaining investment to improve it based on what happens next.
Those first weeks and months of real use are incredibly valuable.
People find different ways of working. Priorities shift. The team discovers which assumptions were right. Users ask for things that nobody thought to put into a requirements document. Some of those changes can be surprisingly small and make a significant difference.
Having funding available at that point gives the organisation the ability to respond.
It also changes the role of go-live. Go-live becomes another point in the learning process, with investment available to keep improving the outcome.
Agile should change shape as the project changes
The right approach will look different from project to project.
Sometimes the organisation already understands the solution well. There’s a known product, a known process and a clear implementation path. You can define a lot upfront.
Other projects begin with a clear outcome and a lot more uncertainty about the best way to achieve it. Those projects need more room to learn during delivery.
The governance around them can adapt too. Risk management, traceability, reporting, decision-making and accountability all matter. Their value comes from the purpose they serve on that particular project.
The same applies to the mechanics of agile delivery. If three stand-ups a week are keeping everyone aligned, have three. A different phase might need two. A difficult period might need one every day.
Keep asking why you’re doing something and whether it’s helping the team achieve the outcome.
For me, finding the balance between discipline and adaptability is what good agile delivery looks like.
We do enough planning to make intelligent decisions. We move when progress will teach us more. And we preserve the capacity (including the funding) to respond to what we learn.
This Thursday I’ll be moderating the panel Agile Innovation in Government: Is It Really Possible? at the Government Innovation Showcase.
Of course, we know it’s possible, but what are the conditions that could make it business-as-usual in your context? If you’ve got a view on how government should fund, govern or sequence agile delivery, come and find me! Conversation generates new insights!
