| > "Writing good specs is important" - it's also really really hard. Yes, this is a very good point. Unfortunately it's also a point that many non-software developers miss. Writing software is hard. Very hard. We, as an industry, should be pointing that out more. > But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation. I'll submit that there's no way to know whether you are doing agile properly or improperly, unless you move to another company. > It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences. This smacks of elitism and it is what makes non-developer scoff at us. Developers are not gods, we're not even the smartest people. We are simply the people that have to crystallize the requirements into a computer that only understands logic. Non-tech stakeholders can completely describe business requirements and also be made to understand the how their requirements fit into the logic of a computer. Non-technical people are not stupid, they just have different interests. > You can't do that in a spec. It needs to be a conversation. The spec is the output of the conversation. > Have a conversation, understand what's needed, build good software. And this is the most important thing said. The trick with adhering to your statement is to define the parties involved in each step. Minimize those parties and then implement each step in order as fast as possible without sacrificing quality. Remove the word "Agile" and the concept of software development, and what you've just described is how work has been completed for thousands of years. I fail to see how Agile comes into play. |