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

So you're saying that the actual bare minimum when a door is ordered is that it functions as a door in an opening, fully installed. That's pretty understandable if the door is ordered by an end user tenant. If the property owner wants to hang the door, you don't have to hang the door. If it's a construction contractor who orders a door from you but hinges and latches elsewhere, they just want a door. If someone wants what's called a pre-hung door -- that is, one with hinges attached and an attached jamb that then is inserted into the rough frame -- then they get the hinges and jamb. If I order a slab door from you, paid someone else for the latch, paid someone else for the hinges, and paid another party to assemble and install the pieces I probably don't want you to send a workman and additional hardware. I just want the door.

"Give the customer what they ask for" is not shorthand for "screw the customer over by misrepresenting your agreement to get out of work". You should gather the requirements and deliver what's required. Just as you shouldn't short the customer by delivering much less, you shouldn't short yourselves by delivering a bunch extra. The customer would rather pay you no more than necessary, and any extra time you have to give them they'd rather get the extra features THEY want, not what you GUESS they MAY want. When you're coming in way under budget, make that extra customer meeting about whether they want early delivery, a partial rebate (horrors!), or WHICH extra features they may want included in the original price. It's much better, trust me, then the meeting THEY call to ask why you overpriced their initial requirements to provide all this fluff they didn't ask you to write.

  • 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 Your Mother (Archbishop) on Jul 27, 2015 at 18:05 UTC

    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

      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.