How to use agile methodology for Infrastructure projects where the Scope is known upfront?
Project examples
The scope is not changing, most of the project will run from Runbook.
If not possible, does that mean infrastructure projects are mostly done using Waterfall?
Please see my answer to a similar question earlier.
Agile methodologies and frameworks are better suited where requirements either cannot be stated fully upfront or tend to change often.
As you yourself pointed out:
the scope is not changing, most of the project will run from Runbook
All of your examples are predictive projects:
- Data Center migration/relocation
- SAN Migration
- For Cisco's Telepresence Solution
- Telephony Projects
It is not about whether agile is possible:
If not possible, does that mean infrastructure project mostly done by Waterfall ?
It is a question of which process is best suited. If you can create a WBS (Work Breakdown Structure), identify dependencies, assign resources and get them to follow the plan, Waterfall process is best suited for that type of work.
Is it possible to use agile on projects where scope is known upfront? Yes.
Is it the best approach? Maybe.
It all boils down on how much uncertainty you'll face along the implementation and how much value you can deliver incrementally.
For instance, when setting up a video conf project, do you know...
If all the above is going to be delivered "by the book", then go with waterfall. On the other hand, you may find benefits on the incremental approach agile delivers, as you can setup an initial part of the structure for a few offices while you address the problems on other offices.
Take this with a grain of salt - agile is about incremental deliveries. If there's a hard committment date (due to any external factor, for instance) you may want to stick to the Waterfall that will give you more capacity to cover your part of the project from eventual external dependencies.
Lean Agile Kanban approach is better suited to operations and maintenance than a Scrum approach. A big difference is that Kanban does not have fixed time boxes. Work transitions from a backlog to Work in Progress to Done. The key concept is to limit Work in Progress. This prevents too many concurrent tasks happening at once. Do 2 or three things at a time, not 17 things at a time. Reduce context switching and get each task done quicker.
As an example: The Department of Motor Vehicles has a single entry queue, then 1 WIP for each clerk, then Done. One clerk takes you from your initial request all the way through. Without limiting WIP, each clerk would serve everybody in line at once. Your time in the DMV would be much longer.
