The idea of an event horizon comes from general relativity, but if you’ve ever heard of an event horizon, you probably know it either from black holes or from that weird Laurence Fishburne movie. With black holes, the event horizon is that boundary around a black hole that marks the transition from “you could conceivably still get away with enough force” to “you’d better tell your friends you’ll be late to the bar.” Black holes are always pulling at the things around them, but the event horizon defines the difference between having to deal with a black hole and actually being inside one. Interestingly, from the outside, objects that pass the event horizon seem to disappear completely.
Event horizons are the ultimate black box. They are the universe’s embodiment of that fight or flight moment. You can get in, or you can stay out, but you can’t stay there. In fact, the force required to stay in an event horizon increases to infinity. The longer you try to remain neutral, the harder it becomes until it’s impossible.
When an organization decides to increase their agility, this effort also has an event horizon. Generally, these efforts either originate in management and spread out, or they originate in an implementation team and spread out. The latter is far more common. Management might mandate the agile effort, but the actual transformation begins in an implementation team.
Regardless of where it starts, this effort has a boundary that attempts to suck in everything else around it. Agile transformation efforts are not static. You can’t just take, say, a team of software developers, get them all agiled up, and expect this to have no ramifications for the rest of your organization. What you have done is created a singularity that, given enough time, will draw in the entire organization.
This is actually what you want. This is one of the benefits of truly agile efforts; they can’t stay in their little box. That event horizon is defined by the boundaries of contact between your “agile teams” and the rest of the organization.
Does your project management have distinct, Waterfallish phases? The event horizon will eventually touch that. Do you budget your projects on a cost-based approach where you have to allocate all the money up front? The event horizon will touch that. Are you constantly changing priorities at the top? The event horizon will touch that. Do you have tons of processes solely designed to protect the company from itself? The event horizon will touch that.
In ways you never even intended, the singularity will try to draw all aspects of your company into it, and the event horizon marks that boundary of change. Objects pass into it, and that’s where you have the critical moment of decision: do you allow accounting, management, project management, the executive team, and sales to pass through the event horizon, or do you expend force to keep them outside of it?
The answer to that question says a lot about the ultimate success or failure of an organization trying to be agile.