Yes. And no. It depends on which definition of agile you use.
In the broadest sense, agile methods work by splitting your delivery into small batches and working on one batch at a time. The team or organization finishes and delivers a batch before moving on to the next set of work. Each time the team completes a batch, they learn more about the work they’re doing and can move faster on the next batch. As a bonus, each batch can be sold or used as soon as it’s completed, rather than waiting for the entire product.
In fields which are not pure software, the fundamental concept still works. The question is – what’s my batch? What am I trying to move through development quickly?
In some fields, this is pretty obvious. In others, it’s not so obvious.
- IT help desk – your batch is probably incoming requests for help
- Maintenance team – defect fixes and maintenance upgrades
- System test teams – it’s the test suite. Or is it? Does your company make more money if you run more test suites? Probably not. The real product of testing is information. If your system test team receives stories and epics to test, then you should be delivering information regarding those stories and epics, which means your batch is probably testing of a story or epic. See more at “Lean in the Test Lab 2013”.
- Pharmaceutical research. The fundamental batch here is a testable hypothesis whose results will help drive further development.
Specific “agile” methods such as Scrum are designed to work with batches of software. Some agile practices are effective with batches of any kind of work, and some are effective only if the work is very like software. A method founded on agile principles may look quite different in another field. Would that be considered agile? What do you think?