Yes. And no. It depends on how you define agile.
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 of small batches still works. The question is – what’s my batch? What will deliver value immediately?
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 one type of batch would deliver information regarding those stories and epics, based on test results. Another batch might answer important questions about the software, such as “how does the system perform under load?”. See more at “Lean in the Test Lab 2013”.
- Pharmaceutical research. The fundamental batch here could be a testable hypothesis whose results will help drive further development.
Specific agile methods such as Scrum are designed to work with batches of software – user stories and epics. Some agile practices are effective with batches of any kind of work, and some are effective only if the work is very similar to software work. If you understand why the practice works, it’s easier to see whether it will work with a different type of batch.