Hi Mike and John,

Hey, Great book so far. I'm looking forward to reading it all the way
through.

Here's my feedback on chapter 1.

1) I think you should emphasise that the way you describe Critical
Path / Gant approach is closely related to the use fo the Waterfall
approach. That is, agile challenges (at least) 2 major paradigms:
the project management paradigm and the software development paradigm.

2) Since the two are tied so closely together I think you need to
include the big problems caused by the waterfall approach -
(a) high risk of late integration failure,
(b) bloated software with many low low priority features included
(c) many features missing because they weren't learnt about until
the project progressed and were rejected as change controls
(d) the customer doesn't get any return until the end of the first
(long) phase.

3) If you include 1. and 2. then it makes your arguement stronger
because chapter 2 is more complete (e.g. deliverying finished software
reduces the risk of late integration failure; delivering in prioritised
iterations allows cash flow / roi and reduces the likelihood of bloated
software; being able to reprioritise often means that important
features that are learnt about by doing the project are included. It
might help, when you talk about local safety, if you included the
long-tailed distribution curve ala Goldratt. You might also want to
distinguish between a developer giving an estimate (which is the
expected value based on the distribution curve) and giving a
committment (which is the 90 / 95% safe answer ). I don't think you
should say that we "add" local safety because that implies (to me)
that there is a correct estimate but we add more on. It's better to
say that we give a safer estimate.

4) There are some other important reasons why plans go wrong:
a) they don't include many tasks that have to be done - in
particular, they often don't include the tasks we have to do if a big
risk actually occurs
b) most project managers tend to commit to an agressive schedule,
which by definition has a lower chance of success
c) many plans don't level resources - so they often include staff
working 100% on several tasks at the same time d) change happens and
often causes scope creep and/or rework but the plans are based on the
original plans.

5) Could you end with DeMarco and Lister's "cummulative chance of
completion distribution curve" (I've made the name up because I don't
have their book handy but it's the one that shows (e.g.) 5% change of
completing in january, 10 % by february, 20% by march ...). That
curve basically sums up your arguement: the plan may look predictive
but it's not.

Clarke