in reply to Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

I've found many, maybe most, customers don't have a good idea of what they actually need (I only do web-work professionally; back and front end). There is a dialog and chance to apply expertise there, not guessing, or the price-padding fluff you somewhat unkindly allege. Bare minimum, while I understood you were speaking in code for some kind of ship early best practice, would be interpreted as cheap, half-baked, or rip off in most industries. Were the cleaners good? They did the bare minimum. How's the new car? It's the bare minimum.

"I need a customer contact form," is a typical requirement for a website. Bare minimum could be interpreted a few different ways there and different levels of expertise will apply different standards. That's about as simple as the stuff gets and it's still ambiguous.

Again, I did say I knew you knew this stuff. Throwing out things like "trust me..."? And CAPS? No, you TRUST me! :P

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

Replies are listed 'Best First'.
Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by mr_mischief (Monsignor) on Jul 27, 2015 at 19:35 UTC

    I allege nothing. It's a matter of what the customer perceives.

    My point is you gather the requirements, then you provide what meets those requirements. You don't provide less. The minimum is the requirements. You might provide more, but don't spend a lot of time and money providing a lot more. If there was a lot more needed than the requirements stated, then the requirements weren't gathered well.