Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle

No. The bare minimum is what the customer requirements state. You deliver to the customer requirements. You don't deliver less, because that wouldn't meet the requirements. You don't deliver well beyond the requirements, because you'll guess incorrectly which direction to build.

If you come in ahead of schedule and below budget, looking around furiously for more value to add for the customer, then ask the customer what else they need. Don't just build more random stuff just because you have time to do so.

How this nonsense of "the bare minimum" somehow being less than what was promised comes about I'll never know. The bare minimum is what was promised. That's how promises work.

Comment on Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^9: Beyond Agile: Subsidiarity as a Team and Software Design Principle by Pope-O-Matik (Pilgrim) on Jul 27, 2015 at 21:00 UTC
The bare minimum is what the customer requirements state. You deliver to the customer requirements. It's all about negotiation. Everything else get pushed to "another release." The "bare minimum" changes in order to release faster, and what was originally requested can take many releases to get to.	[reply]
Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle by mr_mischief (Monsignor) on Jul 27, 2015 at 22:02 UTC
That's not at all "beyond agile" then, as the thread is supposed to be about. Either you're having the agile conversations with the customer and doing short sprints and regular demos and deliveries or you're not. There's no pushing off things to next release in order to release faster in Waterfall. Either you're delivering everything as promised, or you're doing Waterfall wrong. If you want to adjust to failing Waterfall with more frequent releases and more negotiation, then perhaps you don't want to use the word "agile" but that's what the term is all about.	[reply]