Why IT and Agile Don’t Get Along
At least once a month, the tech media publishes another op-ed complaining that IT is too slow and cumbersome, and that we must radically alter our approach to produce faster and more responsive service development and delivery.
Complaints about IT’s speed aren’t particularly new, but one thing is new—there appears to be a solution to this issue. 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:
1. More Projects = More Problems
Agile works best in a startup’s small, focused environment. But corporations are large organizations with complex, diverse technology needs.
“Part of the difficulty in becoming agile stems from the sprawling nature of the modern enterprise and the complexity of its products. Today, project teams can include thousands of employees who don’t operate out of the same office, don’t live in the same time zone, aren’t working on the same product component and don’t use the same development practices…”
Wilson went on to argue, “the projects tend to be bigger in corporate IT than in a startup garage,” and that Agile principles can sometimes be applied within the enterprise, but they become harder and harder to implement as project size increases.
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.
To help IT professionals and organizations take advantage of this more immediately actionable opportunity to increase productivity from an individual-focused perspective, we’ve put together a new e-learning course: the Ultimate Guide to IT Productivity. Within it, you will find a system for increasing an IT professional’s productivity that is born out of our 25+ years working directly corporate IT professionals, and remains mindful of the specific issues and opportunities their unique context demands.
