Your Team Is Agile. Your Steering Committee Isn't.
Much Agile advice is written as if the team works in a vacuum. Daily stand-ups, sprint reviews, backlogs and retrospectives all assume that the people who matter are in the room.
In reality, many project managers run Agile teams inside organisations that still govern projects the traditional way. The steering committee wants a Gantt chart. Finance wants to know what will be delivered for the approved budget. The executive sponsor asks, every month, "What percentage complete are we?"
The team is working in two-week sprints. Leadership is thinking in phases, gates and fixed scope. And the project manager is stuck in the middle, translating between two languages that do not map neatly onto each other.
This is a common challenge in Agile project management, yet it often receives less attention than team-level Agile practices. Understanding why it occurs can help project managers manage the relationship more effectively.
The real problem: you are answering different questions
The clash is rarely about stubbornness. It happens because Agile reporting and traditional governance are designed to answer different questions.
Agile tools such as burndown charts, velocity and sprint goals answer the team's question: Are we delivering value, and how much can we take on next?
A steering committee is asking something else entirely: Will we get what we paid for, by when, and should we keep investing?
When a project manager presents a velocity chart to a steering committee, the committee sees data that does not answer their questions. When the team is asked for a detailed Gantt chart for work that has not yet been refined, they see a reporting requirement that adds little value at that stage.Both sides walk away frustrated, and trust erodes.
The answer is not to abandon Agile, and it is not to force governance to "go Agile" overnight. It is to become a good translator.
Five ways to translate Agile progress for traditional governance
1. Report outcomes, not activity
Executives do not need to know how many story points were completed. They need to know what the business can now do that it could not do last month. Instead of "We completed 42 points in Sprint 6", try "Customers can now track their orders online. This was the first of three priority capabilities for this phase."
2. Replace "percentage complete" with a forecast range
"Percentage complete" assumes the total scope is known and fixed. In Agile work, it usually is not. A more honest and more useful answer is a forecast: "Based on our delivery rate over the last four sprints, the remaining priority features will most likely be ready between mid-March and early April."
A range feels less comfortable at first, but it builds credibility. When you hit it, leadership learns to trust your forecasts. A burn-up chart, which shows both the work completed and the total scope over time, makes this visible at a glance, including when scope has grown.
3. Build a roadmap with honest confidence levels
Governance bodies need a clear forward view, but the level of certainty should reflect how far ahead the work is being planned. Work planned for the next month can be described in detail with high confidence. Work planned for next quarter is a set of intended capabilities with medium confidence. Anything further out is a direction, not a commitment.
This gives the steering committee the long-term view they need, without implying precision that does not yet exist.
4. Bring decisions, not just status
The most valuable thing a steering committee can do for an Agile project is make decisions quickly: trade-offs between scope and time, priority calls between stakeholders, removal of blockers. Frame each report around what you need from them: "We can deliver A and B by June, or A and C. Which matters more to the business?"
This turns the meeting from a status review into a governance tool, which is exactly what it should be.
5. Agree up front on what will trigger a conversation
Traditional governance often relies on detailed baselines to detect problems. In an Agile setting, agree on a few clear signals instead. For example: if the forecast date moves by more than a month, if spending exceeds the planned budget rate by an agreed margin, or if a priority capability is dropped, the sponsor is told immediately. Everyone knows when to escalate, without searching through lengthy reports to find out.
Three mistakes that make it worse
Maintaining two sets of plans. Some project managers keep a detailed Gantt chart for leadership and a separate backlog for the team. The two drift apart within weeks, and the project manager spends more time reconciling documents than managing the project. Build one source of truth and produce different views from it.
Using velocity as a performance measure. Once velocity appears in an executive report, it is easily interpreted as a number that should keep rising. Teams may then inflate their estimates, and the number loses its value as a planning tool. Keep velocity inside the team; report forecasts and outcomes upward.
Hiding bad news behind green status. Agile is meant to make problems visible early. If the report still shows green while the team knows a key feature is in trouble, the governance body loses the one advantage Agile was supposed to give them. Early, honest amber is far better than late red.
The project manager as translator
In many organisations, Agile and traditional governance will coexist for years. Hybrid is not a failure to "do Agile properly". For many South African organisations, it is simply the reality.
The project managers who thrive in this environment are not the ones who know the most Agile terminology. They are the ones who can stand between a delivery team and a boardroom and make each side understand the other.
That is a skill that can be learnt. If you want to build it in a structured way, the University of Pretoria's Agile Project Management short course covers Hybrid approaches, measuring progress and adapting Agile to different organisational contexts, presented face-to-face in Pretoria and online.
