Why Agile and CIOs don't get along

Posted by Sysadmin 4 lyfe on October 22, 2016

Marc J. Schiller wrote an article in CIO Insight titled “Why IT and Agile Don’t Get Along” and it reminded me of the stark contrast I felt moving from a large, slow moving IT organisation to a smaller, Agile web company a bit over twelve months ago. It was filled with the typical Kool-Aid I heard from upper management while at my old organisation and I felt so strongly about how wrong it was, I was compeled to write a rubutal.

Marc makes the mistake of claiming only startups use Agile and they are a completely different business to Corporations. Marc correctly points out that 92% of startups fail in the first 3 years, but many many startups are successful and turn into Corporations.

Marc starts out by quoting Gartner analyst Nathin Wilson as saying:

“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.”

And uses daily standups, in which project teams spend 10-20 minutes a day talking about what they did and what they’re doing next, as an example of this:

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

There’s a simple fix for this, only work on one project at a time. That’s the Agile way; don’t say it won’t work if you’re not doing it right.

The fact that there are many products and teams geographically distributed makes no difference, plenty of companies that practice Agile (including where I work) have the same challenges. In fact standups help solve a lot of these problems, because it allocates time that doesn’t distract everybody for anyone to raise problems and help getting unblocked, instead of trying to work through the problem for hours or days because they can’t turn to someone to ask a question.

Marc then uses Legacy applications as an excuse for why Agile doesn’t fit. He quotes Sven Gerjets at Infoworld as saying

“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.”

This is ignoring that Agile is about more than velocity, it’s about delivering value and improving quality. Claiming “my legacy app is too fragile for Agile” isn’t going to solve the problem of the applications fragility, it’s like a drug addict stating they can’t go to rehab because it’s too hard. Sitting still in IT, refusing to fix what’s clearly broken, is a recipe for failure.

Speaking of failure, my favour quote from Marc is:

By contrast, corporate IT can’t fail. Operations can’t fail. A project can’t fail to meet is (sic) initial performance requirements.

But they do, all the time! How many times have we seen a bank or airline’s IT system go down for hours or days at a time? How many times have we seen a government project fail and blow out costs by billions of dollars? This is CIO kool-aid at its best.

I work in an organisation who has hundreds of employees, thousands of people world wide that rely on our company to put food on the table and processes hundreds of thousands of dollars in transactions a day. Oh and we practice Agile. Corporations can learn from accepting failure, it’s inevitable. Only when we embrace failure can we learn from it. Google talk about it in their book “Site Reliability Engineering”, which I highly recommend reading, and they run the most popular website in the world.

There’s no doubt that Agile is extremely hard to retro-fit into a corporate environment. I wouldn’t know where to begin, but the defeatist attitude that “it won’t work because we’re more important than the companies that do practice Agile” is complete drivel and nonsense. Plenty of successful startups have continued to grow and succeed while still practicing Agile. To Marc’s credit, he at least tries to offer an alternative:

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.

Sounds like micro-managing to me. Corporations have a habit of focussing way too much on individuals and process and not enough on culture. Only when the culture of these organisations change, starting with the CIOs, do they have any hope of improving the speed and performance of IT.