Every traditional development team I worked with, in spite of numerous procedures set in order to ascertain progress, seems to act as if ''reflection'' should always take precedence over ''observation''. Lacking a better guide, most of their decisions give privilege to speculations about the future of the project.

	'''At the outset of construction''':	
	* They establish a set of secondary requirements for which they try to offer a systematic answer with sophisticated software layers. ("We'll surely need this too").

	* Betting on the stability of requirements as well as process, they define in advance for the project, long production phases that they carefully document.

	* Since in each phase they plan to validate ''after'' producing, they bet again that such productions will always be correct. According to their plans, the failure of a phase is unthinkable.

	'''During construction''':	
	* Being not provided with the best covering test suite, they validate the software product partly on an act of faith. ("It should work now").

	* They let an enormous MaintainabilityDebt accumulate, either pretending they'll always be able to reduce it during a big "spring cleaning" promised for times of respite, either merely denying it. ("It won't evolve in such a critical way").

	'''In the midst of the application life''':	
	* reversing their initial values, and always lacking sufficient test coverage, they consider change proposals with much distrust. ("If we touch this, nothing will work anymore").

	* When they consent in coding the change, they still defer the payment of the - now really heavy - MaintainabilityDebt, and they imagine this change will be the last.

By contrast, agile teams seem to keep intact during the whole project their refuse of directing it with indication taken from any kind of speculation about the future :

	* They set up a cycle of production and validation that is short enough to allow observation to guide the project in each step of its progression, by this excluding any artificial extrapolation or rationalization. 

	* They implement what is required for the current iteration and this only, and they always DoTheSimplestThingThatCouldPossiblyWork.

	* They check at every moment the conformity of the product against requirements and they do this by keeping the functional coverage of their automatic test suites constantly high. Not that they mistrust what is not tested : to those teams, what is not tested simply doesn't exist.

	* They know the nature and the consequences of the MaintainabilityDebt, therefore at every moment they keep the whole production code ready for any possible evolution. (MercilessRefactoring)

Maybe I'm just comparing very bad traditional development teams with very good agile teams, after all. --ChristopheThibaut

At work here is a mental trap that developers are prone to; all creators really. Software development can be seen as a kind of disciplined speculation. "If I add this code to the existing (potentially empty) system, it should do this here." Substitute "I speculate that it will" for "it should."

Accurate speculation about the future - what ought to work - can be very valuable. There was a huge payoff to speculating correctly about the dot-com boom in the US, and more if you predicted right when it would end.

The interesting thing to me is the trade-off between speculation and feedback. Sometimes speculation is all you've got. The other challenge is costs. Some things are very expensive to change, and also relatively stable. Speculation is a pretty good solution there. -- JamesBullock

----
CategoryComparisons CategoryProjectManagement