Most big companies today are structured and managed like those during the industrial revolution. They may have started small and nimble, but over time, layer upon layer of bureaucracy was piled on. If something bad happened, a rule was instituted so it never happened again. Then a rule was created to deal with another problem. Pretty soon there were hundreds of rules. And worse, job performance was built around how well employees conformed to these rules.
If only burdensome rules were the only problem to unravel in large companies. Dilbert (the sadly funny cartoon strip about life in corporate america) is famous for documenting the common practice of placing managers at every level of the hierarchy, to “do the thinking” for the lower level workers, and to babysit them, because adherence to the status quo was required, and workers couldn’t be trusted not to screw around on the company dime. Inside and between departments, communication is strangled and held hostage, often hoarded, because in this kind of organization, the person with the most information acquires increasing influence and power.
So what’s the bottom line? Employees are disengaged.. .but there’s just one very big problem… in the digital age we now live, the “line workers” (those at the bottom of a companies hierarchy) are now the brains and talent powering new products, services, and revenue streams. If they’re disengaged, burdened by rules, starving for information, and generally left to answer to “old school” managers your company’s future is bleak.
DOES THIS SOUND LIKE YOUR COMPANY?
In a well-intentioned effort to fix the burdensome rules, procedures, and mind-numbing layers of controls in companies, organizations attempted to scale Agile. Agile may already be used in your company’s IT or engineering department. Agile is great for software development, because of its focus on self-managing teams, autonomy and visibility into a prioritized backlog.
We have customers tell us, “We have Agile technology, we have numerous Agile teams, but we haven’t been able to scale. In fact, our Agile COE (Center of Excellence) is in direct conflict with other teams.” What we’ve found is that in an effort to scale Agile, companies created a bunch of accidental adversaries.
You might have had some successful implementations of Agile in your IT department. So you try to implement it with another team, or your business partners, spending potentially millions of dollars, many months or even years of time, hoping that at some point all the Agile-powered teams will just melt into one giant magical Agile Enterprise.
And you thought Agile was going to save your company?
But you’re asking for the wrong thing.
You don’t need Agile teams. You need Enterprise Agility.
The process of scaling Agile seems simple: if Agile works in one department, you just apply it to all your existing teams and departments. But there are two problems:
-
Thinking of Agile as TOOL. Unfortunately in today’s digital age, we often think that if you have a problem, you can buy this NEW SHINY TOOL, install it everywhere and it will solve everything! The new tool ends up being bolted on top of your existing organizational processes, or your product development processes.
-
Forgetting that the company is an ecosystem. Your company is an ecosystem that is dynamic, composed of teams, departments, and businesses, each with a set of unique cultures and informational networks. Ecosystems are not designed; they evolve. Most importantly, the health of the organizational ecosystem affects your company’s success.
And if the ecosystem is unhealthy, it will continue to be unhealthy at any scale.
If you don’t understand your ecosystem and its dynamics, and try to merely scale Agile teams, the results at best will be ineffective. You might end up amplifying existing structural and procedural illnesses. At worst, an Agile implementation can be not only disruptive but catastrophic. Your organization may revolt.
In order to successfully transform your organization into an Agile Enterprise, you need to first understand your company’s ecosystem, and then diagnose its health.
In the next article in this series, we’ll talk about learning to see your company’s ecosystem.
