The centerpiece of the Nimble Method℠ is the way we
develop software, and it's a big reason we can confidently promise
to deliver on time, on budget and on target. It works. But
how does it work?
In addition to User Experience design to keep the software
user-centric, Function Point Analysis to accurately size the
project, and Project Management to keep things on track, we use a
best-of-both-worlds combination of Waterfall and Agile development
practices.
First, some background.
The Waterfall
method, first coined in 1970, is a traditional process in which
development follows a sequence: First, the client writes down all
of his requirements, then the technical architect translates those
into a tech spec, then developers write code, then testers execute
a test plan, and finally the client gets to see the finished
product.
Its disadvantages: documentation is extensive, sequential work
means looong timelines, a rigid schedule makes it difficult to
adapt to changes mid-stream, and the client is only involved at the
start and finish.
In the mid-1990s, a new method arose: Agile.
In this approach, the client, architects and developers work
collaboratively to iterate through a project in a series of
1- to 4-week cycles, called sprints, relying on the code itself to
guide the project rather than heavyweight documentation.
Its disadvantages: The unstructured path can devolve into
"cowboy coding," undefined requirements can lead to scope creep,
and it's well nigh impossible to predict up-front when the project
will end or what it will cost.
The StoneHenge approach:
Nimble Development
At StoneHenge Partners, we've tried both methods, with varying
degrees of success and heartbreak. Through trial and error (our
developers have an average of 15 years experience in IT, so we've
been around the block a time or two) we have put together an
approach that we are convinced combines the best of both
worlds.
We call it "Nimble Development."
This approach preserves the best of Waterfall:
- Fully realized requirements (we typically spend as much in the
planning phase as in the building phase)
- A well-defined timeline
- Tight change control
- A solid launch date.
Then we add the best practices of Agile:
- Breaking the work into 1- to 2-week iterations that run in
parallel instead of sequence
- Keeping the code user-centric through use cases
- Daily stand-up meetings ("scrums") in which the client
participates as a member of the team
This approach is a natural fit with Function Point Analysis. By
defining a project's functional components up-front, it is easier
to group functions into an iteration that organically produces a
working component -- a shopping cart component, for example, or a
business intelligence reporting component. Each Function Point
becomes a tracking metric to gauge progress of a component, and
thereby the project as a whole.
Parallel development is efficient
Finally, we discovered a bonus benefit: Assembly-line
efficiency. Take, for example, a 12-week, 3-iteration project. Here
is its timeline.
Notice the Business Analyst is finished with his tasks by Week 6
-- just in time for testing to begin. On small development teams in
which the same person fills both analyst and tester roles, this
means the analyst can begin testing Iteration 1 as soon as he
finishes defining Iteration 3. Because he understands the
requirements so well -- he wrote them, after all -- testing is more
accurate. He'll be testing not just the tactics -- "Does this
work?" -- but the strategy -- "Does this do what the client wants
it to do?"
The end result
A good case study of this process in action is a project we did
in 2008 for Dollar Thrifty Automotive Group. As outlined here, we used
User Experience design, Function Point Analysis, Nimble
Development, and disciplined project management. Despite mid-stream
changes to the business requirements that added 200+ hours of extra
work, the 2,044-hour project was delivered -- as promised -- on
time, on budget and on target.