means leaving decisions until the last responsible moment. This is non-intuitive to many Project Managers and Developers who normally prepare Project Plans from original requirements. Not to mention all people who are taught by their parents; "Never put off until tomorrow what you can do today!".
We know that developers are asked for estimates regarding work in the future, well these are just that, estimations! At some time early in the process, these estimates become contracts to the customer who are not happy when functionality is not delivered ‘on-time' and developers are working long hours to satisfy the raw estimates that the customer has been promised. These estimates are far more accurate when delivered closer to the time of execution (i.e. implementing a story or feature) and when given in context when the developer knows more about the system they are contributing to.
Functionality also changes over time. Iterative Development is a cornerstone of Agile and one of the concepts that has made Agile practices successful. Prioritizing time-boxed stories so that each iteration (or Sprint) consists of highest priority work that is achievable, has allowed more frequent deliverables to customers. Over the life of the project, requirements change, and can be introduced in between iterations. Allowing customers to defer commitment on features just before the iteration begins, at the last responsible moment, allows them time to confirm that the functionality is still relevant to the solution, or for them to realize that this functionality is now obsolete or less of a priority. This saves the team from performing work that might have otherwise been ultimately rejected.
"Deferring Commitment" does not mean leave everything until the last minute, otherwise the project will be late.
Why hope a design, or even hardware decision, will be suitable weeks or even months before it is absolutely needed? A design decision for a future feature could be totally negated through different decisions in early features when implemented and therefore the time spent in meetings discussing those future features, that are now not required, is waste. Also as a developer, your contextual or domain knowledge will increase as you are working on a project. The more you learn about the domain, the better informed you will be to make a decision
One approach to "Deferring Commitment" is to use Set Based Design. This works as an option when the deadline cannot be moved. One interpretation of Set Based Design is to have parallel development streams so that one team works on the simplest solution with minimum requirements (guaranteed to be delivered on time), while another team works on a system that has more functionality (may be delivered on time, but not guaranteed) and a third team may work on the ideal system (unlikely to be completed by the deadline). The customer will have a system by the deadline and management can wait to the last possible moment to decide which one to implement knowing there is a fall back plan. The idea is to complete the ideal system in the near future, to be delivered to the customer at a later date.
Admittedly, I have rarely seen this implemented. One successful example was at IBM in the early days of E-business (mid to late 1990's) where manpower was not an issue and different techniques were applied to determine the ‘best' way to deliver a project. Most organizations do not have the resources to perform this, do not want the extra overhead (even though it may be incorrectly seen as wasteful), or are fearful the customer will be happy with the current system and not implement the