[simplotek]

> The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.

It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.

So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?

[cassianoleal]

If the so called "standard approaches" are in the way of my delivering quality software, I'm absolutely going to call it out and do my best to change it. Most times, if that's impossible, the correct course of action is to leave rather than delivering poor quality.