plan – In Search Of

Fidelity is truth. In software projects we need to know how much “truth” is
in the plan and how much “fiction” might be in the plan.

We know that the more detailed the wbs, the greater probability that it is
truth, rather than fiction. The exception to this involves documenting
heuristic tasks and estimates in detail in the plan. Only document the
actual tasks representing the real work in detail, rather than fictitious
tasks that will be replaced with real tasks later.

The shorter the time span of a task, the nearer our ability to prove the
fidelity of the estimate.

in order to realize this ability, I also need to measure frequently,p
relative to the mean duration of tasks in the plan. That is, I should
measure every time a few tasks are completed, so that any propensity toward
fiction in the estimates can be observed and biased.

Reaction time breeds agility. The shorter the project, the less time to
adjust. The less time to adjust, the more frequent the measurement must
be. The more frequent the measurement, the smaller the mean task duration
must be.

How you plan determines how quickly you will be able to react as fiction
leaks out of your plan.

Sometimes it’s really beneficial to get a team all on the same page
before you start something. Starting a design initiative for a
software project is a good time to do this. One good way to get
consensus or at least to determine how far apart developers are
ideologically, is to document the assumptions that will guide your
design.

It is not really important how you document them, the purpose really
is to get the team to articulate and discuss and ultimately agree on
the values, methods, approaches, and ideas that will guide their
design (and ultimately their build process).

Laying out your assumptions before you try to make decisions could be
a great way to shortcut some of the inevitable disagreements caused by
unexposed differences in the religious beliefs held by software
developers. Software theology and design jihad go hand in hand.
Assimilating new members into a team, requires understanding their
religion, with a view to preventing heresy from creeping into your
designs, and ultimately your code base. Having to declare a jihad
against all things that violate layer isolation, or the normalization
in the conceptual domain model during the design review is a bad idea.
Better to get the differences out on the table early.

It also makes your documentation easier to read because the
assumptions need much less justification than the decisions you are
documenting, and frankly can get assimilated by new team members
faster. Most of the WTF’s in the design review meeting are really
poorly documented assumptions that one or another team member trips
over.

Most likely, though, the exercise will trip over semantics, and when
when you get down to the core values of the team, and what is really
important, good people agree more than they disagree, and they will
feel good about the things they agree on, and they will have a sense
of starting well, rather than a subtle dread of the design review,
expecting the “Here we go again…” approach.

Posts Tagged with plan

Fidelity

Assumptions