The Roots of Agile, Part 1
by Preston G. Smith
Agile software development attempts to enhance our ability to make changes during the product development process. This is valuable because the business world is becoming increasingly chaotic in the following ways:
Customers change their minds or use the product in unanticipated ways.
New competitors appear or existing ones introduce threatening products.
New product technologies arise or planned technologies don't work out as anticipated.
Unfortunately, conventional agile software development, although quite successful on software projects, doesn't translate well to non-software projects because it depends on some special characteristics of the software medium, such as object technologies and the ability to automate testing and thus do it continuously. So the question arises: Are there comparable techniques that apply for making non-software development (cell phones, hand tools, or food, for example) more agile? There indeed are, but to find them you must understand -- at the most basic level -- what enables agility.
That is the purpose of this article: to appreciate the roots of agility so that they may be used to enhance existing agile software development methodologies or to inject agility into the development of non-software products. I will introduce nine factors -- four this month and five more next month -- that will enhance your agility regardless of the type of product you are developing; for more on any of these, please see my book, Flexible Product Development (Jossey-Bass, 2007).
Isolate Areas of Change
Modular product architectures are invaluable for creating interfaces between chunks of the product, which allow one to make changes in one part of the product without this change rippling into other parts, prompting massive redesign. Think of these interfaces as fences. Draw them tightly around the areas where you anticipate change, and then they contain the change, rendering it less disruptive.
Clearly, this requires you to have some idea of where change might occur, and this is the case for most means of enhancing agility: you must anticipate to some extent where you believe change will occur. Also observe that such product modularity can be applied in several domains of the product: software, electrical hardware, and mechanical hardware, for instance.
Develop Your Options
During a project, we inadvertently make decisions that close off options, thus limiting our ability to take another route later. Consequently, agility is a matter of being conscious of these options, not closing them until necessary, and actually expanding them actively.
There are two ways of pursuing this. One is experimentation: purposely exploring the design space through various types of experiments (tests, prototypes, or simulations, for example). Through experiments, you can see what works and what doesn't and maybe even better understand the underlying factors. Then you are in a stronger position when change happens.
The other approach is a technique originated by Toyota called set-based design. In it, you methodically prune areas of the design that will not work, leaving areas -- a set of solutions, rather than a single point -- that will work. With these areas of feasibility known, change becomes a minor adjustment rather than a major disaster.
Delay Making Decisions
A related way of maintaining options is not to make a decision until necessary -- what we call making decisions at the last responsible moment. This has two desirable outcomes. First, it keeps options open longer, thus improving agility, and second, it allows you to make the decision with fresher, more complete information when closure is finally needed.
This may seem obvious, but many development processes -- such as waterfall, phased development, and related management techniques -- encourage making many project decisions early in order to "nail down" the project. Management feels more comfortable with a complete plan, even if some of the decisions implied in a complete plan are not yet required.
Making decisions at the last responsible moment is not procrastination; in fact, it is the opposite. Rather than the relatively lazy approach of procrastinating, the last responsible moment approach is a proactive one of scheduling the decision and proceeding to collect information that will be needed to make it when its time comes. In addition, the last responsible moment is not the best approach for handling certain decisions.
Enhance Communication
When there is no change during a project, one has the luxury of documenting the entire project, communicating it once to everyone involved, and then working to this plan. Changes in plans require not only re-communicating these changes but also additional communication to ensure that each player knows about the changes others are making and to indicate the possibility of future changes so that people are not blindsided by them.
Consequently, a project operating in a turbulent environment will require far more communication, more accurate communication, and faster response in communicating. Adding additional technical communication channels, such as e-mail, does not do this because they do not have the fidelity and responsiveness required. Instead, the primary means of enhancing communication is strengthening the development team: full-time involvement, co-location, and an empowered leader, for instance.
This covers the first four factors for making your development process more agile. I will cover the remaining five next month. I welcome your comments on this Advisor and encourage you to send your insights on agile project management in general to me at comments@cutter.com.