Complaints about IT’s speed aren’t particularly new, but one thing is new—there appears to be a solution. Over the last 15 years, new approaches to service development and delivery have emerged in the technology world. They largely come out of the Silicon Valley startup scene, and they tend to express some variation on agile methodology.

When it comes to speed and responsiveness, it’s not a pretty comparison between Silicon Valley startups and corporate IT. Agile-evangelizing startups are known for developing and improving software and service delivery at breakneck speed, building and iterating huge new technologies seemingly overnight, while IT and its old-school approaches of Waterfall, ITIL and the like can’t seem to produce a minor update to the organization’s email client in less than six months.

The solution sounds simple: IT just needs to adopt the agile methodology, and they will perform as fast and responsive as a startup, right?

Not quite.

First, A Dose of Reality

Before we over-aggrandize the startup world—and pile on IT too much—let’s look at a few simple facts.

Up to 46% of startups utilize agile, but despite big talk about agile’s effectiveness, the startup world is filled with failed technology initiatives. We only see the winners, which creates a survivorship bias that seems to equate “agile” with “technology success.” According to the Startup Genome Report Extra on Premature Scaling—co-authored by faculty members at Berkley and Stanford—92% of startups fail within 3 years. Interestingly 74% of those failures came from premature scaling, aka attempting to grow too fast.

Agile can produce amazing results, but it does not offer a sure route to successful technology development and service delivery—and agile’s ability to produce amazing results seems to diminish as a company grows in size.

As organizations grow, their needs change. What works in the early form often does not make sense in their mature structure. Size matters when it comes to choosing the appropriate methodology to meet an organization’s needs. Even though agile may work effectively for a startup, it often works disastrously within a large corporation.

This point—that different contexts demand different solutions—is the key to understanding why IT can’t just adopt agile… and why there might be good reasons why IT has to operate a little slower than IT’s critics would prefer.

A Corporation Is Not a Startup

Consider a few key contextual differences between a startup and a corporation, and how these impact IT’s ability to effectively adopt agile:

More Projects = More Problems

Agile works best in a startup’s small, focused environment. But corporations are large organizations with complex, diverse technology needs.

The volume of projects also makes agile a challenge to implement in a corporate IT environment. Many startup developers work on one project, while most corporate IT professionals work on 3-5 different projects at any one time… and methodologies that work well when you have one project on your plate often fail when you try to apply them to half a dozen projects.

One example: Agile’s 20-minute standup meeting. Once or twice a day, everyone stops working and gets together to talk through the project, discussing and diffusing potential issues and bottlenecks to their work. This is a great idea when you’re working on one project, but if you’re working on 3-5 projects, and each demands 20-40 minutes out of your day for standup meetings, you lose a huge chunk of your day to meetings. Add in the complications of everyone trying to schedule 3-10 standup meetings a day around everyone else’s 3-10 daily standup meetings, and just one of agile’s core tenets already leaves you little time and attention to actually get your work done when applied in a corporate IT context.

2. 80% Legacy, 20% Projects

Some simple math further complicates agile’s applicability to corporate IT.

Startup

100% Technology Development

Corporation

20% Technology Development

80% Legacy Operations

At best, agile directly applies to only 20% of corporate IT activities. But that 20% of corporate IT technology development does not operate in a vacuum—it has to always work mindfully and in partnership with the 80% of their peers focused on operations. Which means even if a corporate IT group adopts agile methodologies, they are still going to be slowed down by operations’ old-school approach—and for good reason.

As Glenn O’Donnel, an analyst at Forrester, explains to Infoworld:

"Ops has historically been tasked with maintaining website availability, and the challenge with that is the best that you can ever do is 100 percent availability." Avoiding outages prompts the operations team to "become strongly opposed to change," Robbins says.

To protect the infrastructure, IT ops can put in place processes that seem almost draconian, causing developers to complain that these processes slow them down.”

Technology developers within corporate IT always have to be mindful of their peers in operations. They don’t want to be cumbersome, but they have to slow themselves down to maintain corporate IT’s overall technology mandate—nothing, not even new technology development, can interfere with keeping the core systems up and running at all times.

Sven Gerjets at Infoworld sums it up best in his article To make IT ‘agile’, devops is not enough:

“Most large companies are built on legacy technology that tends to be fragile—and agile and fragile mix about as well as oil and water.”

3. IT Can’t “Fail”

Startups accept small service disruptions and the collateral damage created by the break-neck speed of their technology development process. In fact, startups have fully embraced this concept that failures, large and small, are unavoidable, and are often good things. Often startups fail at creating the product they originally set out to create, and simply “pivot” their technology development in a more promising direction, over and over again, until they find something that works for them.

By contrast, corporate IT can’t fail. Operations can’t fail. A project can’t fail to meet is initial performance requirements. IT projects have to do what the business asked them to do—they can’t “pivot” to some new functionality.

Yes, compared to a technology startup, a corporate IT department behaves cautiously. That caution slows everything and everyone down. It leads to using methodologies like ITIL or Waterfall that aren’t known for their speed nor responsiveness. But that caution is also understandable within a corporate context.

In a startup, if something fails there’s often a way to spin the situation into a positive direction.

In corporate IT, when something fails people get fired.

Is Agile Impossible in the Enterprise?

By now, you’re at least doubting the recent argument that IT’s problems with speed and responsiveness can be solved by simply adopting agile methodologies. Agile was developed for, and works best within, a very different context than corporate IT.

Now, everyone agrees IT could work faster, with greater responsiveness, but we aren’t sure swapping a new set of processes and policies—developed within and for a much different context—offers the best opportunity to upgrade an IT organization’s ability to perform. Instead, we’ve seen a much more immediately actionable opportunity to improve the speed, responsiveness, and overall performance of the IT organization lies in the area of the personal productivity and an individual’s project governance behaviors.

Marc J. Schiller has spent more than two decades teaching IT strategy and leadership to the world’s top companies around the globe. Through online courses, speaking engagements and corporate consulting, his company educates IT pros at all levels how to be more effective, influential and successful in their IT careers.