Agile scrum with non-software development activities
I work in a large organization which has been going for many years in a vertical with very strong government regulation.
They have recently started adding agile/scrum for IT infrastructure projects. There is no software development involved.
A turn-key solution will be designed and implemented by the vendor.
Documentation is unavoidable in this organization and nothing can be implemented without approved documents because of the strong change control.
There is a waterfall of documents which get more detailed from one to the next. All need to be approved by internal service owners before any production implementation can happen.
It takes months of work before a MVP (Minimum Viable Product) sees the light of day.
It’s beyond me why anyone in the organization thought scrum/agile could work under these circumstance.
In googling around I can’t find any examples of agile/scrum for anything but software development. Any examples of such & or comments related to the above would be much appreciated.
Scrum is not restricted to software development, and the Scrum Guide was updated in 2017 to include this section:
Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
- Research and identify viable markets, technologies, and product capabilities;
- Develop products and enhancements;
- Release products and enhancements, as frequently as many times per day;
- Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
- Sustain and renew products.
However, the problems you describe are not specific to non-software products. This sounds like a lot of software companies that think they want agility.
What is the reason for choosing Scrum?
Does this organization want the transparency, short feedback loops, and invitation of difficult truths that Scrum can provide? If not, then pretending to Scrum might just invite a load of pain with little reward.
It’s beyond me why anyone in the organization thought scrum/agile could work under these circumstance.
It might be charitable to assume that there is complexity involved, and that managers genuinely wish to bring it under control by means of an empirical process. If so, it might be worth finding out who is sponsoring the deep enterprise change which will be needed.
Then again it is perhaps more likely that an agile way-of-working is being appealed to as a magic bullet, with a view to reconciling fixed time, cost, and scope projections which are hopelessly at variance with each other.