Change: embrace it, don't deny it: tools and techniques inspired by software development can introduce the flexibility needed to make changes during product development with minimal disruption

Research-Technology Management, July-August, 2008 by Preston G. Smith

* They all reassess and replan the product requirements at the end of each iteration.

* They incorporate the customer in this frequent iterative planning.

* They depend on small, close-knit teams and will subdivide a large project until they can use such teams.

* Many employ pairing, in which developers write all production code using two programmers sitting at one computer with one keyboard and mouse, trading off between "driver" and "navigator" roles.

* They integrate one product feature at a time into the existing package and automate testing so that they can test continually as they integrate in order to detect problems early.

* Furthermore, many write these tests before developing the corresponding product feature and then design the feature to pass the test.

This is not business as usual in the software development world, in which the norm is a sequential (waterfall) process with extensive upfront documentation and many design reviews (code walkthroughs) to ensure that the software works properly when it is finally operational.

Although agile development has grown explosively in the software community, it depends on some unique characteristics of the software medium--such as object technologies and the ability to automate all testing--that are not available to the developers of other types of products. This does not mean that other fields cannot be agile, but it does mean that other developers and managers wishing to become more agile will have to rethink the basics of agility and find other tools and approaches for restoring flexibility to non-software development.

This rethinking of agile development is not straightforward, nor can one simply map the agile development characteristics in the bullet list above into flexibility techniques for non-software development projects. It requires a rebuilding, for instance, in recognizing that:

* There is value in making the product modular so that change can be contained within a module (as is done with object technologies in software).

* A key to flexibility is delaying decisions, (as agile software developers do by deferring decisions on a product feature until the iteration in which the feature is to be implemented).

* Small, close-knit teams do best at managing the heavy, highly responsive communication needs of a project subject to unrelenting change.

* There is great value in building and maintaining options to be available in case something changes.

From such recognitions, which have come largely from observing how agile software development projects work, I have assembled the set of flexible development tools and approaches described below for application to non-software products. Although aimed beyond software, I believe these techniques will also help software developers to better appreciate the essentials of what they are doing.

Although each of the following tools and approaches provides greater flexibility, each also has its costs, monetary or otherwise. Consequently, you should apply these tools with an eye toward both benefit and cost. Apply them selectively to only the parts of projects where you anticipate change or to only projects facing the prospect of great change. This assumes that you can, to some extent, anticipate where change is most likely to occur.