Page 70 - DCAP405_SOFTWARE_ENGINEERING

Unit 5: An Agile View of Process

measure that can be used in representing how agile a software development process is. The Notes
proposed measure employs information entropy as the main concept related to software agility.

5.1.1 What is Agility?

To become Agile, most organizations will need to change their perspective. Most of our
assumptions about business, about technology and organizations are at least 50 years old. They
have outlived their time. As a result, we are preaching, teaching, and practicing policies that are
increasingly at odds with reality and therefore counterproductive.
Agility isn’t a one-shot deal that can be checked off the organizational initiative list. Agility is a
way of life, a constantly emerging and changing response to business turbulence. Critics may
counter, “Agility is merely waiting for bad things to happen, then responding. It is a fancy name
for lack of planning and ad hoc-ism.” But Agile organizations still plan; they just understand the
limits of planning.

Notes Although the defining issue of agility involves creating and responding to change,
there are three other components that help define agility: nimbleness and improvisation,
conformance to actual, and balancing flexibility and structure.

Creating and Responding to Change

Is agility merely a matter of reacting to stimuli, like an amoeba, or is it something more? My
preferred definition of agility has two aspects:
Agility is the ability to both create and respond to change in order to profit in a turbulent
business environment.

Agility is not merely reaction, but also action. First and foremost, Agile organizations create
change, change that causes intense pressure on competitors. Creating change requires innovation,
the ability to create new knowledge that provides business value. Second, Agile organizations
have an ability to react, to respond quickly and effectively to both anticipated and unanticipated
changes in the business environment.
Agility means being responsive or flexible within a defined context. Part of the innovative, or
proactive, piece involves creating the right context—an adaptable business organization or an
adaptable technology architecture, for example. Innovation is understanding that defined context
and anticipating when it needs to be altered. The problem with many traditional software
development and project management approaches is that they have too narrowly defined the
context; that is, they’ve planned projects to a great level of task detail, leaving very little room
for agility to actually happen.
“We think Agile is both being able to respond quickly (which means you have to know that you
have to respond quickly—not an easy thing to do) as well as being able to anticipate when the
rules or principles are changing or, more importantly, can be changed,” says Bob. “Organizations
that do this are often called “lucky”—in the right place at the right time. Some undoubtedly are,
while a few have created the necessary infrastructure to exploit the change.” Part of the cost of
agility is mistakes, which are caused by having to make decisions in an environment of uncertainty.
If we could wait to make product development decisions, they might be better ones; however,
the delay could well obviate the need for the decision at all, because aggressive competitors
may get their product to market while we dither. “This fact leads to a sort of organizational
uncertainty principle: The faster your decision-making cycle, the less assurance you can have
that you’re making the best possible decision,” says David Freedman (2000).

LOVELY PROFESSIONAL UNIVERSITY 63