Agile Software Development and the Three Faces of Simplicity
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Agile methodologies supporters claim better quality, shorter schedules, and lower costs—but many managers are skeptical. What's the real story? Download a FREE copy of the expert report Fists are Flying: Agile Versus Heavy Methodologies, by Cutter Consortium.
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.
—Jim Highsmith, Practice Director, Agile Project Management
http://www.cutter.com/consortium/index_ebusiness.html
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.