An
agile
process creates plans
as needed and
allows teams to self organize directly around a
problem. We must trust our process to keep our project on
track, but there is a paradox associated with any process:
If you don't use your process it can't help you; if your process
doesn't help, you won't use it.
I use a personal digital assistant (PDA) or
handheld organizer as a metaphor. You want your PDA to alert you every
time you have
a meeting. But right out of the box that PDA won't alert you to
anything. You must move all your appointments onto it. But
even more than that your PDA comes with a hidden process: You
must constantly keep it up to date. You must enter every
appointment with out fail. If you don't it will fail to
remind you.
A
PDA is a tool that helps implement the hidden process of writing down
every appointment in one place and then checking for
appointments regularly. You could use a pencil and a
paper calendar to implement that process and get most of the benefit.
It's
that hidden process that's important, not the implementation.
People
have told me their software process is
Rational Rose(TM).
Rose
is a UML tool, not a
process. Installing an automated build tool instead of a real
continuous
integration process is another common mistake. Never confuse having
a tool with actually having a process.
|
The obvious consequence of the paradox of process is that when you
begin a new process
it seems totally useless and a waste of
time. You
need to have faith and really use the process until it begins to return
on your investment.
Unit
testing is a prime example. The graph
|
below shows the number of
unit tests for the EarlyPay
project at InStream Financial Services. It
was a large system that didn't have unit tests yet. We added tests when
we
added new features and fixed bugs. After a
year there were no bugs in
production anymore. The big pay off came after two years when we had
complete coverage
and could confidently redesign the system. We simplified and removed
about one third of the code while maintaining a perfect record of no
production bugs.
Many of the rules and practices of Agile processes seem like a waste of
time when you start them. It takes time and patience to get to a point
where they begin to help you in unexpected ways. |
|
|