Is it possible to use agile methods for large IT infrastructure projects?

I am working on a large project where the development team uses agile methods, while the infrastructure (which is where I am involved) is being established using waterfall methods. We recently debated whether agile could be used throughout the project, but failed to reach a conclusion. If anyone has practical experience, what were the pros and cons of the approach?

  • 1
    See Chuck Cobb's answer to [the question on uncertainty][1]. [1]: pm.stackexchange.com/questions/4338/… Jan 24, 2012 at 4:21
  • Good reference - I like the comment that it contains, which talks about about macro and micro planning. This could be an interesting way to develop a more flexible approach to infrastructure project management than I have seen to date.
    – Iain9688
    Jan 24, 2012 at 19:14
  • How this will help full in mobile application development? i mean is there any document or startup process document?
    – fasttrack
    Mar 20, 2012 at 10:23

9 Answers 9


Agile is a new term on decades old concepts. I've blogged on this very topic recently with a blog titled "Gorillas can be Agile with any project" (PMI recently reposted this on their Agile Community of Practice).

My blog isn't just an opinion. I used agile principles at the program level in a hardware company that had both Japanese business practices and a legacy of IBM practices. I helped the team increase products shipped per quarter by orders of magnitude. All I did was focus on agile values and worked to make the organization a team.

And when every anyone says to me "Agile doesn't work in hardware companies."

I just respond with one word...


  • 2
    Thanks for this. The blog is a timely reminder that Agile is a term that is often (incorrectly) assumed to mean "Scrum", and on that basis, it seems that there is every reason to look at Agile for infrastructure. All that remains is to understand the details of what will work and what wont... and that's where the fun will start.
    – Iain9688
    Jan 26, 2012 at 20:56
  • Joel, any chance you're around and have a link to that blog? I'd like to read it.
    – RubberDuck
    May 24, 2016 at 23:48
  • Blog link should be in my profile. Cheers. May 26, 2016 at 4:30

The big difference between software projects and infrastructure is lead time. For example if you need to build a new datacenter it might take years. Even something as simple as ordering disk drives right now may be long lead because of the floods in Thailand.

Agile is great, and if you think about it, that is what using cloud servers is all about. For a firm that operates primarily on hosted cloud servers, then I see no reason why agile methods would not work. On the other hand if you keep your infrastructure in house then you need to insure that you do longer term planning to accommodate lead times.

  • There could be lot of cross-vendor coordination issues, too. You are likely to have multiple vendors delivering major pieces in a infrastructure project that might be more rare in software development project (i.e. the SAN equipment can't be delivered and tested without power, cabling must be done before equipment delivery, etc.)
    – SBWorks
    Apr 3, 2012 at 10:38

I have successfully used a blend of Agile and PRINCE2 in large,complex IT infrastructure and construction projects, with a budget of up to $140M and a total team of 167 persons. If you accept that Agile is an adaptive framework, ie not a fixed or prescriptive process, then you should be able to implement it in any type of project. It is regrettable that our mindset has been conditioned to believe that Agile can only succeed in software development projects, with the project team being accommodated in one room for most of the project's duration. The reality is that today's project teams could be based in disparate locations around the world ... so why not use a virtual Kanban board, for example? Come on, open up your minds ... be adaptive ... give it an honest and fair try!

  • Hi Sylvia, welcome to PMSE, and thank you for your contributions, just be sure that you address the full question, as on this network each answer posted should answer the question and serve as a reference for others. Can you provide any pros and cons of using that approach in your large IT (and possibly even the construction) project? Thanks, and welcome to PMSE!
    – jmort253
    May 22, 2012 at 8:34

Hardware infrastructure can be implemented in phases.

Estimate how the requirements will grow over time and see if you the infrastructure you require can be implemented in phases. E.g. Start with 10 servers, add 10 more and etc.

This can be managed using an iterative life cycle.

If the phases are short enough then you can use an agile life cycle (agile is based on shorter iterations than the original UP).

Software infrastructure, as any software, can be developed using an agile life cycle. However, it is important to keep the end vision intact, so that the software will be able to function as an infrastructure.


Add to the lead times, last minute changes to architecture can be quite costly compared to either software projects or Toyota. Most internal IT organisations do not/cannot have a warehouse that is always full of parts. In Toyota (even if they do have inventory that comes in Just In Time like Boeing) they become part of a finished product that goes off the factory.

Data Centers can go easy on this as the equipment can be re-used for another project/customer easily.

  • +1 Good point on how the cycles can be shortened by "pooling" the unused resources of the data center. Apr 3, 2012 at 9:21

Agile, specifically scrum is good for non deterministic projects where the requirements can change a lot over the course of the project. For Example Software Development projects. It can be used for deterministic project e.g. IT Infrastructure projects but alternatives like Kanban are more suitable for deterministic projects.


I am on a back-end service team and we are using Agile the whole time. The key to this is to separate work status from agile process and to select an appropriate sprint period. Know your team's velocity and pace, pick a sprint of two or three weeks duration. If you get familiar with Agile, Scrum can be applied to any team.

The only difference is the deliverable may vary and you as a manager need to define what is 'done'. Not Surprisingly, a researcher wrote an article on how to apply Scrum to a team of researchers.


Do not limit your capacity with your imagination. Good Luck.


Agile for infrastructure

The triumph of Agile over traditional waterfall in software development is it's focus on product delivery. Being able to constantly get assurance and modified requests in its iteration process has proven to produce 'true-to-request' features in end products.

Yet in infrastructure the hurdle is its value-chain. It's more long-tail than traditional SDLC in that it has setup requirements (value-chain) to facilitate deliverables.

Neither is it wholly credible to argue agile for infrastructure based mainly on Cloud computing. As cloud computing is essentially just migration - the tail end of most infrastructure project. To properly consider agile for infrastructure is not just a change of mindset but a need to integrate forward scheduling, so that the window of 'release' or delivery should be planned & iterated in phases.

In another logical approach if agile can work in construction then it should be able to apply in traditional infrastructure (yes the bare metal) set-up of a data center. Ideally, each phasing is a program of relating deliverables, think WBS (ie Servers: Conception through design - procurement - construction - construction phasing), the iteration is based on scheduling time frames & collaborative working on all the moving parts then agile can work.

Kaban is the most favored as its open-ended. I, in summary, would consider the Wagile (Waterfall & Agile) framework with Kaban equally suitable.


As Agile is more customer-focused, you have to work very closely with customers for infrastructure delivery.

I've used the Agile thinking for large server deployments in the past, working with the customer to deliver capacity in phases. For example, out of 3000 servers, setting up the expectation to have 100 every 2 days ready to go in production. I had the liberty to store at least 500 servers on-site, network gear and cables stocked.

This can work if all stakeholders are on the same page and with Agile hats on. For example, the supplier has to ship on time to have the stock ready for deployments.

The best thing is, if you set the right expectations for your customer, you can change the stock keeping unit (SKU) in the middle of deployment and you will have the option to change the order with the supplier accordingly.

But, as I said, all parties should be onboarded to the idea. Going "Could First ;)" is a way to go. When you need it, where you need it, pay what you use, turn it off and save money.

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.