Agile Software Development and the Three Faces of Simplicity

Simplicity should be simple, shouldn’t it? Unfortunately, sometimes it’s downright difficult. Most of the agile approaches to project management and software development espouse a principle of minimalism: do less, do better, and do swarms. In this article, Jim Highsmith of the Cutter Consortium discusses these three dimensions of simplicity.

Simplicity should be simpleshouldn't it? Unfortunately, simplicity
isn't always simple, and sometimes it's down right difficult. Most of
the agile approaches to project management and software development espouse a
principle of simplicity or minimalism, from lean development's principle of
minimalism to Crystal's call for eliminating embellishments to
methodologies, to extreme programming's "do the simplest thing
possible" (which includes the famous YAGNI acronym for "you
aren't gonna need it"), to adaptive development's call for
"a little bit less than just enough process."

But there are at least three dimensions, or faces, to simplicity: do less, do
better, and do swarms. The last of which is often overlooked and
underappreciated by a great number of people, both within and outside the agile
community.

"Do less" means just that: do fewer activities, produce fewer
documents, reduce management reports. Alistair Cockburn discusses methodology
embellishments, those activities that creep into work processes because someone
says, "this activity should help us deliver software of higher
quality." Note the operative word is "should," because these are
often activities that they have read about in a book, heard in a presentation,
or been taught in a workshopnot things they have any actual experience
doing. Embellishments are insidious; they often arise from a problem
encountered, for which the new activity is intended to prevent a recurrence.
Time and again, activities are added to prevent problems. Many, if not most, of
these problems would be effectively resolved by a "fix on occurrence"
strategy rather than adding overhead to every project.

"Do better" has a particular flavor, particularly when applied to
design. Several years ago I participated in a data architecture project for a
worldwide consumer goods company. A previous project had produced a data model
that unfortunately looked much like the proverbial rat's nest. While
complete, the model was not usable. Over a several-month project, the new team
accumulated user stories related to the data, and the team constructed,
deconstructed, and reconstructed the data model. Slowly but surely, the model
evolved into one that was more readable, more understandable, and simpler. In
the end, the team began using the words "aesthetic" and
"streamlined" to describe the model. The simpler and more
straightforward the model became, the surer the team became that the design was
correct.

XP's criteria for simple design are: runs all tests, no duplication,
expresses every idea, and minimize elements (classes, methods). In this
scenario, simple design (do better) may take considerable worksimple
design often takes more time, not less. In the data model example, we produced a
model but it took several months to turn a model into a simple model. Code
designs evolve by an ongoing process of coding, testing, and refactoring
(periodic redesign). Simple, aesthetic designs emerge from concentrated effort,
including revisions. Simple designs don't mean less work, they mean more
thinking.

If simple designs take additional work, why take the time? Simple: simple
designs are easier to change. The prime rationale for agile processes is
flexibility and adaptability to change, not necessarily pure delivery speed. In
fact, agile processes produce results faster in high-change environments.
Failure to "do better" results in difficult-to-change code, which then
slows subsequent iterations.

"Do swarms" values simplicity for the complexity it generates. The
concept of swarm intelligence comes from complexity theory: the right set of
simple rules, applied within a group of highly interactive individuals, produces
complex behaviors such as innovation and creativity. Jim Donehey, former CIO of
Capital One, used four rules to help ensure everyone in his organization was
working toward the same shared goals: always align IT activities with the
business, use good economic judgment, be flexible, and have empathy for others
in the organization (Eric Bonabeau and Christopher Meyer, "Swarm
Intelligence: A Whole New Way to Think About Business," Harvard Business
Review, May 2001). Do these four rules constitute everything that
Donehey's department needed to do? Of course not, but would a 400-page
activity description get the job done? What Donehey wanted was bounded
innovationa department that thought for itself in a very volatile business
environment, but also one that understood boundaries.

Similarly, the 12 practices of XP, the 9 principles of DSDM, or the 12
principles of lean development (all agile methods) do not constitute everything
a development group should do. However, they do constitute the minimum set of
rules that bound innovative and productive work. They create an environment of
innovation and creativity by specifying a simple set of rules that generate
complex behavior. XP, for example, doesn't prescribe configuration control;
it assumes that when a team needs configuration control, it will figure out a
minimum configuration control practice and use it. Agile methods don't
attempt to describe "everything" that any development effort might
need in thousands of pages of documentation, they describe a minimum set of
activities that are needed to create swarm intelligence.

As Bonabeau and Meyer point out, developing a useful set of rules is not a
trivial exercise. The rules can often be counterintuitive, and seemingly minor
changes can have unforeseen results. This is one reason proponents of XP may
seem to be overly adamant about not (or at least very carefully) altering XP
practices. They know from long experience that the 12 practices reinforce each
other in both direct and subtle ways. Changing one practice without
understanding the interactions and the concepts of swarm intelligence can cause
the complex XP system to react in unforeseen ways.

So simplicity is not simple. Furthermore, it extends far beyond the
oft-maligned concept of reducing documentation. Those who think simplifying
software development via agile processes refers only, or even primarily, to
reducing documentation don't understand the three aspects of simplicity: do
less, do better, do swarms.

The Agile Project Management Advisory Service is designed to help
organizations implement software development practices that support
responsiveness, adaptability, and innovation. Led by Jim Highsmith, author of
the award-winning book Adaptive Software Development, the Cutter team of
internationally recognized expertsincluding Alistair Cockburn and Ron
Jeffriesprovides timely, measured, and succinct information that focuses
on the project management tools you can really use. Receive advice and guidance
you can put into action immediately! For more information visit
http://www.cutter.com/consortium/advisory_epm.html .

(c) 2002 Cutter Consortium. All rights reserved. Unauthorized reproduction in
any form, including forwarding, photocopying, faxing, and image scanning, is
against the law.