Analogies are very powerful, either to mislead or to instruct. For many years people (including me for a short while) have used the analogy of building a house—or a bridge, or a skyscraper, or anything else—to understand how to properly build software. I recently came across another example at one of my favorite database-related web sites, SQL Server Central. Here it is, followed by what I think is a better one:
The not-so-flattering Agile analogy (not invented by me) is like trying to build a house one-room-at-a-time (where software is the "fine carpentry and dry wall" and data structures are the "foundation and roof"). "O, wow, I really like this kitchen" says the customer, "let’s add a bedroom". Seems easy if you’re doing fine carpentry and drywall. However, how do you do Agile foundation work and roofing? Brings to mind the parable told by the radical rabbi about the foolish man building his house on sand. The wise man built on a solid foundation.
In my opinion this analogy is flawed in two ways. I’ll briefly state the first reason, then treat the other at more length.
First, and I guess not surprising given the site it came from, it shows a bias towards data. I’ve spent (and continue to spend) my most of my career more closely aligned to the database world than the realm of of what this person would call “software”. But data’s no good unless you can use it. I would hardly call the programs enabling data to be useful, “fine carpentry and dry wall.” For this analogy to work at all, we’d probably better use architecture as the foundation.
But the whole analogy is flawed from the beginning because data, and the software that accesses it, is not like a house. Nor is its construction and use. This has nothing to do with Agile vs. non-Agile. It’s just the wrong analogy. Plenty of other others have written about this, so I’ll leave it at that.
I know of a better analogy the applies specifically to Agile Development—at least to me. I didn’t make it up, but I think I’m going into a little more depth here than I’ve seen elsewhere.
Keep in mind that this analogy applies only to Agile Development done well, which excludes the vast majority of projects that have tried to use the name.
Agile Software Development is like Human Development.
- A human has a very short gestation period compared to the expected life of the system—but the being’s life depends on critical aspects of that period.
- It is recognizable as human even before its first release (birth). It has some some essential subsystems (skeletal, circulatory, nervous, etc.) and a recognizable shape. They are in their most basic form, but they exist. A leg (or kitchen in the other analogy) does not develop in its entirety followed by the head and so on…instead, the fundamental systems develop gradually and more or less simultaneously from the start.
- A healthy fetus may be viable, with extra support, even before its first delivery date, and sometimes this becomes necessary, although its functionality will be even more limited than projected.
- The first release of a human to the customer, or parent, has extremely limited functionality and will likely keep them up at night, but it’s what they wanted and expected at this stage of the game and it delights them to no end. They even happily show it off to anyone who will pay attention.
- This is the most important point: due to its superb architecture and high-quality construction, a healthy newborn human excels at precisely one thing from day one: it can become more mature in very small, rapid increments, in a somewhat (but not entirely) predictable way, losing nothing essential along the way (baby teeth, etc., may be discarded when no longer needed).
- Some critical components (for example, certain structures in the brain required for making wise decisions) don’t exist at all in release one, and won’t develop for quite a long time. The parents and others will have to compensate for this, but they’re happy to do so (even if a little frustrated at times) because of the value already being delivered and their confidence that it will indeed develop as a natural part of the process.
- Maturation is extremely fast in early life and slows thereafter. But even late in life a human can gain new functionality, such as learning to play the guitar.
- Progress is measured primarily by concrete behavior (“she learned a new word today!” Or, “he gets his homework done without nagging now!”).
- Within the limits of its excellent, flexible architecture, it can rapidly adapt to radical, unexpected, and even adverse changes in its environment.
- If quality of construction is allowed to decline through neglect, abuse, etc., the system degrades but will otherwise have a long and productive lifetime.
- The adult’s full feature set (will it become a DBA? Will it be good at basketball?) is not determined until long after its initial release. Many possibilities and possibly some limitations can be indicated at the very beginning, but the adult’s character and abilities are influenced a great deal by environment in a long succession of mostly small decisions.
This analogy is of course far from perfect. Most importantly, the “customer” (parents) have limited choices to make in the initial specifications, nor do they have full influence over the final product. (Some theologies, including mine, would say that the parents are merely stewards; the true “customer” is also the architect, product manager, source of funding, and ultimate owner.) Then again, some software systems morph into things undreamed of by the initial customer, and the systems may very well outlast them.
So there you have it—the best analogy I know of for Agile Software Development done well. I hope it’s instructive about how it’s supposed to work, even though we all know it not done perfectly. I also hope that even though I didn’t try to make it match up point for point, you can find how this fits with the thinking behind the Agile Manifesto and especially the “Principles behind the Agile Manifesto.” You might smile as you carefully compare them.