Agility and Stability

 Posted by on Jun 28, 2016  Add comments
Jun 282016
 

The world is in a time of rapid change resulting from the usual culprits:

  • The integrated economies and labor market have created a “flat world.
  • The Internet has reduced friction in the marketplace
  • The accessibility of data has revolutionized target marketing
  • The low cost of processing, storage, and software environments (e.g., Java, Python, R) has made application development efficient, enabling innovation and disruptive technology.

In the past, building business was associated with stability — creating an organization of lasting value that persisted even through a change of management or some market structure change. Running a business in the face of today’s changes, however, alters the nature of business management.

“Agility” is the facility of quick response — the ability to be nimble. In general, to be agile entails the ability to detect changes in your environment as well as the ability to respond quickly and appropriately. Being “agile” (in the traditional sense) is about excelling in a constantly changing environment, much like a serious athlete who masterfully integrates the aspects of balance, speed, strength, coordination, and reaction to the dynamics on the field. Management has two roles in bringing agile behavior to the organization:

  1. Leading organizations that have adopted Agile and DevOps methods
  2. Bringing agility to the overall business or to a function other than software or IT

Management’s unique perspective includes the business needs, the competition, the pace of innovation, product demand, and the organization’s role in the enterprise. Management’s challenge is to bring this perspective to the Agile teams and collaborate and lead so as to bring the best value to the business.

The right controls facilitate agility; the wrong controls hinder agility. For example, consider two sorts of aircraft shown in Figure 1: a jet fighter (an F-22) and an airliner (a Boeing 747). The F-22 is very agile. It has sensors, actuators, and software that constantly detect and react very quickly to changing conditions (e.g., local weather, altitude, orientation, fuel onboard, and pilot intent). It is this agility that enables the plane with its pilot to outmaneuver the enemy. It achieves this agility with very tight control loops. However, the fighter is aerodynamically unstable. Remove the controls and the plane will crash. It will not glide.

The 747 commercial airliner, on the other hand, is not designed for maneuverability, but for stability. If one of its systems (e.g., an engine) fails, the plane can still fly. The 747 has controls, but they are less intense and are designed to keep the plane on course, even if the pilot falls asleep. It is unaffected by changes in the environment. It is this stability that makes the plane safe for commercial passengers. However, this very stability would put the 747 at a severe disadvantage in a dogfight. Both planes are excellent for their purposes. So the question for managers is, “What sort of organization do I want?”

 

Figure 1 — A jet fighter is agile but not stable;
a commercial airliner is stable but not agile.

In the past, managers were taught to build stable organizations, creating long-lasting stockholder value. In today’s rapidly changing world, agility has the greater premium. So do you want your organization to be like a 747 or an F-22, or perhaps something in between? Depending on your situation, each is a valid choice. Unlike what many believe, being agile requires more control, not less. However, the controls must be chosen with care.

Traditionally, organizations relied on stable, tried-and-true systems, processes, procedures, and workflows. The goal was to ship well-understood products rapidly and efficiently. Workers were exhorted to “plan the work and work the plan”; threats and unknowns were often ignored and not responded to. The goal was to build an organization of lasting value that could withstand the buffeting of changes in the market.

But today, the pace of external change makes it more important to react nimbly. Today’s mindset of adaptive, reactive organizations characterizes the opposite end of the spectrum, with autonomous, self-organizing teams focusing on the work and eschewing process. This swing of the pendulum has, in some cases (especially development), led to a disconnect between the workers and management. There were extreme cases in which it was considered “Agile management malpractice” to make delivery commitments. The Agile management challenge, therefore, is to reach the right balances between:

  • Stability and agility
  • Control and empowerment

[For more from the author on this topic, see “Agile Management, Part I: What and Why.”]

avatar

Murray Cantor

Murray Cantor is a Cutter Consortium Senior Consultant. He has been applying leading-edge ideas in software and systems development for more than 30 years. Until recently, Dr. Cantor was an IBM Distinguished Engineer, a member of the Rational CTO Council, and the Rational Lead for Analytics and Optimization for Software and Systems.

Discussion

  2 Responses to “Agility and Stability”

  1. Getting balance between Agility And Stability is quite tough but one should focus on this entirely as per your thoughts too. Agility is an important part of enterprises also. I have recently read the relation between Agility and TOGAF and found a lot of knowledge about the working of it.

  2. I love this Murray. The image I see is that off someone leaping across a giant pond, going from rock to rock. In this image both stability (firm rocks) and agility (ability to leap) are both vitally important.

    I think that both the modern day knowledge worker and the technology that they use need to BOTH be agile and flexible, working together to build what needs to be built.

    Would love your thoughts.

    Geoff
    InfoPath Alternatives

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)