Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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...
"Toyota"
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.
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!
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.
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.
http://www.cs.umd.edu/~mwh/papers/score.pdf
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.
