Product development flexibility depends not so much on following a certain approach as on adopting a set of values that support flexibility. Below are some of these values.
Since about 2000, the agile software development community has created several agile methodologies, including Extreme Programming, Scrum, Adaptive Software Development, and Crystal. Although these differ in detail, they all stem from the Agile Manifesto, a set of four contrasts of values.
The agile methodologies benefit greatly from certain characteristics of modern software development, specifically object technologies, the ability to automate testing, and the general malleability of the software medium. Non-software products lack these characteristics , so we must find other ways to achieve flexibility. This is the challenge of flexible development.
However, agile software development values do carry over to the development of non-software products. Fortunately, you don't have to know much about programming to understand how the agile methods work.
The Agile Alliance is a good source of information on the agile approach.
In short, the agilists have blazed the basic path and established the values, but we will have to pave and widen it with techniques suitable for non-software products.
The initial contrast of the Agile Manifesto is "Individuals and interactions over processes and tools." This isn't idle talk. Data from a broad base of software development projects over a 20-year period show that people and their interactions have ten times more potential for productivity than tools and processes:
From Flexible Product Development by Preston
G. Smith, Jossey-Bass, 2007. © 2007 by John Wiley & Sons. Used with
Data source: Boehm, Barry W., et al. Software Cost Estimation with COCOMO II. Upper Saddle River, NJ: Prentice Hall, 2000.
However, most product developers consider their process the centerpiece of their product development. If you ask them how they develop products, they are likely to reply that they use a Stage-Gate® process, a PACE process, or a waterfall process.
Some process and structure are certainly necessary, but too much process breeds rigidity. Moreover, it is very difficult for inexperienced developers to see and trim the excess out of a process, and management usually feels more comfortable with extra process as a safety net.
In contrast, the emphasis is on people in flexible development: with experience, they can adjust the process to what is needed. Consequently, for flexibility, we use a "barely sufficient" process and encourage the team to gain experience in adapting processes to suit the occasion.
Traditional product development aims to deliver the set of features originally specified and planned. The closer the team sticks to the original plan and delivers the full set of specified product requirements, the more successful it is. Developers love "frozen" requirements as a stable reference point in the midst of turbulence.
This approach doesn't work when change is the norm. Sticking with original plans puts you at a great competitive disadvantage when the market needs something else or if technology opens new possibilities.
Consequently, a flexible team measures itself by delivering value. Yes, value is harder to measure than a list of completed product requirements, but it is far more useful to the customer—and, in the end, to the business.
One advantage of using value as the measure of completion is that we might terminate the project when it has delivered the bulk of customer value, skipping some items that were discovered to be of low value as the project progressed.
Delivering value fits with the Agile Leadership Network's Declaration of Interdependence.
Flexibility requires people who not only are comfortable with change but are experienced at adapting processes to fit the circumstances. Agilist Alistair Cockburn suggests three levels of process mastery:
Process adaptation skills are learned only by practicing them. Thus, we encourage direct hands-on practice rather than extensive planning and preparation, which is likely to become obsolete quickly in a fast-changing environment anyway.