I really like the idea of 'always thinking long term'. I think there's a couple of problems here: 1) Estimates are essential. We need them, even if they are r

I really like the idea of 'always thinking long term'. I think there's a couple of problems here: 1) Estimates are essential. We need them, even if they are rough. Most software is not rocket science. I like to think of software like 'construction' or 'plumbing'. Few things should be that-that complicated. Avoid complexity. Would you hire a guy to build you a deck if he told you he had no idea how much time and $ it would be? Nope. 2) Constant interaction is essential. Why? Because 'failure to understand requirements' is the #1 problem in software - always. The 'devil is in the details' and sometimes the smallest details matter. So, I think it's more about finding the right level of management and direction shifting. 2) Sprinting. I've found that without some need to hit interim milestones, software can just 'go on forever'. We, as Engineers have a proclivity to 'over design' very often. We write tons of code to accomodate false notions of performance. By 'sprinting' to meet a milestone we are forced to face the ultimate reality: time. After a sprint, I almost always recognize that several pieces of what I was trying to do are unimportant, and that other pieces are more important. Were I to have 'optimized' it would have been a waste.