|
 In
this article in the series on Extreme Programming, Pradyumn Sharma
discusses the merits of working with small releases, one of the
important practices of XP
Many projects (rather most projects) begin with
unclear requirements. Quite often, the customer is not fully clear
about what they require from the system, though they know their
business well (normally) and have a general idea of what they require.
In some projects, the organisation gets just
a page or two of written details of what are required from the system,
and they are expected to quote based on that. That, of course, is
the path to sheer disaster. Even when things are not so bad, the
requirements stated by customers are not entirely clear and are
subject to change.
The typical approach
So what does one normally do? You start discussions
with customers to understand their requirements and start documenting
them. In some projects you may be lucky and the customer may pay
you for this stage (though I think such customers and development
organisations are in a minority). In most projects this stage is
at your cost and risk, and you conduct a preliminary study of sorts
to give you enough indication of the size and complexity of the
project, and based on that, an estimate of the effort involved so
that you can quote.
When the formal requirements determination begins,
you start discovering more and more requirements. As an experienced
requirements analyst you start finding gaps in what customers tell
you, you ask more probing questions and discover various exceptional
cases and alternative scenarios, and you document even more.
Quite often, this becomes a very long cycle,
leading to a situation known as analysis paralysis. You gather requirements
and analyse them, only to find more areas and gaps to understand
and analyse. As you go further, many requirements that were understood
and documented in detail earlier seem to change. You go back to
them and something else seems to get changed too.
Hopefully, you get out of this mess at some time
(some projects get cancelled at this stage due to delays). Either
you or the customer gets sick of never-ending discussions and the
requirements are “frozen,” but only for the time being.
But you may have already consumed many weeks or months in this process,
without delivering any value to the customer.
You then do a thorough and detailed design. Then
your team starts development based on the specifications provided
and the requirements document. By the time they are ready to deploy
the system, many months have passed, and no value has yet been delivered
to the customer. But that is about to change soon. Or so you believe
and hope.
The dangers ahead
The next part of the story is very common and
yet comes as a surprise to most. The software that your team has
so beautifully crafted over many agonising months with heart-burning,
deadline-beating, late-night efforts and all, fails to impress the
customer. The reasons could be many:
- The customer “expected” some features
and behaviour from the system that you as the developer were not
even aware of.
n Nature of the customer’s business and
therefore their needs from the system may have changed during these
months, causing the earlier requirements to be not entirely valid.
This shatters the myth of the perfect watertight requirements document,
if you tried to achieve that.
- The customer does not like the user interface
of the system though you feel that it is the most appropriate
for the user. But who decides what is most appropriate for the
customer?
- There are so many bugs in the system that
the customer cannot use it until they are fixed.
- Customer is annoyed with the delay.
- Customer’s business priorities have
changed.
The list is potentially endless.
According to various studies conducted, a large
number of software projects get cancelled or remain unused by customers
(not fully used at least), for a variety of reasons such as poor
quality, delays, mismatches between expectations from the system
and its behaviour.
What is the solution?
Extreme Programming (XP) strongly recommends
adopting small releases as a key practice of software development.
Remember, XP is ideally suited for projects with unclear and changing
requirements (which happens to be true of most projects, as we have
seen).
With small releases you don’t aim for that
elusive water-tight requirements document, perfect understanding
of all the customer’s requirements (when even they don’t
always have), and a single big-bang delivery of a complex project.
How small a release should be? A month or two at the most. The smaller
the release cycle, the less the risks for both developers as well
as customers.
The first release caters to the most pressing
requirements from the customer that adds most value to them.
The customer puts the release to production use,
and gives you valuable feedback early about the expectations, user
interfaces, missing requirements, changes in requirements, etc,
which can be useful for the next release.
For all the subsequent releases, the customer
chooses those functionalities (user stories) that seem to add most
business value to them at that point of time.
Benefits of small releases
Working with small releases has the following
benefits:
- You get early feedback from the customer.
- Early feedback means that if any course correction
is required (in terms of priorities, user interface, performance,
robustness, or whatever), you can make that in time, and not after
many months of effort when it becomes too late to do so.
- The risk of wasted effort in software development
is reduced significantly, even if the customer’s business
needs or priorities change, as in each release you work only on
those user stories that add most value to a customer at that point
of time.
- You do not have to wait for the requirements
to be frozen (that may never happen anyway).
- Clarity on the requirements may evolve gradually,
both in the customer’s mind as well as in the developer’s.
As customers start using the system, they may get a better idea
of what will work best for them.
- The customer starts seeing early the value
from the system. Their confidence in the system grows and their
involvement, commitment and excitement about the system increases
(provided, of course, you are delivering quality).
- Avoids fancy-features-rich systems being developed.
- You and the customer both get a good idea
of project progress. There is concrete evidence to show what has
been achieved.
Contrary to what many people believe, most of
the practices, including small releases, work well even when requirements
are clearly understood, very well documented, and are unchanging.
You can still get big and early payoffs by working with small releases,
as you are able to measure progress in more concrete terms rather
than on a notion, are able to plan better, and are able to get early
feedback from the customer.
Pradyumn Sharma is the CEO of Pragati Software.
He is a trainer and consultant in the areas of Object-Oriented Analysis
and Design, Design Patterns, and Extreme Programming. E-mail: pradyumn.sharma@pragatisoftware.com
|
