The
customer wanted an on-line currency exchange capability added to
their on-line financial service offerings. They figured it would
take several months to implement. But the development team
suggested a different approach: start by hiring a dozen telephone
operators and implement the necessary software for these folks to
execute currency trades. The company gave it a try, and in six
weeks the first iteration was ready. With no more than an 800
number on their web site and a rudimentary interface to the currency
market, new business was being transacted and profits being made.
Over the course of
the next several months, the on-line trading capability was
implemented around the core module originally used by the telephone
operators. Not only did the company see early revenue, but the risk
of failure disappeared once trading started. In addition, system
requirements were defined by observing real trades.
In the book Software
by Numbers – Low Risk, High Return Development (Prentice Hall, 2004)
Mark Denne and Jane Cleland-Huang make the case for incremental
delivery of software. Mark Denne developed the Incremental Funding
Methodology (IFM) in the 1990’s to help land a large software
development contract. In an attempt to distinguish his bid from the
pack, he reorganized the deliveries into units of value, and
adjusted the development sequence so that the customer would realize
revenue faster and in the end, receive a greater return on their
investment. The customer discovered that this approach dramatically
reduced their need to borrow money and gave them earlier product
release with lowered risk. In what seemed like hotly competitive
bidding process, Mark’s company won the bid by emphasizing “time to
value” instead of development efficiency.
Software by Numbers
recommends dividing a project into Minimum Marketable Features
(MMF’s). These are small feature sets which deliver some
identifiable value to the customer. Each MMF should have its own
return on investment (ROI). By laying out the potential ROI’s of
various feature sets, an optimal development sequence for the MMF’s
can be determined. Early deployment of key MMF’s reduces risk
while generating revenue to help fund the remainder of the project.
When business people
and software developers focus on identifying and valuing marketable
features, their conversation is changed. Developers are exposed to
ROI and stakeholders are confronted with the realities of software
development. The entire team is focused on achieving business ROI
early in the development cycle. Management sees continuously
measurable progress, and the team benefits from the early and
compelling feedback generated by real software being used in
production.
With so many
benefits, why wouldn’t IFM be the preferred approach for developing
software? Denne and Cleland-Huang note that many practitioners view
software architecture as a monolithic whole, requiring early
definition because of the extensive impact that architectural
changes can have on a system. On the other hand, they argue, it is
not until the details of an architecture are implemented that one
can tell if the architecture is viable. Thus architecture presents
us with a chicken and egg problem.
The book recommends
that architectural elements which support each set of MMF’s should
be developed with their respective MMF’s. In other words,
architectural development should be sequenced using the same
financially driven priorities as feature development. While there
may be times where architectural coherency may dictate early
development of features not immediately related to the current
feature set, in general it is not only possible but also preferable
to defer implementation of architectural elements until the features
requiring these elements is being developed.
As we discover that
architecture not only can evolve, but in fact, in any deployed
system, the architecture will evolve over time, the view that
architecture must be fixed early in the development process becomes
a liability. This is a view that creates architectures that are not
tolerant of the change they inevitably must undergo. Once we accept
that software architectures must be designed to be change-tolerant,
the barrier to early deployment of high value features is lowered.
Returning to the
currency trading example, we see that early deployment of marketable
features is a compelling strategy for increasing return and reducing
risk. At the same time the stage is set for a better understanding
of the real system requirements and improved collaboration between
developers and their customers.
The book:
Software by Numbers: Low-Risk, High-Return Development
by Mark Denne, Jane Cleland-Huang, Prentice Hall, 2004
