| Creating a
Fast and Flexible Process: Research suggests Keys to
Success
Alan MacCormack, a professor at Harvard
Business School, was
studying successful software development processes. He
and his colleagues asked executives at a software firm
to provide two case examples, one from a "good" project,
and another from a "bad" one. Two projects were
identified, each of which yielded products that had just
shipped. Observing the state of these products over
time, MacCormack and his researchers saw that the "good"
project failed in terms of such factors as market
acceptance, expert quality rating, and productivity.
According to MacCormack, the project that management
said was a good project "turned out to be uniformly
bad," while the project that executives said was "bad"
was a marketplace success.
MacCormack discovered that
what executives judged to be a "good" project was one
where the specification was completed up front, where
the design had been frozen, and the project had been
executed fairly efficiently. For executives, a "good"
project was one that built the product that it set out
to build. A "bad" project, according to executives, was
one in which the final results ended up looking
completely different than what they set out to build.
And yet the market reaction to the project that had gone
through continual change was much better than the
project that had a design that was frozen in time. Says
MacCormack, "The way they thought about ‘good’ and
‘bad’ in that case was completely upside down. The
people who were overseeing projects there assumed that
the good projects were the ones that delivered to the
spec. In fact, good projects are ones that deliver to
the market."
MacCormack’s ongoing
empirical research into flexible product development
processes has yielded a number of important insights
into how these types of processes work, and how they can
be leveraged to deliver successful products to the
marketplace.
Flexible Processes: A
Response to Uncertainty
A flexible process is one in
which a great deal is unknown at the beginning of the
project. As a result, these processes are designed to
manage uncertainty. Says MacCormack, "There
are some uncertainties that are irreducible. A lot of
product development theory is predicated on the idea
that you can eliminate uncertainty up front in
development, and then it becomes a routine task. There
are some environments where that is not the case. During
the execution of the project, you actually have to be
good at learning about things that you have no past
experience of."
The aim of the more
traditional methods, claims MacCormack, is to stamp out
uncertainty. A flexible process, however, doesn’t only
tolerate uncertainty – it actively builds a
process around it. MacCormack finds that different
product development practices bring different benefits
depending on the level – and the source – of
uncertainty. Explains MacCormack, "If you face high
market uncertainty, then you get much more benefits from
an early beta release than if the uncertainty is...more
around the technologies inside the product. I call this
a contingent approach to development where you say, at
the beginning of development, that the first phase of a
project should not be concerned with product design. It
should be concerned with process design. [In flexible
processes] the first question is ‘What type of
uncertainty do we face?’ And given the levels and
sources of uncertainty, what is the appropriate process
for us to use?" A further complexity is introduced
by the fact that on any given project, the source of
uncertainty may change.
Evolutionary Delivery:
Generate a Small Number of Features…that
Work
MacCormack’s research
suggests that one of the hallmarks of flexible
development is that it seeks to create a working version
of the product as early as possible. Rather than
creating the entire product prior to market testing it,
a functional version of the system is created, but with
only a portion of the feature set. MacCormack explains
that these early beta versions are not computer
mock-ups, or wooden or clay models, that are thrown away
after use, but a working version of the
system.
This evolutionary delivery
model of development, explains MacCormack, "means
a change in mindset because usually we write out the
features that are going to be in the final version of a
product and then we allocate the team to all the
features. Sometime in the long-term future we get
together and put it back together. When your aim is to
deliver some of the functionality early, you can’t
organize tasks like that. You have to prioritize the
features up front in development and work mostly on the
essence of the system. And then once you have the
essence of the system down, you can work on the other
features."
MacCormack recognizes that
there is likely to be resistance to the idea of starting
development before having a complete specification. But
in highly uncertain environments, particularly,
MacCormack feels that the greater danger is that,
"You can create the whole [product] and find no one
wants it." MacCormack found that, on average, the
software projects he studied were first tested with
early beta versions that had about 70% of their full
functionality.
In order to move toward a
more flexible process, incorporating the evolutionary
delivery model, MacCormack suggests the following
approach: "Take your typical project and identify the
point at which you first get meaningful, high-fidelity
feedback on the performance of the product, in the end
use context, and then say, ‘what is to stop us getting
that feedback half as early again?’ By asking this
question, you identify the main obstacles that you need
to work on to get your process to be more
flexible."
Four Key Elements of
Fast and Flexible Design
In addition to the
evolutionary delivery model, MacCormack’s work has
identified four constructs that underlie a more flexible
process.
- Generating
information during development – particularly from
customers
- Responding to that
information during the development process – and not
in the next ‘rev’
- Integrating the
team around the new models of flexibility and
responsiveness
- Architecting the
product for rapid responsiveness
Generating
One of the most important
skills in the domain of flexible processes is the
ability to generate new information. "The biggest
lesson we discovered from this research, and the other
case examples we’ve had from non-software industries, is
the concept of breaking up a project into milestones and
getting interim feedback on the performance of the
design as much as possible…front loading that
feedback…finding out information as early as possible in
a project," says MacCormack. The ideal, he claims,
is a version of the product in the hands of customers.
"There are certain types of products where
limitations prevent that from happening, so then you’re
really looking for the next best high fidelity feedback
you can get...in the end market context."
Responding
Once a conduit has been
created between the customers, the performance of the
design, and the development team, the next step is to
build responsiveness to that data into the process. The
idea here is to reduce the time between receiving the
feedback and the design of new tests that will provide
even more information. MacCormack’s research suggests
that it isn’t the aggregate experimental capacity that
is the key element, but the ability to get feedback
rapidly and to turn that feedback into new design
experiments – and new designs. MacCormack suggests that
companies invest in infrastructure that allows them to
create value from the stream of information they
generate from customers.
Integrating
Integrating the stream of
information created by a flexible process is no easy
task. It requires a team structure that will allow the
right decisions to be made on the fly. One way this is
done, according to MacCormack, is to pinpoint one person
with the role of integration. This point person will be
responsible for making the hard decisions regarding
triaging features, deciding which bugs most need fixing,
and sequencing tasks. "In a traditional process,"
explains MacCormack, "most of this is figured out
ahead of time, so there is less need for this role. In a
flexible process, you are going to have to make
real-time decisions…Somebody anointed with that
responsibility is needed because [now] you’ve got those
big decisions to make."
Architectural
Design
According to MacCormack’s
findings, product performance and process flexibility
are intertwined through their relationship with the
product architecture. Observes MacCormack, "In a
normal project, when no one cares about flexibility,
engineers will come up with spectacular solutions that
tend to be very hard to change." In many cases, the
most efficient design is one in which sub-systems are
coupled together tightly. But, in a flexible process,
says MacCormack, "I don’t want the best performing
design if it means I have to wait a year. I actually
don’t mind giving back a little of the theoretical in
exchange for being able to demonstrate a part of this
product a third of the way through the
project."
The key, according to
MacCormack, is to view product architecture not from the
standpoint of design but from the standpoint of rapidly
creating a partially functional early version of the
product. The question, says MacCormack, is to focus on
the point at which an early beta version can be made
available. If this time-to-first-beta can be
reduced by 50%, the design implications are such that
"it will force a series of decisions on people in
terms of the architecture."
Finally, MacCormack also
found that changing the culture, from a "freeze the
spec early," "late changes are always bad"
mindset, to a fast and flexible mindset, is probably the
most difficult thing. It’s very difficult for many
developers to swallow the idea that design changes could
be "good." But design changes can be the life’s blood of
a successful flexible process, "because,"
concludes MacCormack, "it means you are reacting to
information you receive. In [more traditional] processes
you just ignore it."
This article originally appeared in the
August 2003 issue of PDBPR
To join our e-mail
list and receive future updates on "Fast & Flexible"
techniques, click
here.
|