* A demo is a thing you can show. The first demo is usually
- the program will compile, run and print "hello world"
* A demo is a contract between stake holders
* Demos happen frequently. For a developer each day, for a team each week, etc.
Why does this help? A demo, actually showing something, is the only enforceable token that commits both part to the contract. In that way it is almost a currency. No stakeholder, whether manager, sales or developer can argue - either the demo was met, or not or was not clear.
This is much like sprints, test-driven, but a demo has the contract aspect.
Demo-driven reduces many of the causes/motives for over-engineering.
* Is the over-engineering bit in the contract? Why not?
* New function requires a new contract so no more last minute changes. (Been there done that).
* Stakeholders gain experience designing demos.
* Demos are adaptive. They provide tactile feedback.
* A demo is a thing you can show. The first demo is usually
* A demo is a contract between stake holders* Demos happen frequently. For a developer each day, for a team each week, etc.
Why does this help? A demo, actually showing something, is the only enforceable token that commits both part to the contract. In that way it is almost a currency. No stakeholder, whether manager, sales or developer can argue - either the demo was met, or not or was not clear.
This is much like sprints, test-driven, but a demo has the contract aspect.
Demo-driven reduces many of the causes/motives for over-engineering. * Is the over-engineering bit in the contract? Why not? * New function requires a new contract so no more last minute changes. (Been there done that). * Stakeholders gain experience designing demos. * Demos are adaptive. They provide tactile feedback.
My 2 cents