Agile versus Waterfall
Either method taken to the
extreme will have undesirable consequences. They are not
mutually exclusive; you can design your process to utilize
the best of both. Agile cycles are possible within a larger
waterfall context, and waterfall workflows can be executed
within an agile cycle. Watch our video and decide for
yourself.
Watch the Agile Waterfall video in Quicktime or MP4 formats.
Lightweight Peer Reviews
Most companies think of
Quality Assurance when they think of Software Quality.
However, when a client has a huge number of field defects,
it is unlikely that this is due to a failure in the QA
function. The reason is that you cannot test quality into
the product; you have to build a quality product and then
use QA to verify that you did. At one company we identified
that there was little effective review of other developer's
work products. We defined a lightweight review process
which chose a method based on the risk that the development
artifact carried. For low risk items, a peer review from
one other capable person was sufficient. For high risk
items, we defined the process to be a "Team Review" as
defined by Karl E Wiegers in
Peer Reviews in Software.
The result was a release with about 50% fewer defects
than the previous release. Moreover they went 8 weeks
after the release without requiring a hot fix, which was
unheard of for that organization.
Architectural Control
A software development
organization without accountability and responsibility for
controlling the architecture of the product is one which is
likely to develop a product without a cohesive high level
design. At his company we put a review board in place along
with a system to ensure that visibility across the
organization was given to those developments which required
change in the architecture. The result was better
communication and fewer surprises, as well as a document
that new hires could read to understand the entire system
before delving into the code.
