Page 77 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes As projects become increasingly complex, the balance swings much more toward the latter.
At times it seems almost mystical, but in field after field, from physics to cellular automata to
some of my client’s projects, emergence has, well, . . . emerged . We have all experienced
emergent results on some special project, but it somehow seemed nearly accidental, not
something to count on in a crunch. CAS provides some comfort that it is not accidental.
For a project manager, maintaining this balance means two things. First, he or she has to decide
which parts of the project are predictable. For example, we can predict that without appropriate
configuration control procedures, a software project of any size can implode. For parts that are
unpredictable, he or she has to establish an environment in which the wild and wonderful
properties of emergence — basically open, collaborative, messy, exciting, diverse, anxiety-
ridden, and emotion-laden — can exist.

Unfortunately, at least for some people, CAS postulates certain conditions for emergent behavior.
The most important is that it happens at the edge of chaos. Whether in physics, biology, business,
or human behavior, it appears that there are three broad categories of environments — stable,
unstable (or chaotic), and a transition zone labeled the “edge of chaos.”
The edge of chaos is the constantly shifting battle zone between stagnation and anarchy, the one
place where a complex system can be spontaneous, adaptive, and alive.
In human terms, being in chaos is analogous to being psychotic. So the trick is to lead a project
team away from the familiar and the stable toward chaos, but not all the way. Success comes to
those who can hold anxiety, who can attune themselves to paradox and uncertainty. Innovation,
creativity, and emergent results are born in the transition zone at the edge of chaos.

Learn

Collaborative activities build products. Learning activities expose those products to a variety of
stakeholders to ascertain value. Customer focus groups, technical reviews, beta testing, and
postmortems are all practices that expose results to scrutiny.
Learning, according to the dictionary, is gaining mastery through experience. In an adaptive
environment, learning challenges all stakeholders, including both developers and customers,
to examine their assumptions and use the results of each development cycle to learn the direction
of the next. The cycles need to be short, so teams can learn from small rather than large mistakes.
They also need to be double-loop, so teams learn both about product changes and more
fundamental changes in underlying assumptions about how the products are being developed.

Speculate—Collaborate—Learn

If you examine the speculate — collaborate — learn cycle, even briefly, it becomes obvious that
the three stages overlap. It is difficult to collaborate without learning or to learn without
collaborating. They are purposely messy, nonlinear, overlapping terms — how could terms that
describe an adaptive framework be otherwise?
For many project leaders and project teams, adaptive development is a terrifying prospect. First,
we knock away the foundation pillar of cause and effect, so we can’t say for sure what needs to
be done next. Next we force the team into meeting deliverable goals, but we admit we don’t
know exactly what they are. Then when they then get anxious and concerned about all the
“seemingly inefficient” groping around for solutions (because of the needed diversity and
multiple interactions), we have to say that high anxiety is part of the new game, and it won’t go
away. And finally, when a successful product emerges, to many it seems almost accidental. It is
not a place for the timid.

70 LOVELY PROFESSIONAL UNIVERSITY