FYI: Magazine article: Meet the Access Team

L

Lyle Fairfield

Larry said:
Never trust an unannounced schedule. At a minimum, mistrust any schedule,
announced or otherwise, unless it is in a contract which contains provision
for "liquidated damages for late delivery". <GRIN>
Click to expand...

Clipper's "Aspen" is 16 years late, and counting.

But I STILL want it!

That and Kim Novak ....
 
S

Steve Jorgensen

Clipper's "Aspen" is 16 years late, and counting.

But I STILL want it!

That and Kim Novak ....

--
Click to expand...

With Kim, there's always a sliver of hope, eh?

Seriously, there are ways of delivering software on time, and there are people
doing it. Just work in small iterations such that there's something that
could hypothetically be delivered at the end of each iteration. Now, measure
how much actually gets done per iteration on average, and plan based on that.
Make sure that the features are prioritized top-down so that features that
might get left off at the end are optional. If the schedule slips, the
release doesn't have to.

A key point is that each iteration must be complete and deliverable, so no
matter what happens, -something- could be delivered at any time. Testing
can't wait until the end, and deployment and installation can't wait until the
end. At the end of the first iteration, you may have nothing more than "Hello
World" that passes all tests and can be successfully deployed and installed.
Just that is an excellent start.

Now for the surprising part - it looks like Microsoft might be starting to
adopt a methodology similar to what I just described above. In up-coming
generations of MS software, we might miraculously start seeing products
delivered on schedule.
 
L

Larry Linson

A key point is that each iteration must
be complete and deliverable, so no
matter what happens, -something- could
be delivered at any time.
Click to expand...

Yep, I've seen that done, too... long before the current fad. I called them
"featureless releases", because to release -something- on the committed
date, they often had to remove everything of any value. Fortunately, it was
not on any project of which I was a part.

Most of my clients, individually or client of someone I worked for, would
have stood still for a "Hello World" release. We'd have been out of there
skidding across the asphalt of the parking lot on our rumps before you could
say, "but we did release -something- on the committed date".

Larry
 
S

Steve Jorgensen

Yep, I've seen that done, too... long before the current fad. I called them
"featureless releases", because to release -something- on the committed
date, they often had to remove everything of any value. Fortunately, it was
not on any project of which I was a part.

Most of my clients, individually or client of someone I worked for, would
have stood still for a "Hello World" release. We'd have been out of there
skidding across the asphalt of the parking lot on our rumps before you could
say, "but we did release -something- on the committed date".
Click to expand...

I don't think you got my whole point. Hello World had better be in
deliverable condition after iteration 1 in say, 2 or 3 weeks. After each
subsequent iteration, more value is added. From that point forward, features
are added in order of difficulty and priority so that the hardest and the most
valueable stuff is done first.

Obviously, valuable stuff is done early so that it will be sure to make it
into the release. Hard stuff is done early so the measurements of velocity
will tend toward pessemistic, not optimistic when, after the first 3 or 4
iterations, you re-evaluate what's likely to fit in by the release date.

If there's any feature that has an estimated time to develop of more than
about 1/2 an iteration, you need to figure out how to divide it into phases
with real added value in phase 1, so you never leave valuless, half-done code
in at the end of an iteration. If you have 9 months for a release, that's
about 12 iterations worth of work.
 
T

Tony Toews

Steve Jorgensen said:
Seriously, there are ways of delivering software on time, and there are people
doing it. Just work in small iterations such that there's something that
could hypothetically be delivered at the end of each iteration.
Click to expand...

That's what I do except I do deliver something which each iteration.
Which can be hours or days of work in length.

Ultra Frequent Application Deployment
http://www.granite.ab.ca/access/ufad.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
A

adsl

Larry Linson said:
Never trust an unannounced schedule. At a minimum, mistrust any schedule,
announced or otherwise, unless it is in a contract which contains
provision
for "liquidated damages for late delivery". <GRIN>

In a previous incarnation, I personally observe a major PC software
suite's
announcement cancelled one (yes ONE) day before the planned official
announcement. (In the course of time, all, or almost all, the software
products that would have been included in that announcement were
cancelled.)

Larry Linson
Microsoft Access MVP
Click to expand...
 
A

adsl

Larry Linson said:
Yep, I've seen that done, too... long before the current fad. I called
them
"featureless releases", because to release -something- on the committed
date, they often had to remove everything of any value. Fortunately, it
was
not on any project of which I was a part.

Most of my clients, individually or client of someone I worked for, would
have stood still for a "Hello World" release. We'd have been out of there
skidding across the asphalt of the parking lot on our rumps before you
could
say, "but we did release -something- on the committed date".

Larry
Click to expand...
 
A

adsl

Steve Jorgensen said:
I don't think you got my whole point. Hello World had better be in
deliverable condition after iteration 1 in say, 2 or 3 weeks. After each
subsequent iteration, more value is added. From that point forward,
features
are added in order of difficulty and priority so that the hardest and the
most
valueable stuff is done first.

Obviously, valuable stuff is done early so that it will be sure to make it
into the release. Hard stuff is done early so the measurements of
velocity
will tend toward pessemistic, not optimistic when, after the first 3 or 4
iterations, you re-evaluate what's likely to fit in by the release date.

If there's any feature that has an estimated time to develop of more than
about 1/2 an iteration, you need to figure out how to divide it into
phases
with real added value in phase 1, so you never leave valuless, half-done
code
in at the end of an iteration. If you have 9 months for a release, that's
about 12 iterations worth of work.
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

A couple questions BEFORE using Office 365 0
popularity of Access? 19
Spec-ing SQL Server Box For Small Work Group? 3
Any consensus on stability/readiness of Access 2007 runtime? 50
Bulk Email Directly from Access 3
Access 2007 Runtime problems 4
visual studio team suite use with Access? 4
Project Online Timesheets Actuals Mismatches - data not publishing to projects 0

Top