Rich – Page 23 – In Search Of

Fidelity

Posted on February 1, 2011Leave a comment

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.

Assumptions

Posted on January 29, 2011Leave a comment

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.

Sufficiency

Posted on January 27, 2011Leave a comment

Sufficiency is a word that we don’t use very frequently. It has a high
correlation with enough.

In lean management circles, anything more than enough is waste.

So how much is enough? How good is good enough? How soon is soon enough?
How clean is clean enough? How fast is fast enough?

Often we reward people for going above and beyond the “call of duty”. Is
this not doing more than enough?

Marketing campaigns are specifically designed to encourage dissatisfaction
– to convince you that your current phone, car, service, etc is not enough.

They rely on the premise that the mere existence of “more” confers on you a
need or desire.

Your immunity to this is a predetermined criteria for sufficiency.

So here is my sufficiency question for the day. If I can get more for
less, can I also get less for even less? Why spend more for something
beyond sufficient?

A missing product role

Posted on January 24, 2011Leave a comment

Every product needs a champion. Trouble is, in the enterprise application
software space, sometimes this role is left unfilled.

Lately it seems like the enterprise space is dominated by project/program
methodology, more than software design methodology.

When your customer is the product owner, the team does not have a champion
to rally around.

With all the emphasis on cost and schedule (customer) who is the champion
of good ideas, of consistency, of integrity, of quality?

The customer certainly feels entitled to these things, but as a
non-practitioner, cannot lead us into practices that yield them.

Technical architect? Solution architect? Product manager? I think that
all these roles are defined too narrowly, and vested with too little
authority. I am looking for a champion – who takes on all comers to ensure
that the best decisions are made for the long term value of the product.

Productive communication

Posted on January 10, 2011Leave a comment

Sometimes I get e-mail at work where the thread consists of a long chain of
short messages, and in order to determine the needed response, it is
necessary to contemplate the thread from beginning to end. This is
especially heinous in corporations where required e-mail sigs and
disclaimers are chunky.

As each person adds their response, this contemplation becomes more and
more expensive.. Some times it almost feels like some folks are playing
ping-pong and responding just to get “the ball in someone else’s court.”

To make the conversation more productive, it would help to summarize the
conversation periodically within the thread – that alone would reduce the
processing time required by each participant. Take the extra 5 minutes to
clean up. It will bring the issue to conclusion faster.

Chicken and egg

Posted on November 3, 2010Leave a comment

I continually argue with myself about whether tools or process should come
first…

Adding process without tools makes it hard to enforce process rules,
implement consistently, or measure compliance.

Adding tools without clear process definition is also futile, as people
tend to use tools differently, and tools can impose limitations on process
that make later process improvements impossible without replacing tools.

— the balm here is to grow your own tools and process in concert. Build
just enough tool to bootstrap process, then evolve.

This requires the stomach to build tools, and not give up. —

Rest

Posted on September 1, 2010Leave a comment

This project has been a fight. Fighting with customers, fighting with the
team, fighting with the technology. I think everyone involved feels pretty
beat up.

At the end, I look at the accomplishment and say to myself – it’s getting
pretty good. I need a rest.

I want the customer to take advantage of the new capabilities that have
been added. I want the team to take some pride in their accomplishment.
I want us all to learn from this project.

But in order for that to happen, we need to rest; to soak things in; to get
a better perspective. I don’t know how other organizations do this, but we
do not – we roll quickly from one initiative to another.

We need to rest…. Zzzzzzzzzzz

Reality

Posted on June 14, 20101 Comment

Spent the weekend (really the last two weeks) preparing to engage some
business partners on a project whose plan got somewhat sideways.

Original estimates were smaller than really required. Requirements took
much longer to elicit because the business vision was not complete, nor
were all that participated invested in a vision.

There has been a lot of drama around this project, because business execs
felt deceived. While the project team felt like it had been
extraordinarily transparent.

Then someone said it. Business reality implied a fixed bid process. While
IT was working on a time and materials project.

It explains why business gets angry and hostile when we shed scope to meet
a date. Their reality is fixed bid.

Internal IT rarely does fixed bid estimates. There is no motivation. No
profit. We only ever bill what we spend. But what if we did? What would
we do with the profit?

Reality?

The sniff test

Posted on June 3, 2010Leave a comment

When someone asks you to do something different or unusual, it must pass
the “sniff” test. Is what this person is asking “reasonable”. Does the
accommodation represent a material departure from process/protocol/custom
that may/will have impact in other ways? Is it a one time deal, or setting
a new precedent? Is the cost worth the value? Are the motives behind the
ask straightforward or are there hidden agendas? Is this a setup? Is this
somehow compromising my integrity, justice, fairness, etc? Will this come
back to “bite” me later? Will this actually satisfy the requester?

Whatever sniff test(s) you want to apply. You apply them quickly in your
mind with history and experience as your guide. You reach a conclusion.
When the request fails the sniff test, you call “bullsh*t”!

Happy sniffing!

The plan

Posted on June 1, 2010Leave a comment

The plan is the set of steps to get to “done”. What happens when there is
not enough time or money to get to “done”?

We can stop and adjust the schedule – making more time. We can decide to
spend the money. We can decide that “done” means something different that
costs less or takes less time. Or we can keep going and hope we that
people will understand why we have failed.

The hardest part is that while we are deciding how to react to the
information that is not pleasant, we continue to spend time and money.

While people look for some cause of the “problem” – and try to deflect
culpability – they are/were somewhat responsible and now decisions must be
made. There is no problem. There is only new information, and with it,
the ability to decide differently.

Think of the effort to do some work on your home – when a project takes
longer, costs more, etc, you don’t usually duck and cover or deflect
responsibility – it’s your money, time and effort. You get what you pay
for – but software is less tangible, predictable, and permanent than your
house. You just decide….

And in those decisions is the plan….