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

[chacham]

Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?

In general, teams are paid to support the customer. The bare minimum is not what they are asking for; they are asking for a lot more. As problems arise, they begrudgingly settle for the bare minimum.

Try unit testing and integration testing.

Full tests are expensive in both time and resources. Usually, a quick test, if anything at all, is done instead. Unfortunately, for all the teams i've been on, the testing environments were either used for more development or were not actually production-like.

If we're talking about an ideal environment where things are actually tested properly, why not wish for applications that are actually designed properly from the beginning?

[mr_mischief]

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.

[Pope-O-Matik]

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.

[mr_mischief]

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.