Agile is an
attractive word. It means swiftness with discipline, with an emphasis on
alertness to change in one’s external surroundings and quickly responding to
change as needed.
The word I want to focus on from above is external. When the surroundings that
generate change are actually controllable, then the need for agility is greatly
reduced. Agility comes at a price, and maintaining agility is a waste of
resources when change is controllable.
A prime example of the difference between internal
(controlled) and external (un-controlled) is an operating enterprise: business
company, non-profit group and the like. The interesting problem for most enterprises
is how effectively they control their own operations. The boundary between
internal and external can become nebulous if control is lacking in parts of an enterprise.
Control sounds
like a bad word. It implies top-down definition of all aspects of enterprise
operations. This can be true, but control can also include delegation of
authority, with expectation of results without definition of methods used.
Control is maintained, but authority is distributed. This is the sphere of business
management practices, defined and changing and transforming from Henry Ford to
Jack Welch. It is not easy, and many others have and will address it better
than I, so I will reference them as need be.
The topic of interest here is the boundary between internal
and external, controlled and uncontrolled, event and response… but not between
knowable and unknowable. An enterprise needs to know what is happening around
it in order to focus its operations on knowing what events are important,
events that it needs to respond to. For these events, an enterprise defines
processes/procedures to execute when triggered by events, to provide the
desired results in response to the events; successful enterprises include those
that recognize that the nature of events and corresponding processes change
over time, sometimes very quickly. So, at any one point in time, an enterprise
needs to be in control of its processes, but that control can’t stifle the need
to change as fast as the world around it changes. Further, this rapid change
needs to be accomplished without disrupting on-going operations.
What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly
to changes in its surroundings without losing its internal cohesion.
The basis for controlled agility in an enterprise includes
understanding that:
- an enterprise runs on its processes, not its org chart
- processes are composed of distinct activities and decisions
- processes run on information, gathered and stored and used
- processes are guided by business rules, especially when decisions need to be made.
With this basis, an enterprise is well-positioned to be
Agile without losing Control. It all comes down to understanding Change.
Change comes in many degrees of impact to an enterprise.
Consider workflow, which is based on process with roles and authority levels
defined. If all loan applications over $100,000- go to Fred to be underwritten,
the workflow will change temporarily when Fred goes on vacation. Those loan
applications have to go to someone else until Fred gets back. This kind of
change can happen frequently, but more importantly, it is a kind of change the
enterprise knows can happen.
Frequent known changes are the heart of controlled agility.
This is the kind of change an enterprise must be able to do, without changing
itself, as part of operations. It should not need a project, especially an IT
project, to make the change.
Temporarily changing workflow might be considered a simple
example, but it is actually an example of an overall type of change that can
occur frequently, and that is business rule change. Business Rules are so
embedded in how an enterprise works, it is actually a new and revealing
approach to call them out separately. In a lender enterprise, it is likely a
fact that “Customers may apply for Loans”, but “Customers may apply for Loans,
only if they are 18 years old or older” is a Business Rule; it constrains an
aspect of enterprise operations and, as said above, rules change (next year it
could be 19 years). An enterprise that knows the facts and rules of their
operations is well positioned to change rules as quickly as needed. However,
rule changes still need to be controlled to avoid using incorrect rules to the
detriment of the enterprise. Still, these changes should not require a project
to change the structure of the operation and, again, not need an IT project.
A major use of rules is to support making decisions. Loan underwriting across many financial
lending/leasing enterprises is heavily rule-driven, the information about a
customer and the loan product being used to decide to lend or not. These can be
complex rules, or simply that the enterprise does not lend to anyone with a
Credit Score below a stated value; and again, the rules will be changed over
time as a lender tunes its underwriting, or is willing to take on more risk,
etc..
Decisions also play a role in defining what processes/activities
are used to respond to events. We all know of BPM diagrams with boxes for
activities, diamonds for decision points, and arrowed lines connecting them
all. A process may be composed of 20 possible activities, but less than 20
might be used in response to any one event because of decisions based on rules.
What can change for a process? The number of processes in an
enterprise, once all are defined, is relatively stable over time; new processes
usually mean the enterprise has expanded its products/services to areas which
need their own processes. Within a process, however, the exact activities that
are carried out may change, or be re-ordered, or even be retired. It is the
ability to change processes as quickly as possible, again without a project,
that marks an enterprise as Agile.
Changes in decisions and rules used in processes are the
most frequent changes an Enterprise must do. Changes to the activities in a
process change less frequently than decisions/rules, but often enough the agile
enterprise needs to it as part of its operations.
Are there aspects of an enterprise that are more stable? And
are types of changes to them not necessarily known or predictable? This is a
loaded question, because the answer is information or specific data used by an
enterprise. Once all the information needs are known for an enterprise, these
are very stable over time. The need to change information needs is similar to
the need to add more processes; it happens when (as above) the enterprise is
expanding into new products or services different from current
products/services. To be more precise, information needs may change as the
enterprise expands, but they may not as well; data requirements have been shown
to be the most stable aspect of an enterprise.
So we have two ends of the change pendulum: from frequent
and known, to rare and unknown. As said earlier, frequent known changes are the
heart of controlled agility.
