Should IT Go Agile? The Pros And Cons - InformationWeek
IoT
IoT
Infrastructure // PC & Servers
News
10/6/2015
07:05 AM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

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?
Previous
1 of 10
Next

(Image: OpenClipartVectors via Pixabay)

(Image: OpenClipartVectors via Pixabay)

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:

  1. Planning
  2. Design
  3. Testing
  4. Implementation
  5. 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.

Andrew has well over a decade of enterprise networking under his belt through his consulting practice, which specializes in enterprise network architectures and datacenter build-outs and prior experience at organizations such as State Farm Insurance, United Airlines and the ... View Full Bio

Previous
1 of 10
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mdepollo.ithaka
50%
50%
mdepollo.ithaka,
User Rank: Apprentice
10/6/2015 | 4:48:34 PM
It's and Art more than a Science
We apply agile techniques to infrastructure projects within our organization as a means to accomplish a great deal of work that must also be done right the first time. It's the only way to eliminate a backlog of technical debt.

 

The thing that is different about using Agile within Infrastructure is where you focus your agility within the process of implementation.

 

To be fair..  we actually blend 'waterfall' with 'agile'... and with it we are capable of getting projects started sooner, and completed faster simply by using an agile approach to the 'planning, design, and testing' phases so that 'implementation' goes off without a hitch, and 'maintenance' (or residual effort) is kept to a minimum. Does that mean we Scrum, use swim-lanes and sticky notes, and hold daily stand-ups... no. But we could... if the scale of the project warranted it.

 

The biggest complaint about 'waterfall' is the analysis-paralysis trap that can occur in the planning phase.

 

We approach elements of the 'planning, design, and testing' as 'stories'.

We iterate on the stories till we have a 'good enough, let's get started' understanding and all involved can be 'leveled'.

Along the way, some of these items can get polished and perfected, if needed.

 

Craft-fully applying an agile mind-set to the planning is the trick. Break the planning phase down into 'individual stories'. Focus on 'chunks' of the planning at a time. Iterate on those chunks to the point that they offer enough value to 'the project'; and then move on to the next chunk or parse out different chunks to separate 'teams'.  

 

The design and testing phase can be done in a similar fashion. With the objective that the 'implementation' is executed timely, includes safe fall-backs, and the regiment for execution be well choreographed; use an iterative approach to produce the 'things' you need for implementation day.

 

Where is the low hanging fruit, and where is the tough meat? Knock out the easy, while iterating on the hard.  


Is there a bit of 80% (planning) / 20% (execution).. yeah.. so apply Agile to the 80%.

 

So what is the trick...? Clear, obtainable goals and objectives... what are the problem(s) to be solved? This is what the Product Owner/Manager does in Software Development. For Infrastructure, this is the value the organization, department, or a given project. 
TerryB
50%
50%
TerryB,
User Rank: Ninja
10/6/2015 | 1:17:23 PM
Right On
As developer, been a big fan of Agile long before it had methodology formed around it. "Rapid Prototyping" was the beginning, using that mindset when I started back in the mid Eighties.

But your conclusion is correct from my viewpoint, very few infrastructure projects make any sense for that methodology. Too much fixed/purchased cost is involved in the hardware side and a system is rarely usable without everything included the end users need.

For example, could you really deploy new Win 10 desktops with VDI without including all the applications the users need? And making sure you have a handle on capacity/throughput? As you stated clearly on a slide, scratching your investment and starting over is not an option.
How Enterprises Are Attacking the IT Security Enterprise
How Enterprises Are Attacking the IT Security Enterprise
To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Register for InformationWeek Newsletters
White Papers
Current Issue
Digital Transformation Myths & Truths
Transformation is on every IT organization's to-do list, but effectively transforming IT means a major shift in technology as well as business models and culture. In this IT Trend Report, we examine some of the misconceptions of digital transformation and look at steps you can take to succeed technically and culturally.
Video
Slideshows
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll