Most attempts to extend agile frameworks beyond technology teams produce one of two outcomes. The first is a genuine shift in how the team works — faster decisions, visible priorities, consistent output against a stated goal. The second is a performance: sprint boards that nobody updates, fortnightly showcases that feel like status meetings with a different name, and a vocabulary of agility sitting on top of unchanged ways of working. Both outcomes are common. The difference between them is not the domain — finance, HR, policy, or procurement — and it is not the capability of the people involved. It is what was actually carried across when the framework moved.
The failure mode is routinely attributed to agile being inherently suited to technology work. That explanation is wrong, and it matters that it is wrong. Organisations that believe that agile is only for ‘technology’ stop before they ask the serious question: how can we change the way we work to take full advantage of frameworks that optimise for flow of value, over task management?
In Brief
- The Scrum framework — accountabilities, events, and artifacts — transfers intact to non-IT domains; the software delivery tooling that surrounds it does not.
- Scrum’s accountabilities, events, and artifacts have been applied intact in procurement, marketing, and policy contexts — and produced measurable results.
- The selection criterion is work type, not organisational domain: iterative work suits Scrum; flow-based work suits Kanban.
- Executives who rename the framework’s labels to reduce cultural friction remove the accountability structures those labels were built to hold.
- Framework selection — iterative or flow-based — is an executive decision that must be made explicitly before implementation begins.
Framework and tooling are different things
Scrum, as defined in the 2020 Scrum Guide, is a lightweight framework built on three accountabilities, five events, and three artifacts — each with a specific commitment attached to it (Schwaber & Sutherland, 2020). That is the entirety of the framework. The accountability structure — a Product Owner answerable for the value the work produces, a Scrum Master accountable for the team’s use and understanding of the framework, and Developers who own the plan for achieving each Sprint Goal — has no technology-specific assumptions embedded in it. The five events create the inspection and adaptation cycle that makes empirical work possible in any context. The three artifacts make work visible and create the conditions for honest progress assessment. None of this requires software.
What surrounds Scrum in most organisations is a separate layer: velocity charts, burndown graphs, story points, and other estimation and reporting formats that software delivery teams developed to manage their specific uncertainty profile — high requirement ambiguity, fast feedback from working code, output that decomposes into comparable units of complexity. This layer is not Scrum. It is what Scrum tends to look like when software delivery teams use it, in a context that warranted those particular tools. When this layer travels without the framework beneath it, the result is the appearance of agile practice without the mechanism that produces agile outcomes.
The confusion persists because the tooling layer is visible and the framework layer is not. A sprint board, a two-week cadence, a team reporting velocity — these are the external signals that an organisation is doing agile. They are easy to identify and easy to replicate. The accountability structure is harder to see from the outside: it lives in the authority a Product Owner actually holds to redirect work mid-cycle, in the clarity of a Sprint Goal, in the discipline of a Daily Scrum that inspects progress toward a goal rather than reporting status upward. These are structural conditions, not visual ones, and they are the first things softened when a framework moves into a domain where its language feels unfamiliar.
The framework works outside technology
When practitioners rename the Scrum Master a “team facilitator” to reduce cultural friction, or the Sprint Review a “fortnightly showcase” to make it feel less like IT, the instinct is to read this as reasonable adaptation. What is actually happening is that the accountability schema embedded in those terms is being removed. “Scrum Master” carries specific meaning — what the accountability includes, what it excludes, what holding someone to it looks like. “Team facilitator” carries none of that. The new label gets filled with whatever the existing culture suggests, which is almost always a version of whatever management role was already there.
The framework layer has been applied intact — by name and in full — in contexts well outside technology, and has produced measurable results. At the Australian Competition and Consumer Commission, Scrum’s accountabilities, events, and artifacts provided the structural backbone for a government procurement and legal contracting engagement. Sprint Goals replaced the Statement of Work for each delivery cycle. The Product Backlog served as an evolving artefact carrying scope forward without triggering formal contract variations. A vendor engagement forecast to take three months took three weeks; five months of delivery time was recovered across the program.
At New York marketing services firm, Scrum became the full operating model across sales, account management, strategy, and delivery — with a shared Definition of Done across all teams and the CEO moving from approval queues to active Sprint governance. During COVID-19 response coordination at the Department of Industry, a Scrum Master was appointed to an Executive Action Team drawing on staff from policy, property, people, and communications. The Daily Scrum set the plan for each 24-hour cycle; new policy frameworks were developed and communicated across the division within the first week. In each case, the accountabilities were named as accountabilities. The events were run as events. What was left behind was the tooling — because it had no meaning outside the conditions it was designed for.
Framework choice
The correct selection question is not whether agile works in a given business function. It is what the work in that function actually is. Iterative work — where a team produces discrete outputs against an ordered set of priorities, a stakeholder can inspect each output and redirect based on what they find, and the solution space benefits from short feedback loops — suits Scrum. A procurement team developing a contracting model, a marketing team building a campaign pipeline, a policy team working through regulatory complexity: all of these can be structured as iterative work, and Scrum’s accountability structure holds in each.
Flow-based work is different in kind. It arrives continuously, has variable cycle times, and does not decompose cleanly into bounded Sprint increments. HR policy administration, regulatory processing, and sequential document coordination across multiple branches fit this profile. For these teams, Kanban — which makes flow visible, limits work in progress, and optimises for cycle time — tends to be the more appropriate choice. Sport Australia’s HR team used Kanban to move a complete policy suite from a 12-month backlog to a three-month delivery. The Department of Industry coordinated twelve branches through a six-week incoming government brief process using Kanban, cutting the cycle time per pass from weeks to days (McKinsey & Company, 2020).
What compounds when this selection is made implicitly — when implementation drifts toward renamed meetings and adapted vocabulary rather than a deliberate framework decision — is the cost of the next attempt. After two or three iterations of compliance theater, honest assessment of whether the framework was ever actually tried becomes difficult. What remains is a set of practices that look like agile and perform like what came before, and a leadership conclusion that the approach simply does not apply to their context. That conclusion tends to persist. And because it was never grounded in a genuine implementation, it is almost impossible to test or reverse.
What the executive controls
The selection decision belongs at the executive level, made explicitly before implementation begins — not discovered by the teams through trial and error after the framework has already been softened beyond recognition. Is the work iterative or flow-based? If it is iterative and Scrum is chosen, the second question is whether it will be implemented with its accountability structure intact. The 2020 Scrum Guide is direct on this point: implementing only parts of Scrum produces results that may vary, often diminishing the benefits of the framework itself (Schwaber & Sutherland, 2020). Accountabilities are named as accountabilities. Events run as events. The tooling layer — velocity charts, burndown graphs, estimation formats — is left behind deliberately, not because it is always inappropriate, but because in a non-technology context it has no signal value and its presence draws attention toward the appearance of agile practice rather than the substance of it.
An executive who names the framework and holds to it gives their teams something real to organise around; one who softens the language to reduce friction removes the accountability structure the framework was built to create.
References
Boston Consulting Group. (2024). True enterprise agility lies beyond the agile hype. BCG. https://www.bcg.com/publications/2024/true-enterprise-agility-lies-beyond-agile-hype
McKinsey & Company. (2020). An operating model for the next normal: Lessons from agile organizations. McKinsey & Company.
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Scrum.org. https://scrumguides.org/scrum-guide.html
