Nogility

The Agony and the Ecstasy

When, in the course of human events, it becomes necessary and prudent for the CIO to advance a strategy for reducing the business burden of the black hole of cost centers that is corporate IT, few panaceas erupt with greater fervor than that one, magic cure-all known as Agility. While it may disrupt things and cause untold suffering it ultimately delivers the El Dorado of IT value.

Becoming Agile will solve everything that is bad about IT. The rising of the seas will slow. Everyone will be equal. Flowers will bloom. It is an accepted fact that tossing “Agile” about, regardless of and in spite of the definition’s ambiguity, will grant you capital funds and at least 6 months of project time. Status reports? Never worry. Simply put “Increasing agility” or “Adopting agile processes” on that bad boy and you’ll be all set for another week or so.

Agility is the industry’s Holy Grail. And it is almost as meaningless and elusive. Here’s why.

No Thank You

Corporate IT isn’t really interested in Agility. To be sure, they’re interested in the results promised by being ‘agile’. The lure of the twin sirens of IT cost reduction and increased IT responsiveness appeal to those for whom such ambiguous notions are key to their definition of success. If you deal in 500,000ft level concepts, the extreme abstraction is attractive. What’s that you say? IT costs too much? No worries, Business Stakeholder. We have a plan in place to reduce our cost while increasing our ability to execute in shortened timeframes. What is that plan? Well, we’re going to become agile. Need more detail? I’ll get back to you on that.

However, as with Congressional budget negotiations, the devil is in the detail. And in the case of Corporate IT, that detail is found right under the surface and exposed without much effort. Large technology organizations don’t simply become agile. They’re either agile or not. If they’re not, the path to being so is via change, often radical change at that. We’re talking about organizational change and procedural change. In short, we’re talking about people and process change. The most obstinate and intractable types of changes to foster. Technology has little to do with it. Have you ever seen an organization become ‘agile’ by implementing tools like, say, SharePoint? Has that awesome thing your development org published to Prod been the harbinger of total efficiency? No. Tools don’t make you agile. Custom in-house dev doesn’t make you agile. In many cases these things merely mask the non-agile rubbish that persists under the surface because of an unwillingness (or inability) to address people and process. Companies end up spending hundreds of thousands or even millions while making things just that much worse.

When it really comes down to it, technology organizations are actually actively rejecting agility, despite their pronouncements, because the effort required to become agile involves more change than they are willing or able to make. They are, in effect, saying “No thanks, we prefer the status quo ante” and turn to tinkering around the edges with new social tools and application development approaches. They create a new program or department to handle the tinkering, implement some part of some methodology (ITIL and Six Sigma come to mind) and call it ‘change’. The only positive thing that can be said about this ‘change’ is that at least they don’t use the word ‘hope’ in conjunction with it.

In other words, in practice, IT’s actions demonstrate a preference for maintenance of the status quo, for no change and for non-responsiveness. They prefer no-gility over agility.

It’s the Psychology, Stupid

There are myriad reasons for the inability or unwillingness to address people and process. First and foremost, technologists are typically tool oriented. That is, there is an institutional disregard for people and process. Tools are predictable. Technologists are stereotypically inclined to a preference for logic and predictable results. This reality is something I’ve discussed previously. Not that there’s anything intrinsically wrong with it. This is, after all, who they are. But one would expect their leadership to be much more predisposed to dealing with people and process, especially if they are in fact floating at that abstract, conceptual level. Tools don’t decisively impact abstract, conceptual thinking and decision making to nearly the same degree as people or processes do.

So if we shouldn’t expect, as a matter of course, people and process thinking at the 5000ft level due to simple psychology, how on earth can IT ‘become’ agile? How can IT promise agility when it is singularly ill-equipped to think in terms of the changes necessary to bring it about? Your average technologist isn’t usually skilled in the arts of organizational change, strategic realignment and procedural redesign. Why, then, should anyone expect this change to be bottom-up? Can a CIO Vision and supporting strategies alone make IT agile in a top-down fashion?

The Nogile Enterprise

Of course, companies aren’t guided by psychology alone, no matter how ingrained or powerful human nature may be. To the cynic (that would be me), the cost/profit motivation is the overriding factor influencing these types of strategic decisions. If cost and or revenue is not the motivating factor, I defy anyone to give me a plausible alternative rationale for major corporate IT efforts. If one accepts that ‘becoming agile’ is first and foremost a strategic decision involving organizational and procedural changes, regardless of how many tactical decisions may flow from it to the lower echelons, then the question becomes, who exactly is capable of initiating that change? Doesn’t it fall to senior IT management? If they are using ‘agile’ as a promised panacea and justification for massive programs to effect efficiency, is it not incumbent upon them to be willing to make the needed changes and not punt to a peer or kick the can down the proverbial road?

In the Nogile Enterprise, projects may exist with the intent of enabling agility but they end up delivering the exact opposite. The folks involved in these projects, the technologists and project managers (with ideally some business stakeholders keeping watch) are ill-equipped, un-empowered and disinclined to institute actual changes required of a business that is responsive and quick. “Enterprise” thought takes over. Concern becomes paramount for lifecycle, governance, forms, reports, status updates, politics, personalities, conflict avoidance. What were supposed to be rapid implementations elongate into protracted hassles. That cloud project that was to revolutionize delivery of IT services turns into a 3 year project with a cast of thousands and Deloitte to boot.

This is to be expected in a large enterprise that has grown large and maintains large by favoring bold PowerPoint over bold practice. Practicality, pragmatism and reality swamps any spark of idealism that may have existed. Any thought that ‘this time it is different’ is quickly subsumed beneath ‘this is the way we do things around here’ and ‘this is what can reasonably be accomplished’. The energy that infuses a start-up (a truly agile enterprise) is sorely missing and is smothered by hordes of Accenture experts. It is, in fact, actively discouraged: “You can’t just go and do such and such without consulting infrastructure (and development and legal and marketing and sales and PMO and…. ).”  In other words, the cynic? #Winning.

Nogility rewards following procedure and consensus building over change. Nogility is about bold pronouncement and grand plans followed by line toeing. Nogility exists where up and coming so-and-so, who is on the fast track to upper management is soon ‘pursuing other opportunities’  because his or her plans for change ran up against institutional political reality. Nogility is about casting ossified fiefdom building in the light of bold responsiveness for at least a few budgetary cycles. Nogility is about presenting total failure to change as a bold experiment or proof of concept, declaring success at the exact moment that complete failure is becoming readily apparent to stakeholders. Nogility is a program for which change is the goal but for which meaningless tweaking over the space of dozens of months is the ultimate triumph. Insofar as you are in an industry who’s revenue and profits can cover such incompetence, bully for you. Meanwhile, Google is eating your lunch while you’re concerned about the next tollgate.

No wonder consultants have such a perpetually rich prospect field. It turns out that many companies excel at spending millions on change when in actuality they are incapable of change for reasons beyond the ability of consultants to affect. These are the enterprises that excel at nogility.

Tilting at Windmills

It often seems to me, when I commit to paper, that I’m being absurdly simplistic. I read what I wrote and I say, “Meh. Don’t be ridiculous. That’s just how it is.” The problem I have is that when I say to myself “This is just how things are,” the idealist in me, the ivory tower architect, comes back and says “This isn’t how it ought to be!” And naturally, corporate America eats that ivory tower architect for lunch on a daily basis. Where I come into honest self-conflict is this: we’re addressing the wrong problem. The solutions I encounter on a daily basis are tool related. They are solutions but not solutions. They are large scale IT efforts to institute change using millions in funding for tools and project managers and consultants. But technology doesn’t make change. Technology can automate change. Technology can facilitate change. But change is an organic thing. It is a natural, animalistic thing. It is a human thing. And no matter how much money we spend on research and junkets and boondoggles and proof of concepts and minimally viable products and vendor supplied tooling, if we are unwilling or unable to change people and the processes they follow, we are absolutely doomed to failure. Agility is a business problem, not an IT problem. Addressing it with technical solutions is a sure path to nogility.