Should IT Go Agile? The Pros And Cons
Agile methodology has produced faster software development and better outcomes for users. Could it do the same for IT infrastructure projects?
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt08c5025d6f67010b/64cb48cb280e8b70ebd64699/1-intro.png?width=700&auto=webp&quality=80&disable=upscale)
Agile methodology has made a tremendous splash on the software development side of IT -- so much so that many are trying to shoehorn agile development practices into other areas of IT, including infrastructure projects.
Today, infrastructure projects commonly use a traditional waterfall approach. Steps are completed one at a time. Moving onto the next in the sequence rarely happens until the previous one is fully complete. A typical infrastructure project plan would look something like this:
Planning
Design
Testing
Implementation
Maintenance
In a waterfall approach, each step is static, and deviating from the finalized design is highly frowned upon. Many in IT believe that this approach to infrastructure projects increases time-to-delivery and leads to a final product that may not be exactly what the business requires. To many, the answer to these two problems lies in agile methods.
Without getting too deep in the weeds, the Agile Manifesto outlines a lightweight development method. Instead of spending a great deal of time in the planning and development stages, developers begin with an adaptive planning stage, in which general milestones are created that describe where the project should head. The plan builds in plenty of room for flexibility in how to reach those milestones.
[Is your business looking in the right places for products and services? Read 10 Government Innovations Your Business Can Use.]
Once an adaptive plan is in place, the team sets out to build the network, while consistently working with end-users on how to better accommodate their needs. Once built, the agile process bunches the testing and implantation phases into a single step. Last, the concept of continuous improvement is used to reflect on what works today, and what changes are needed to reach the next general milestone. From there, the process starts all over again until the project is complete.
There are some clear advantages to the agile methodology when applied to IT infrastructure projects. At the same time, the nature of infrastructure introduces several disadvantages that are not commonly seen in software development. To help you evaluate your options, we've outlined the pros and cons of agile development for IT infrastructure projects. Once you've reviewed these, let us know if you think that agile has a place in IT infrastructure, or if it should be left strictly for use by software developers. We'll be waiting in the comments section below.
In a traditional waterfall project management approach, infrastructure projects aren't considered ready for production until the project is nearly complete. The result is a fully functioning infrastructure solution that was built from very static requirements that were finalized weeks, months, or even years earlier -- during the planning and design phase. Agile does away with this method, and instead rolls out the base infrastructure solution to end-users as soon as it's ready. Changes and new features are then rolled out incrementally in future deployments. Thus the result is a faster deployment to end-users, as continuous improvements go on simultaneously.
When it comes to flexibility in an IT project, it all boils down to the detail of the initial design -- and how much wiggle room is built in to allow for changes in implementation without harming the key milestones put forward. Allowing for changes in an infrastructure project's implementation process will let the end design morph into a solution that best fits the organization's needs.
There are no static milestones and fixed plans in agile, but that doesn't mean there is nobody shaping the design. Agile introduces the concept of continuous feedback in order to shape the final design. Feedback is provided by the end users who actually use the new infrastructure solution. This feedback is absorbed by the implementation team and then used to make adjustments to the configuration in order to squeeze out extra value for the end-users.
Because agile methodology goes through multiple rollout cycles, it has a better chance of providing exactly what the organization needs at any given point in time. These rollout cycles are designed not only to add new features, but also to allow for adjustments to what has already been deployed. The idea is that the infrastructure is never complete. Instead, it's continuously morphing to meet the changing needs of end-users.
While the idea of multiple, small release cycles sounds like it will get an infrastructure solution in the hands of end users more quickly, this isn't always the case. The simple nature of deploying a new blade server, network switch, or a next-generation firewall requires that the vast majority of setup tasks be completed before everything is even usable. Because infrastructure still deals with physical hardware and connections, it places a limit on the initial release cycle. You may end up with a very long first release cycle, which ends up breaking the agile flow.
Infrastructure projects can become vastly more complicated when using agile because such projects have to deal with the hardware as well as the software. Hardware, with its physical interconnectivity into the rest of the infrastructure, places barriers on how flexible projects can actually be. Unlike projects which deal purely with software, infrastructure projects have a "point of no return" aspect from a hardware standpoint. You can't easily scrap hardware and start over, as you can with software.
The agile process focuses heavily on the concept of cross-functional teams that work very closely together on the success of a project. While that's all well and good, these cross-functional teams are commonly involved from start to finish when dealing with a software development project. This is simply not the case when you are talking about infrastructure projects. In many cases, specialized skills are only needed for a very short period of time, then there is nothing left for a certain team member to do.
To think that these resources will be constantly waiting for your call to swoop in and perform the necessary tasks is far-fetched. It's not like these resources have nothing else on their to-do list. What likely ends up happening is that the project is put on hold until the resource is available. This does not mesh well with the agile philosophy.
The idea behind agile -- and why so many project managers find it useful -- is that the method focuses strictly on adding value. One commonly heard negative is that agile leaves out documentation for the sake of adding new features for end-users. I've personally not seen this. After all, documentation indeed does add value.
Where I have seen agile projects go wrong is in cleaning up old or orphaned configuration settings that linger on systems. While continuous improvement is always great, it becomes hard to justify value in cleaning up old configurations that aren't impacting the user base. Because of this, a buildup of garbage configs occurs. The worst-case scenario here is that the infrastructure becomes so muddled in partial configurations and multiple versions of documentation that the solution becomes difficult to administrate long-term.
Despite the clear benefits in terms of speed and agility found in agile methods, I can think of many IT infrastructure situations where agile simply won't work. With limitations due to hardware, technical resources, implementation requirements, or long-term manageability issues, in many cases agile isn't suitable. Your experiences may vary. Have you tried using agile methodology for infrastructure projects? Do you use it for software development? What are your pros and cons? Tell us in the comments section below.
Despite the clear benefits in terms of speed and agility found in agile methods, I can think of many IT infrastructure situations where agile simply won't work. With limitations due to hardware, technical resources, implementation requirements, or long-term manageability issues, in many cases agile isn't suitable. Your experiences may vary. Have you tried using agile methodology for infrastructure projects? Do you use it for software development? What are your pros and cons? Tell us in the comments section below.
-
About the Author(s)
You May Also Like