>>Useless answer: All agile processes are supposed to accept change, so "cast in stone" and "agile" don't work together. :)
>
>You are preaching to the choir!! <g>

That's why I said "useless answer" :)

>>One "solution" I heard of for this kind of problems: Have an official schedule for the upper management and a real one for development.
>
>Won't work here. Our director (my direct report) has his fingers firmly implanted in the schedule of all the Teams under him.
>
>~~Bonnie
>
>
>
>
>>Useless answer: All agile processes are supposed to accept change, so "cast in stone" and "agile" don't work together. :)
>>
>>One "solution" I heard of for this kind of problems: Have an official schedule for the upper management and a real one for development. As long as you can convince the upper management that you accomplished what you were supposed to do in each iteration and you finish everything on time overall, you're fine. I've never been on such a project, so I can't tell you how that works exactly. :) I guess the team lead or whoever takes care of the relation with the upper management has to be smart enough to be able to keep the double accounting books. :)
>>
>>My personal approach to rigid schedules is to tell my manager/architect/etc only what they really have to know (they never want to know all details :) ) and organize my work on my own. And if I'm a few days early I can pick up something from the next iteration and work on it and if I'm a little bit late... too bad. Somehow, I'm always ahead overall, so I don't stress myself too much about the official schedule.
>>
>>Vlad