How to use agile methodology for Infrastructure projects where the Scope is known upfront?

Project examples

  1. Data Center migration/relocation
  2. SAN Migration
  3. For Cisco's Telepresence Solution
  4. Telephony Projects

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?

  • There's insufficient information to answer your question as written. For example, where's your WBS for the data center migration? Almost anything can be an agile project if structured that way.
    – Todd A. Jacobs
    Commented Dec 16, 2017 at 16:15
  • Short answer is yes, of course. too many details missing. Commented Dec 17, 2017 at 13:05
  • I posted my opinions on this one here: linkedin.com/pulse/…
    – SBWorks
    Commented Dec 19, 2017 at 3:09
  • 1
    By saying that the scope is known you are implying that the implementation is known. If this is the case, you have no need to pivot, adapt, or learn. You may still gain benefits from iterative value delivery, but that's it. You've driven out all possible risk. If that is the case, sure, the adaptive approach of agile won't get you anything and will cost you more, but never in my career have I seen an infrastructure project like this, so I'm apprehensive of the premise.
    – Daniel
    Commented Dec 19, 2017 at 18:33
  • Agile values and practices can help any project, but support queues and non-iterative work aren’t natural fits. What problems are you actually trying to solve with your selected framework? I do agile infrastructure projects all the time, but I’m optimizing for scope, transparency, and tight feedback loops.
    – Todd A. Jacobs
    Commented Jan 23, 2019 at 6:25

3 Answers 3


Agile/Scrum is not suitable for predictable work

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:

  1. Data Center migration/relocation
  2. SAN Migration
  3. For Cisco's Telepresence Solution
  4. 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...

  • whether the network will be capable of supporting the new demand?
  • this new demand will be stable across different offices?
  • in case you need to change your network provider in a given location, are you aware of how to proceed with it?

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.