Product Development Flexibility: What Are Its Roots?

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.

Agile Software Development Is a Helpful Model
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.

People over Process
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 permission. 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.

Aim to Deliver Value
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.

Learn by Doing
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:

1. Must follow a method
2. Questions and contrasts methods (but still needs a method to follow)
3. Fluent, so can adjust and even create methods to suit

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.

Copyright © 2013 Silver Streak Partners LLC all rights reserved