Agile has escaped the engineering floor. Marketing departments run sprints. HR teams hold retrospectives. Operations groups build kanban boards for work that has nothing to do with code. Consultants sell agility as a general operating system for the modern organization, and executives, watching software teams ship faster, want the same for everyone else.
Some of this transfer is real value and some of it is superstition. The difference depends entirely on what actually crosses the border. When the principles travel, agility outside software can work. When only the ceremonies travel, the result is a marketing team pretending to be a development team, holding standups about work that does not decompose into user stories and wondering why the meeting feels hollow.
Principles port, practices do not
The reason to expect the principles to travel is that they were never really about software. Palopak and Huang (2024) tested the perceived impact of the twelve principles of the Agile Manifesto on project success across 298 practitioners, and the principles they examined are general management ideas wearing a software label. Deliver value early and often. Welcome changing requirements. Build projects around motivated people and trust them to get on with it. Reflect regularly and adjust. None of that is specific to code. Their finding that principle adherence, rather than mechanical practice, associates with success is precisely what you would want to be true if you were exporting agility to a domain with no compilers in sight.
The practices are a different matter. A daily standup makes sense when work arrives in small interdependent pieces that change hourly and where a blocked colleague can lose a day. Impose the same daily cadence on a legal team drafting a contract or a research group running a three-month study and you have imported a ritual whose original justification does not hold. The practice was a good local answer to software's specific tempo. The principle behind it, coordinate frequently enough to catch problems early, ports anywhere. The fifteen-minute meeting does not.
The general team was there before the specific one
If you doubt that autonomous, fast-adapting teams predate software agility, the self-managing team literature settles it. Magpili and Pazos (2018) reviewed self-managing team performance across manufacturing, services and knowledge work, and framed these teams as a response to turbulent environments, wherever they occur. Their model of nested individual, team and organizational inputs is written in no industry's dialect. It describes what any group needs to coordinate itself under pressure, which is exactly the situation a marketing team in a volatile market or an HR team through a reorganization finds itself in.
That generality is the good news for anyone taking agility beyond engineering. The underlying object, the self-organizing team adapting to change, is not a software artifact. It is a general organizational form, and software merely produced a popular set of rituals for running it.
The self-management competency research extends the same logic. Doblinger (2022), reviewing 84 studies on what individuals need to perform in self-managing teams, describes competencies like self-leadership and interpersonal skill in terms that name no industry. A marketer who can direct her own work and coordinate with peers who hold no authority over her is drawing on the same capabilities as an engineer doing the equivalent. The competencies are portable because the situation is portable, which is another way of saying the transfer can work if the organization builds the capability rather than just borrowing the vocabulary.
The transfer fails the same way scaling fails
The bad news is that non-software agility tends to fail for the same reason large-scale software agility fails, by copying form over substance. Dikert, Paasivaara and Lassenius (2016), reviewing 42 industrial cases, found that success turned on customization, adapting the model to the context, rather than on faithful reproduction of a framework. Their caution that most of the evidence was practitioner experience rather than rigorous study is doubly relevant outside software, where the evidence base is thinner still. A company adopting agile marketing is standing on anecdote layered on anecdote.
The honest move is to customize hard. Ask what problem the software ceremony solved, then ask whether your domain has that problem. If your work does not change hourly, you may not need a daily standup, but you very likely still need frequent coordination in some form. If your deliverables are not user stories, forcing them into that shape adds ceremony without adding clarity. Keep the principle, redesign the practice.
The practical read
Agile outside software is a genuine opportunity and a common trap, and which one you get is decided by what you choose to copy. Take the principles Palopak and Huang (2024) found to matter, deliver early, welcome change, trust motivated people, reflect and adjust. Recognize, with Magpili and Pazos (2018), that the self-organizing team is a general form your domain can legitimately use. And heed Dikert, Paasivaara and Lassenius (2016) on customization, because the framework that worked for a software team was itself customized to software. The organizations that get value from agile beyond engineering are the ones brave enough to leave the ceremonies at the door and carry only the ideas across.
Sources
- Palopak and Huang (2024). Perceived impact of agile principles: Insights from a survey-based study on agile software development project success. Tests the twelve Manifesto principles, which are general management ideas, and finds principle adherence associates with success. https://doi.org/10.1016/j.infsof.2024.107552
- Magpili and Pazos (2018). Self-Managing Team Performance: A Systematic Review of Multilevel Input Factors. Frames self-managing teams as a general response to turbulent environments across industries, not a software-specific form. https://doi.org/10.1177/1046496417710500
- Dikert, Paasivaara and Lassenius (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Finds success depends on customizing the model to context rather than reproducing a framework, and warns the evidence base is largely experiential. https://doi.org/10.1016/j.jss.2016.06.013
- Doblinger (2022). Individual Competencies for Self-Managing Team Performance: A Systematic Literature Review. Describes portable self-leadership and interpersonal competencies that let the self-organizing form work outside its original domain. https://doi.org/10.1177/10464964211041114