Agile Does Not Fail in Government.

Governance Fails Agile.

A practitioner’s guide to what actually blocks transformation in the Caribbean public sector — and what to do about it.

The first time agile enters a ministry, the room usually tells you everything.

The technical people are curious. Some are even relieved. Finally — a way to show progress in smaller pieces instead of disappearing for months behind a project plan that no longer reflects reality.

Middle managers are cautious but interested. They want to know how reporting will work, who owns the backlog, and whether this new way of working will make their lives easier or expose them to more risk.

But the real tension sits higher up the table.

It surfaces the moment senior leaders understand what agile is quietly asking them to accept:

We do not fully know what we are building yet.

For many public-sector leaders, that sentence feels dangerous. And that discomfort — entirely understandable — is precisely the barrier that makes agile transformation in government hard.

The Comfort of the Paper Trail

Government loves a paper trail. With good reason.

Every dollar must be justified. Every procurement can be challenged. Every delay can be questioned. Decisions may one day have to be explained to an auditor, a board, a minister, the media, or the public. So the system protects itself — with detailed business cases, fixed scope, defined milestones, signed approvals, reporting packs, and steering committees.

None of this is wrong. In public-sector delivery, these controls are necessary.

The problem begins when the paper trail becomes more important than the truth on the ground.

A project can look well governed and still be failing. The dashboard can be green. The minutes can be clean. The risks can be carefully worded. The sponsor can be reassured. And then, the week before go-live, everyone discovers what the users already suspected, what the technical team quietly knew, and what the project reports did not fully say:

The thing being delivered is not the thing people actually need.

That is the danger of false certainty. Traditional delivery measures accountability at the end. Agile creates accountability through delivery itself — asking different questions, much earlier: What did we deliver this sprint? What did users tell us? What changed because of what we learned? What decision is blocking progress?

You can soften a written status report. You can delay difficult news through governance layers. You can keep a project looking alive long after it has stopped producing value. But you cannot easily hide a sprint review where nothing meaningful was produced.

Government wants certainty before delivery begins. Agile creates certainty through delivery itself. That shift is uncomfortable. It is also necessary.

The Moment Agile Becomes Real

Agile becomes real at the moment a leader gives a team permission to act on what it has learned. Not permission to ignore governance. Not permission to bypass accountability. Permission to make evidence-based decisions within clear boundaries.

That is the part most organisations miss. They train Scrum Masters, create backlogs, schedule stand-ups, run sprint planning, hold retrospectives, and rename meetings. But the real question is never whether the team is using agile language. The real question is:

Who is allowed to make decisions when new information appears?

In many government environments, decisions still move slowly upward. A team discovers a problem. The project manager escalates. The programme manager reviews. The steering committee requests more information. Legal or procurement may need to comment. The next meeting is scheduled. The team waits.

By the time the decision returns, the situation has already changed.

That is how agile dies inside a bureaucracy. Not loudly. Not dramatically. Not because anyone openly rejects it. It dies while waiting for approval.

Decision rights — who has authority to make which decisions, at what level, and based on what evidence — are not an administrative detail. They are the foundation on which agile either stands or collapses.

Agile Theatre

There is a version of agile that looks impressive from the outside. Daily stand-ups. Walls covered in sticky notes. An active backlog. A Scrum Master who facilitates well. A velocity chart that gets updated. Steering committee reports full of agile terminology.

Everyone appears to be doing the right things.

But underneath the language, nothing important has changed. The team still cannot adjust scope without escalation. Users still do not see the product until late. Senior leaders still want certainty before learning has occurred. Progress is still measured by activity rather than usable value.

That is not agile. That is agile theatre.

The organisation has adopted the rituals of agile while preserving the instincts of waterfall. It wants the speed of agile with the comfort of traditional control. It wants innovation without uncertainty. It wants learning without adjustment. It wants user feedback — but only after the major decisions have already been made.

That contradiction eventually shows up in delivery. Always.

Why the Retrospective Matters More Than You Think

One of the most underrated agile practices is the retrospective. To some leaders it looks like another meeting. To a disciplined delivery organisation, it is something far more important.

The retrospective asks the team to stop and examine how it worked. What slowed us down? What did we misunderstand? Where did handoffs fail? Which decision took too long? What should we change before the next sprint?

For many public-sector organisations, this is quietly radical. Because bureaucracies are not naturally designed to say: We got that wrong. Here is what we are changing.

They are often designed to defend decisions already made.

That is understandable. Public institutions operate under scrutiny. But the irony is this: the refusal to acknowledge small failures early often creates larger failures later. A good retrospective does not weaken accountability. It strengthens it. It creates a habit of correction before the cost of correction becomes too high.

That is what mature agile gives government: not less control, but earlier truth.

What the Caribbean Must Be Honest About

We cannot import a model from the UK, Australia, or a large private-sector technology firm and assume it will work here unchanged. Our context is different.

Many agencies operate with small teams. Specialist skills are limited. The same people sit on multiple committees. Procurement cycles can be slow. Technology teams are stretched across too many priorities. Decision-making may be split across ministries, departments, boards, vendors, and external partners.

Agile assumes certain capabilities: a product owner who can make decisions; users who can be engaged regularly; a team with access to technical, business, design, testing, and change management skills; blockers that can be removed quickly; and leaders who are willing to let evidence change the plan.

In many Caribbean public-sector environments, those conditions do not automatically exist.

That does not mean agile cannot work here. It means we must stop pretending that adopting the terminology is enough. The honest question is not, ‘Are we doing agile?’ The honest question is:

Have we created the conditions for agile to produce value?

If the answer is no, then the work must begin there.

Start Small. But Start Properly.

The best way to introduce agile into a bureaucratic environment is rarely through a grand organisational mandate. It is through one visible, well-chosen project.

Not a symbolic pilot. Not a rebranded project. Not a donor-funded experiment that produces a final report and disappears. A real project — with a clear user group, visible value, manageable scope, an engaged sponsor, and a team with enough authority to act on what it learns.

The goal is not simply to deliver a product. The goal is to teach the institution a new way of working. That is why the first project matters so much. The right project creates proof. It gives leaders something to see. It gives users something to respond to. It gives the team something to improve. It gives the organisation evidence that a different way of working is possible.

That is how transformation begins to take root. Not through slogans. Through visible delivery.

The Citizen Test

There is one question every public-sector leader should ask of any agile project:

When does the citizen — the business owner, student, patient, public officer, service user — first respond to what is being built?

If the answer is ‘at launch,’ the agile is decorative.

Real agile brings users into the process while there is still time to change the outcome. Not to hold more meetings. Not to use more modern language. Not to make project reports look innovative. The point is to avoid spending months or years building something that fails the people it was meant to serve.

A licensing system that businesses struggle to navigate. A health platform that nurses find impractical. A student portal that generates more support calls than it resolves. A public service application that digitises the confusion instead of removing it.

These failures rarely happen because no one cared. They happen because users were brought in too late. Agile, properly done, changes that. It forces reality into the room earlier.

The System Has to Learn Before It Fails

The stakes in government transformation are not theoretical.

When public institutions cannot connect information, respond quickly, or adjust based on evidence, the consequences can be serious. The lesson from major public-sector technology failures around the world is not simply that projects were badly managed. It is that institutions failed to learn fast enough.

The warning signs were there. The people closest to the work often knew. One department knew one part of the problem. A vendor knew another. The technical team saw the delivery risk. The business unit saw the operational failure. The citizens felt the service breakdown. But no one had the full picture early enough to act.

This is why agile must not be treated as a technology trend. For government, agile is a leadership discipline. It is about building institutions that can learn while there is still time to change course.

The Leadership Test

Agile does not ask senior leaders to abandon control. It asks them to practise a better form of it.

Control through clarity. Control through priorities. Control through evidence. Control through shorter feedback loops. Control through faster decisions. Control through visible value.

The old model says: Come back when everything is fully defined. The agile model says: Show me what we know, what we have learned, what users are telling us, and what decision is needed next.

That is a different leadership posture. It requires humility. It requires courage. It requires discipline.

Because the hardest part of agile in government is not teaching teams to work in sprints. The hardest part is teaching institutions to learn before they fail.

A ministry can run stand-ups and still be waterfall. An agency can have a backlog and still avoid hard decisions. A programme can report velocity and still deliver little value. A transformation can use agile language and still protect the very behaviours that caused previous projects to fail.

The future of public-sector transformation in the Caribbean will not be decided by who adopts agile language fastest. It will be decided by who has the discipline to change how decisions are made.

Because agile does not fail in government. Governance fails agile.

The Path Is Not Without Precedent

In 2012, the FBI — one of the most bureaucratically entrenched institutions in the United States — completed a full agile transformation of its case management system after a decade of failed waterfall attempts had consumed hundreds of millions of dollars. The project, called Sentinel, had been designed to prevent another September 11: to connect the intelligence dots that siloed, paper-based systems had failed to join in the days before the 2001 attacks. At its worst, the programme was haemorrhaging money, a year behind schedule, with new defects appearing faster than old ones were fixed. A lean team took it back in-house, applied agile principles, and delivered.

The turnaround, documented by Scrum co-founder Jeff Sutherland in ***Scrum: The Art of Doing Twice the Work in Half the Time***, was not the result of better technology or more funding. It came from a leadership decision — conscious, uncomfortable, and institutionally difficult — to accept uncertainty as a condition of the work rather than a sign of management failure.

That is ultimately what agile transformation in government asks of Caribbean leaders. Not a methodology. A disposition. To learn that story in full, and to understand the framework behind it, Sutherland’s book is essential reading for any leader serious about institutional transformation.

The conditions that nearly broke Sentinel exist, in some form, in every government in this region. Navigating them requires more than a framework. It requires experienced leadership — someone who has been in the room where these decisions are made, who understands both the discipline and the politics of transformation, and who can build the conditions for agile to actually produce value.

If you are ready to have that conversation, I am ready to lead it.