Comments - On Planning - Agile Philly2024-03-28T14:48:35Zhttps://agilephilly.ning.com/profiles/comment/feed?attachedTo=3783271%3ABlogPost%3A2866&xn_auth=noKeith, I like your conclusion…tag:agilephilly.ning.com,2010-08-18:3783271:Comment:31512010-08-18T13:48:49.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
Keith, I like your conclusion. This is what I was trying to say that one should form a regular short term delivery schedule and then be ready to absorb change instead of making year long plans.<br />
<br />
I guess I was also saying was that to help you do this you have to change the supporting structure for your employees. So to properly facilitate short term planning an organization should make all other aspects of its working short term, for example: instead of yearly employee review, do it based on…
Keith, I like your conclusion. This is what I was trying to say that one should form a regular short term delivery schedule and then be ready to absorb change instead of making year long plans.<br />
<br />
I guess I was also saying was that to help you do this you have to change the supporting structure for your employees. So to properly facilitate short term planning an organization should make all other aspects of its working short term, for example: instead of yearly employee review, do it based on your delivery schedule; instead of yearly budgets do shorter cycle budgets.<br />
<br />
Obviously you can't short change the vision that you want to achieve, so keep that big vision alive, but reach it using small increments.<br />
<br />
I do like your conclusions. This analogy tells me two thi…tag:agilephilly.ning.com,2010-08-17:3783271:Comment:31382010-08-17T16:21:09.000ZKeith Kendallhttps://agilephilly.ning.com/profile/KeithKendall
This analogy tells me two things:<br />
<br />
1. The incremental benefit of pushing out the planning horizon rapidly diminshes.<br />
2. Kasparov brought something to the game that the software didn't. And that something was nearly greater than the value asymptotically approached by pushing out the planning horizon to, essentially, infinity.<br />
<br />
I think that in the analogy you're equating extensive planning with reduced feedback. That was not the case in the chess matches. Each player benefitted from exactly the…
This analogy tells me two things:<br />
<br />
1. The incremental benefit of pushing out the planning horizon rapidly diminshes.<br />
2. Kasparov brought something to the game that the software didn't. And that something was nearly greater than the value asymptotically approached by pushing out the planning horizon to, essentially, infinity.<br />
<br />
I think that in the analogy you're equating extensive planning with reduced feedback. That was not the case in the chess matches. Each player benefitted from exactly the same feedback cycle (1 move of their opponent) and exactly the same planning cycle (also 1 move of their opponent, at which point they could replan).<br />
<br />
In my opinion, what Kasparov might have brought to the game was a better ability to anticipate his opponent's moves and, therefore, a better ability to avoid the local optimization pitfall. If I correctly recall the story, that's what eventually resulted in Kasparov's defeat. They programmed in an analysis of his entire playing history so that the software could better anticipate his moves and weight it's exhaustive planning analysis accordingly. Essentially, they customized the software...not to play better but to beat a single player.<br />
<br />
What does this tell us that might be of use to Agile/Lean practitioners? Maybe that once you've found that optimal feedback cycle, knowing the terrain (i.e. your client, the marketplace, etc.) well enough to anticipate their needs and the changes they'll request is more important than extensive planning.