Advisor

Empowerment and Control in Agile Management

Posted August 11, 2016 in Business Agility & Software Engineering Excellence

When deciding how Agile your organization needs to be, consider the following three categories and determine where your business falls:

  1. Mostly stable. Are you managing a time-tested mature system in a relatively stable business envir­onment? An example of such a system might be wire transfer management or payroll processing. Such systems forge ahead through challenging business cycles. For good reason, you believe your organization can rely on these tried-and-tested systems, like the stable 747. They are what you did in the past, what helped you through periods of relative instability in the business climate, and what gives you confidence in the future. After all, if it ain’t broke, don’t fix it.
     
  2. Somewhat Agile. Are you comfortable with your honed and highly reactive process management system but under constant pressure to reduce costs and improve efficiency? In this state, you are always open to more fine-tuning and exploring modern Lean techniques, where and when needed.
     
  3. Mostly Agile. For whatever reason, you are being challenged by a rapidly changing business environment. Perhaps you are in the midst of a major reorganization or merger. Perhaps some disruptive technology has entered your market. Or perhaps you are in building mode, ushering in a new system or platform requiring learning and innovation.
     

Going Agile paradoxically requires both more control and more empowerment through the following:

  • Control as in “measure and act” (i.e., “sense and respond”), as shown in Figure 1
     
  • ​Empowering each team to own its measure and respond loops
     

The key to Agile management is that the organization and analytics that implement the interlocking sense-and-respond loops up and down the organization enable overall organization agility. When we use the word “control,” we do not mean controlling the worker with micromanagement or invoking tight process specification and adherence. Rather, we mean that everyone involved in the work has the means to sense and react. This in turn brings up a central principle for the Agile manager: focus on the work, not the process.
 

Figure 1 — “Plan, Do, Check, Act” is central to Agile management.


This principle is fraught with implications. It entails thinking of your business process, not as a defined set of activities, but as a value stream, a set of actions that transform the states of work items so that they accrue value. The accrual of value, no matter what the process, is central to Agile thinking. This is sometimes described as an artifact-centric business process. This means to stop worrying about key process areas and measuring process adherence. The Agile team goal should not be to adhere to a defined process, but rather to efficiently deliver value under changing circumstances. The choice of measures depends on the novelty of the effort and the level of the organization.

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

About The Author
Murray Cantor
Murray Cantor is a Cutter Consortium Senior Consultant. He has been a leader for over 30 years, applying leading-edge ideas in software and systems development. Currently, Dr. Cantor is CTO of Aptage. Recently, he served as an IBM Distinguished Engineer, a member of the Rational CTO Council, and the Rational Lead for Analytics and Optimization for Software and Systems, where he led the application of predictive analytics to software and systems… Read More