Start immediately with things to do, versus make a plan, then carry it out.

[Dead video link removed]
----
''I saw the video as a comparison of approaches, not an oversimplification. Using either approach requires some thought about what is perceived to be a desirable and acceptable product. Where projects fail, the clarity of this perception is often to be blamed. To overly plan before starting, or to start without a precise plan are secondary to clear vision and anticipation of what environment will exist when the product is ready for release. It would be a GoodThing if good predictions were common rather than rare and if the future would be formed in an orderly fashion, rather than as a reaction and adaptation to rapid change and to a chaotic environment. It isn't easy to determine what you need to make, let alone how to make what does not already exist (or nearly so), and will meet future needs.'' 

An eloquent argument, and nicely made. Perhaps the reaction and adaptation to chaos could be reduced by a product providing the solutions that short circuit the chaos in the first place. Is this not what analysis is for? To determine the shape and consistency of such a product? To know what the current needs are and to reasonably predict future needs and how to address them? To analyze the shortcomings of the products currently available, the solutions being provided by competitive products, and the approaches not yet employed in those products?

All of this points right straight back at pre-project planning before any actual development is done. We have to be able to describe what we are making and what its limits are. Without setting boundaries before work begins we'll never know if we can accommodate the latest change request nor if, ultimately, we have successfully built a product at all.
----
CategoryAgileMethodology