Enterprise Agility in a World of Unknowns
Enterprise Agility in a World of Unknowns
Learn how the Royal Aircraft B.E.2 aircraft was shot down for being too stable in an agile world, and how your company can balance agility and stability for results.
Join the DZone community and get the full member experience.Join For Free
In the last decade or so, technology innovations have been accelerating at an amazing rate. The pace will only increase in the coming years. Some of the innovations of the last 15 years are GPS, Social Networking, Mobile Devices, Mobile broadband, Wearables, Drones, 3-D printing, and many of them causing significant and tectonic shifts in strategies and markets. Think of machine learning, autonomous cars, internet of things, new innovations in batteries and the impact these technologies will have. Mind-boggling.
With full potential of some of these technologies yet to be realized and many other disruptive technologies in the pipeline, the environment in which many businesses operate is going to be highly dynamic. Do you know or can you predict with certainty how these technologies will impact your enterprise or business? Not unless you have a crystal ball. Only those enterprises which can adapt fast to their changing environments have a place in the future. The concept of agility has been around for many years and many enterprises have adopted agile practices primarily within their IT. However, this article will look into how the same concepts can apply to the enterprise itself.
Stability vs. Agility
During the First World War, The Royal Aircraft Establishment (RAE) of the UK Ministry of defense built an aircraft named Royal Aircraft Factory B.E.2. It had an excellent record as a reconnaissance aircraft and a light bomber. It proved very helpful in artillery observation and aerial photography duties. This is due to its design providing a very stable configuration that allowed its crew to devote it’s full attention to reconnaissance duties. This same aircraft was later pressed into service as a fighter with disastrous consequences. This aircraft became a sitting duck due to its stability and the inherent lack of agility. The B.E.2 aircrafts dropped like flies against the more agile German aircrafts.
This happened almost a century ago but we can still learn some lessons from this. Stability and Agility have their places. The trick is often finding the right context and striking a right balance between them.
If your organization is like most of the others, chances are you have "standardized" and very "mature" processes. Did you notice the terms within the quotes? "Standardized" often means that the processes are often applied without any awareness of the changes in the context. The original intent and spirit of the process is lost. Also, process ‘maturity’ might mean the process is perceived to have been more or less set in stone and the process stopped responding to changes in the environment in which it operates. Standardization and maturity are not evil. But only when processes stop responding to the changes in their environment and become less effective or totally irrelevant in the new context, they become issues.
Going to back to B.E.2, this was a highly stable machine that performed extremely well where stability mattered. But when the same machine was deployed in the wrong context, it failed to neutralize or avoid the threats posed by the environment and failed miserably. Having a rigid process that is unaware of it’s situational context is like putting a B.E.2 in the fighter role. The results are obvious. In this age of relentless changes in the context in which businesses operate, organizations can no longer afford to establish a process and then settle with it.
Does this mean you should have single process that is highly agile and that can always adapt to its operating environment? That will be extremity to the other end of the spectrum. In general, organizations might have to define different process models to fit different needs, build a flexible process model, or a set of process models that uses both approaches.
The following illustration shows the various steps on a Flexibility scale. The High Flexibility end indicates a flexible and more generic process model. As a flexible process model is adopted and tailored to specific contexts, they become less flexible and more context specific. The tailored processes should be reviewed for their effectiveness based on their current context and decisions should be made on whether the process needs further adjustment or the context demands an entirely different process model.
Invent vs. Adopt/Adapt
Just like many other capability acquisition decisions (build vs. buy), organizations might have to make the decision to define a new process model, adapt an existing process model, or adopt an already existing industry standard process model. But with the process adoption approach, it is very important that the process is reviewed from your organization’s perspective and tailored to fit your environment. And this process tailoring just may not be a one-time process.
In case your organization develops a new process model, it is important to keep certain process modeling principles in mind. Your process model should align with the nature of the problem domain. In general, processes can be task oriented, deliverable or product oriented, decision oriented or content oriented. The process model should align with this nature of the problem it is trying to solve.
As pointed out earlier, a process that is not actively reviewed and managed according to the changes in its environment can have several negative impacts on your organizations: Inefficiencies, not meeting objectives, and introducing or exaggerating risks. Whether the process reviews and changes should be episodic or continuous depends on the drivers for process change and their potential impacts
Whether you are developing a new process or adopting an existing one, the following Method Engineering Process can be a very helpful approach. As illustrated below, this defines the problem, identifies potential options, makes the Develop, Adopt, Tailor decisions, defines guidelines for its application, tests, and finally gets into a maintenance mode that involves episodic or continuous review and refinement of the process.
The pace of innovation and the changes in technology landscapes leveled the playing field to a large extent in many spheres and lowered the entry barrier for newcomers. The increase in market competition and the resultant speed to market requirements forced many enterprises to look for strategies and processes to survive these changes. Lean process improvement, 2 speed IT, Multi-speed IT, Dev Ops are some of the manifestations of these strategies and process models. As the technology innovation trends continue, we could also expect to see many new strategies and process models evolving as in response to those changes.
An enterprise is only as agile as its processes. Today, most organizations operate in an environment where change is the only constant thing. In this context, Enterprise agility is not a luxury anymore and a must to compete and survive. Build your enterprise agility by starting with your processes.
Organizational Change and Development by Weick and Quinn.
Opinions expressed by DZone contributors are their own.