Hi,
I was reading the Wheel of Time series (forgive me, but I am fascinated
with the Fantasy Genre. Apart from the story, there are some wonderful
quotes there!) yesterday night in which a character has 4 rules
regarding information and action:
1. Never make a plan without knowing as much as you can (of the enemy).
2. Never be afraid to change your plans when you receive new
information.
3. Never believe you know everything.
4. And never wait to know everything. The man who waited to know
everything was still sitting in his tent when the enemy burned it over
his head.
I felt these would be good rules to talk about when discussing Agile
planning.
Regards
Sridhar
"A lot of preconceptions can be avoided by simply trying them out" - Bruce Eckel

Sridhar wrote:
1. Never make a plan without knowing as much as you can (of the enemy).
2. Never be afraid to change your plans when you receive new
information.
3. Never believe you know everything.
4. And never wait to know everything. The man who waited to know
everything was still sitting in his tent when the enemy burned it over
his head.

I felt these would be good rules to talk about when discussing Agile
planning.

How do you reconcile #1 and #4? Where is the dividing line between "as
much as you can" and "everything?"

7/15/06, George Dinwiddie <lists (AT) idiacomputing (DOT) comwrote:

Sridhar wrote:
1. Never make a plan without knowing as much as you can (of the enemy).
2. Never be afraid to change your plans when you receive new
information.
3. Never believe you know everything.
4. And never wait to know everything. The man who waited to know
everything was still sitting in his tent when the enemy burned it over
his head.

I felt these would be good rules to talk about when discussing Agile
planning.

How do you reconcile #1 and #4? Where is the dividing line between "as
much as you can" and "everything?"

We're lucky, we are just developing software. We get to use feedback to
find out where the dividing line is. That's why we have short iterations.
So if we waited to long this iteration. Instead of our tent getting burned
down over our head. We might deliver a few less features, because spent too
much time detail gathering, instead of just making the plan for the story,
or task or whatever. If we undershoot the line, the story might not pass
Customer Acceptace tests.

I'm certain that the man that lived by those rules knew where his dividing
line was based, on the feedback of many battles.

The one thing that we have to remember when comparing what we do to what
warriors do is: The problem is the enemy.

Sun, 16 Jul 2006 02:09:29 -0600, "Brandon Campbell"
<brandonjc (AT) gmail (DOT) comsaid:
7/15/06, George Dinwiddie <lists (AT) idiacomputing (DOT) comwrote:

Sridhar wrote:
1. Never make a plan without knowing as much as you can (of the enemy).
2. Never be afraid to change your plans when you receive new
information.
3. Never believe you know everything.
4. And never wait to know everything. The man who waited to know
everything was still sitting in his tent when the enemy burned it over
his head.

I felt these would be good rules to talk about when discussing Agile
planning.

How do you reconcile #1 and #4? Where is the dividing line between "as
much as you can" and "everything?"

We're lucky, we are just developing software. We get to use feedback to
find out where the dividing line is. That's why we have short
iterations.
So if we waited to long this iteration. Instead of our tent getting
burned
down over our head. We might deliver a few less features, because spent
too
much time detail gathering, instead of just making the plan for the
story,
or task or whatever. If we undershoot the line, the story might not pass
Customer Acceptace tests.

I guess I missed George's mail :(

The idea is to gether as much as possible *now*. If you have a customer
explaining a story, get as much details as possible. Don't wait till he
confers with his *entire* organization, getting everybody's approval and
so on. I would interpret the rules in that way.

Again, I also believe that if knew the rules intuitively, the apparent
contradiction would resolve itself. Same concept as in some Eastern
teachings, I guess [ <chuckle>or some of Ron's Signatures</Chuckle].

Regards
Sridhar

"A lot of preconceptions can be avoided by simply trying them out" - Bruce Eckel

Contradictions in requirements *could* (should, if they get that far)
show up in acceptance tests or unit/programmer tests getting one
requirement to pass should make one (or more) tests related to the
other requirement fail.

This is rather "late" in the process, but it is within one iteration
of the implementation of the contradictory requirement -- 1 to 3
weeks. Compare to traditional "unconscious waterfall" where testing
doesn't start until near the end of the project, and manual
test-and-fix would make the contradiction less obvious.

7/18/06, Sridhar <sherlocksridhar (AT) fastmail (DOT) fmwrote:
Sun, 16 Jul 2006 02:09:29 -0600, "Brandon Campbell"
<brandonjc (AT) gmail (DOT) comsaid:
7/15/06, George Dinwiddie <lists (AT) idiacomputing (DOT) comwrote:

Sridhar wrote:
1. Never make a plan without knowing as much as you can (of the enemy).
2. Never be afraid to change your plans when you receive new
information.
3. Never believe you know everything.
4. And never wait to know everything. The man who waited to know
everything was still sitting in his tent when the enemy burned it over
his head.

I felt these would be good rules to talk about when discussing Agile
planning.

How do you reconcile #1 and #4? Where is the dividing line between "as
much as you can" and "everything?"
--
We're lucky, we are just developing software. We get to use feedback to
find out where the dividing line is. That's why we have short
iterations.
So if we waited to long this iteration. Instead of our tent getting
burned
down over our head. We might deliver a few less features, because spent
too
much time detail gathering, instead of just making the plan for the
story,
or task or whatever. If we undershoot the line, the story might not pass
Customer Acceptace tests.

I guess I missed George's mail :(

The idea is to gether as much as possible *now*. If you have a customer
explaining a story, get as much details as possible. Don't wait till he
confers with his *entire* organization, getting everybody's approval and
so on. I would interpret the rules in that way.

Again, I also believe that if knew the rules intuitively, the apparent
contradiction would resolve itself. Same concept as in some Eastern
teachings, I guess [ <chuckle>or some of Ron's Signatures</Chuckle].

Regards
Sridhar

"A lot of preconceptions can be avoided by simply trying them out" - Bruce Eckel