

Cases Against Applying Schedule Pressure - martincmartin
http://www.stickyminds.com/sitewide.asp?ObjectId=9947&Function=DETAILBROWSE&ObjectType=COL

======
zts
While the title of this article is misleading (it's really about
communication, not scheduling), it is food for thought.

Though I can't help but boggle at the author encouraging a team to abandon all
milestones/deadlines in the pursuit of quality. While perhaps the given team
really was looking for a convenient excuse for any quality problems, I can't
help but look at it as pragmatism.

"Take all the time you need - but make sure it's perfect," is a good way to
discourage completion.

------
bluishgreen
Quality can only be attained by employing quality people. Just by giving folks
more time will not automatically turn into quality product. Many times quality
people do not require more time to make a better product. They just need to be
left alone.

Having said that Quality people are also people. People need deadlines or else
will fall victim to student syndrome (all assignments and projects are done
last 2 days before the deadline, refer
<http://bookoutlines.pbworks.com/Predictably-Irrational> Title: Problem of
procrastination).

Quality people loving what they do, need to be put on deadlines which they
agree to as being reasonable. The business should for the most part function
around these deadlines. When a customer imposed hard deadline shows up on the
radar, a healthy conversation should settle the acceptable quality/feature
cuts to meet it.

The essential task of the leader is to make such sudden showing up hard
deadlines as minimal and as far apart as possible through insight and
foresight. The quality of the leader can be directly judged using the number
of such deadlines that prop up in a given span of time.

------
thwarted
_They'd say, "We want to be this far along by July," or "By August we need to
be able to handle these types of transactions." I'd ask them how they'd
established those deadlines. The answer was always the same: No businessperson
had asked for a specific amount of progress by a specific date, but the team
had decided how far along it needed to be at various checkpoints to feel good
about the overall progress._

It's unfortunate that the author had this awesome insight, and then went off
on a tangent about people being more comfortable with schedule pressure than
with quality pressure.

"Feeling good about the overall progress" as presented above isn't schedule
pressure, it's a measure of quality and efficiency. "We want to be this far
along by July" is a way for the team themselves to gauge if, for example, they
are spinning their wheels doing the wrong thing (because it's taking too long,
because it's too hard, because it's not broken down into subtasks properly,
whathaveyou), which directly relates to quality. As this "deadline"
approaches, one can judge if with greater accuracy if it's going to be made.
And since these "deadlines" are not hard and fast, or at least not as hard and
fast as if some business person had set them, tweaking them is less work and
less upsetting. Don't think all seven of the transaction types are going to be
done by August? Scale it back to five, work on getting it into a state where
these five can be handed off to the next team to work on the next part and
build it such that new transaction types can be added later so more people can
work in parallel. Dependency handling (with the core dependency getting the
project in a shippable state within a reasonable amount of time) is the reason
schedule pressure exists in the first place.

I've often had to say to my team "We seem to be spending a lot of time on X,
and are close to [or past] the initial estimates for completion. Are we doing
the right thing here? What else are we going to have to cut? What do _you
want_ to cut? Is it too complex, and can we simplify it?". Too often, even the
list of things (features) that need to be in the final product are determined
externally (read: by business people), without any input from the people who
are actually going to do be doing the work. The implementing team should be
involved in both the feature list and the schedule (a regular topic on HN).
I've been on both sides of the table too many times where there is a
"technical" resource included in the scheduling planning/meetings just for
show and their insight and participation is discouraged, usually because
promises have already been made and the planning meeting is just a big Tetris
game, an attempt to fit a bunch of lines and shapes into a fixed size box.

That all being said, bluishgreen's comments about revolving around the
customer are spot on too. A lot of that comes down to handling expectations.
In my experience, schedule pressure is often the result of improperly used
Gantt charts. Gantt charts should be living documentation used to answer
questions about scheduling and dependencies, not a static bible to be used to
browbeat people (both the implementors and the customer) into buying into some
fantasy dates.

------
fnid
One of the problems with no schedule pressure, which I believe is best, is
that software can always be better. Clicks can be removed. User interfaces can
be made cleaner and easier to look at.

To remove the schedule pressure, you have think differently. Instead of, "This
project is done on Friday," Think, "This project is done when no one has
complained about this form for 3 weeks." This project is done when no bugs are
reported for 4 weeks. Etc.

------
j_baker
I agree with this. Nine times out of ten, schedules tend to be arbitrary
guesses anyway. I don't know if I agree that scheduling pressure should be
totally removed, but I feel that a lot of organizations place it too highly
compared to other pressures.

