4 ms·
Hot-take: Agile is for service work, where the customer can't explain the problem very well yet, and you can take the reputation damage of showing half-work. Pr
by p0nce 4y ago
Hot-take: Agile is for service work, where the customer can't explain the problem very well yet, and you can take the reputation damage of showing half-work. Product work should have some amount of discovery, but derisked by user research (and thus is more waterfall) and thus will be released polished.
- thunderbong 4y agoIf the customer can't explain the problem very well, then how will they verify the software is doing what they're expecting?
- p0nce 4y agoCan't explain entirely before having something in front of them.
- alwaysbeconsing 4y agoMany if not most people are better at describing "what should be different" given a concrete thing than they are at describing "what should be" given a blank sheet. The idea is to build that fact into the work plan.
- thunderbong 4y agoI agree with both the sibling comments. However, in my opinion, in a scenario where the customer is not clear about what they want without something in front of them, it is better to create a high fidelity click through design prototype, rather than actual code. Finally, I'm personally very averse to finalise requirements where the customer is suggesting or dictating UI. Many times, there's a better way to fulfill their requirements by identifying what they want, in textual format, rather than asking them from the UI perspective.
- cratermoon 4y agoIt's been well-demonstrated that users can't articulate what they really want. I don't recall the source, but I read one observation, "users will ask for a toaster in their car's dashboard when their real problem is that they don't have time to make make breakfast in the morning". You can do all the research you want on in-car toasters to get the optimal product, but you still aren't really solving the right problem.