Clichés are the rotting corpses of insights.

“Agile,” sadly, has become one. It has joined the long parade of business concepts that, like “entrepreneurial,” “professional,” and “proactive,” once meant something, but now just mean “good.”

Let’s resurrect the corpse.

Last week’s column focused on Agile development. This week we’re going to talk about the business as a whole. The questions: What does it mean for an organization to be agile, and what does it take?

What it means isn’t especially complicated. While Wikipedia’s entry on the subject is less than stellar, its definition is as good as any: “Business agility is the ability of a business to adapt rapidly and cost efficiently in response to changes in the business environment.”

There is, inevitably, a complication. As pointed out in KJR from time to time, delayed feedback is destabilizing when delay approaches the speed with which system inputs change.

Call it Agile characteristic #1: Feedback loops need to be much quicker than the speed with which the business environment changes.

Agile characteristic #2 is a superset of AC#1: Fast decision-making.

Yes, this is a cliché. But quick decision-making is by no means automatic.

Look at what slows down decisions in most companies and you’ll find two factors are what pour most of the sand into the gears of progress: Lack of trust, and controls.

Lack of trust leads to overreliance on consensus, as people don’t trust decisions they weren’t involved in making. And as consensus is the slowest way to make decisions, and also isn’t how to make the highest quality decisions, Q.E.D.

Then there are controls — requiring, for example, six signatures to approve a $1,000 expenditure. Why all the signatures? The organization’s trust in an employee’s judgment is pegged to their altitude in the organizational hierarchy.

Not that all controls are a bad idea. You might recall the London Whale — JPMorgan Chase’s trader who lost the company more than $6 billion, violating securities laws as he did so. Requiring a second, and even a third pair of eyes on decisions is just fine. It’s the fourth, fifth, and sixth pairs that slow things to an unnecessary crawl.

Agile businesses prize speed, but speed has the same consequences when it comes to decisions it has when driving a car: The faster you go, the more skillful you have to be so you don’t cause a flaming crash — see “London Whale,” above. So Agile Characteristic #3 is an enormous emphasis on making sure everyone who makes important decisions — which in an agile business is, in the context of their responsibilities, pretty much everyone — is in a position to make them well.

So agile businesses invest heavily in education to make employees experts in their areas of responsibility. They invest heavily in defining and promoting, as Jim Collins put it in Good to Great, a culture of discipline. And, they invest heavily in both a “culture of honest inquiry” and the practices and tools required to support evidence-based decision-making without the desire for evidence slowing decisions down to the point they become destabilizing.

Next … this is Agile Characteristic #4 … agile businesses promote another cultural characteristic: Utter contempt for the organizational chart.

Okay, not really the org chart, but close — for the organizational siloes most org charts turn into. In an agile enterprise, everyone collaborates with anyone who (1) will be useful in pursuing an interesting idea; and (2) is interested in pursuing the idea. And not just individuals. Workgroups and departments show the same behavior.

Which gets us to Agile Characteristic #5. People. Very good people. People who have the expertise, judgment, and attitude required to get things done. Because (drumroll …) …

Agile makes software development a practice rather than a process. In a process, it’s all about following the recipe to deliver repeatable, predictable results. In a process, intelligence resides in the recipe.

In a practice, it’s all about the practitioners. Because by the time a competitor has perfected the processes it needs to compete, the agile business has innovated to the next generation of whatever it is.

Processes and the assembly lines they depend on, physical or virtual, take too long to figure out and perfect.

Skilled employees know how to reach the exalted state of good enough, and how to get there fast enough to stay ahead.

Jimmy Dean should never have recorded “Big Bad John.” His squeaky tenor just doesn’t fit the lyrics — they demand a Johnny Cash baritone.

Still, Dean got some things right — his sausages, for example.

And, he gave us a useful quote: “I can’t change the direction of the wind, but I can adjust my sails to always reach my destination.” It will never make it on despair.com, but that’s okay. Cynicism is more fun, but figuring out how to make things work is what pays the bills.

My last two columns have talked about the direction of the wind (“An imperfect storm,” 2/24/2014 and “More storm warnings,” 3/4/2014) — trends you can’t do much to affect, and do have to respond to:

  • Cloud 3.0 — enterprise-class computing that includes cloud-based applications.
  • Shadow IT — the growing amount of information technology implemented without IT’s involvement.
  • The digital enterprise — a grab-bag; right now its most important elements are smart products, the so-called “internet of things,” and all of the opportunities possible when you put the two together.
  • Income disparity — and the rising demand for luxuries and uniqueness by those on the lucky end of this trend.
  • The rise of business practices over processes — practices being the way to organize how work gets done so as to be able to deliver uniqueness.

Your challenge: Adjusting your sails so IT can at least survive these trends and maybe even enjoy the outcome. Suggestions:

Get the relationship right. I know you’re tired of hearing me rant and rave about moving beyond the supplier/internal-customer relationship model to a fully collaborative alternative. I also know I talk to IT leaders all the time who haven’t made the transition.

It matters in this context because in your brave new world of embracing shadow IT, a collaborative relationship is what will stop shadow IT from become rogue IT.

Automated regression testing. Take this to the limit, and beyond.

Cloud 3.0 means multi-cloud plus inside-the-firewall infrastructure provisioning. Multi-cloud, and especially multiple cloud solutions managed directly by the lines of business, means patch management and version management move outside IT’s control.

With automated regression testing you might be able to persuade the lines of business that IT should test cloud-vendor-induced configuration changes before they’re put into production. Without it, IT will once more be positioning itself as a bottleneck rather than an enabler.

Redefine the “I” in “IT.”

Except for shadow IT, all of these trends mean more work for IT, not less. Even cloud computing doesn’t mean IT has less work to do. You’ll be managing multi-cloud systems. Think monitoring for availability and performance. Think more reliance on your WAN. Think about what restoring from backup now means. Especially, think about integration.

This is the redefinition of “I” — from “information,” which never truly encompassed IT’s responsibilities anyway, to “integration,” which completely describes where IT is essential.

Look, like it or not, sales managers everywhere understood the difference between cloud-based shadow IT and the installed alternative. Installed software meant asking IT to unlock sales reps’ laptops so they could install Act! and asking IT to provide a server so their laptops could synchronize to a shared database.

The Cloud meant buying licenses from Salesforce, doing everything through the browser, and getting the shared database too, all with no IT involvement.

So encourage Shadow IT. Get rid of as much responsibility for the applications portfolio as you can. For individual applications, shadow IT’s drawbacks are diminishing, and this also eliminates the “This application doesn’t do what I need” vs “The specs were wrong” arguments that now dominate many business/IT relationships.

But integrating the applications? Only IT … “Integration Technology” … can make this happen.

Which gets us to enterprise technical architecture management (ETAM). This is a long-running personal favorite, and it’s only going to be more important in the future.

A multi-cloud environment with lots of quasi-independent line-of-business and departmental IT departments adding to the application layer is akin to a bunch of developers adding buildings to a community without building codes or well-designed water purification, electricity-delivery and sewage treatment systems to connect to.

In particular, the ETAM function should choose the company’s integration technology system and define the company’s data integration engineering requirements.

Data integration is what causes the most trouble when it comes to accidental architecture. Without a clean, clear, well-engineered approach, shadow IT will exacerbate the situation exponentially.

Okay, okay. “Polynomially” is more accurate, but who’s counting?

* * *

15 years ago in KJR’s predecessor, InfoWorld’s “IS Survival Guide”: An app dev methodology that looks a lot like Agile, two years before the Agile Manifesto.

Way back in 1996, I recommended viewing yourself as a product, not an employee.

And ten years ago, how to avoid the proximity trap — the tendency to pay more attention to those who have access than to those who have answers.