I'm not sure I have any particularly strong views to share, but a couple of notes.
I felt like "collective fiction" was a harsh term that implies we're always lying to ourselves. While that might be true, I like to use the more ambiguous term "narrative" for the same concept. The need for a methodology is a narrative or story that may or may not be true. I guess I do believe ;) that some of our collective narratives are definitely true, and calling them fiction undermines the good ones, or at least makes it harder to evaluate which collective beliefs are more valuable & closer to truth and reality than others.
Side note - collective narratives are a human condition, not in the least limited to programming methodologies. We build collective narratives for everything, and our physiology is prone to it. Having kids, it was fun watching them repeat stories they hear about the world over and over, as a way to cement their narratives with their friends and parents. When they were younger it was almost in the form of a question, they were waiting to be challenged or get more specific information. As they grow older, they get more firm in their statements and beliefs. After watching them do it, I became more aware of how often adults do the same thing, and how pretty much all communication, even technical communication, is just narrative.
My own 20 years of experience with methodologies and with other programmers has led me to believe that pushing coders to communicate frequently about what they're doing and what needs to be done is a good thing; most programmers I've known (including me) tend to wander in directions that they want to go and don't naturally want to do all the things that really need to be done. I sometimes don't like being transparent about what I'm doing, sometimes because I'm working on a pet project that I shouldn't be working on, sometimes because I hate budgeting and I don't know when I'll be done, sometimes because I want to deliver a higher quality than was requested and I know I'll be asked to stop being a perfectionist and just check in my changes. I see others not wanting to be transparent about what they're doing for the same reasons. But making sure that transparency exists is probably the only thing I've seen that works. Checking in often, making sure incremental progress is going the right direction, and re-iterating the requirements and users' point of view.
Too much formal process is usually bad unless you're NASA, and by the time it's called a "methodology", it's probably too much. It gets in the way of a lot of the good things that need to happen. Two week sprints get exhausting after a while, it teaches devs to aim smaller, and it causes undue burdens from management on tasks that legitimately take a couple of months. Being forced to estimate everything in story points has some advantages, but ultimately makes measurement harder, it's subjective and easily manipulated, and it's just contrived anyway.
So, I agree about formal methologies not working well, by and large, but I think the basic intent to keep focused and communicate frequently are good goals. It is ironic that most software methodologies are reasonably good at helping people evaluate how to make certain kinds of focused technical decisions, but they're very bad at helping people evaluate when a formal process is wasteful or bad, or to suggest a different formal process.
I felt like "collective fiction" was a harsh term that implies we're always lying to ourselves. While that might be true, I like to use the more ambiguous term "narrative" for the same concept. The need for a methodology is a narrative or story that may or may not be true. I guess I do believe ;) that some of our collective narratives are definitely true, and calling them fiction undermines the good ones, or at least makes it harder to evaluate which collective beliefs are more valuable & closer to truth and reality than others.
Side note - collective narratives are a human condition, not in the least limited to programming methodologies. We build collective narratives for everything, and our physiology is prone to it. Having kids, it was fun watching them repeat stories they hear about the world over and over, as a way to cement their narratives with their friends and parents. When they were younger it was almost in the form of a question, they were waiting to be challenged or get more specific information. As they grow older, they get more firm in their statements and beliefs. After watching them do it, I became more aware of how often adults do the same thing, and how pretty much all communication, even technical communication, is just narrative.
My own 20 years of experience with methodologies and with other programmers has led me to believe that pushing coders to communicate frequently about what they're doing and what needs to be done is a good thing; most programmers I've known (including me) tend to wander in directions that they want to go and don't naturally want to do all the things that really need to be done. I sometimes don't like being transparent about what I'm doing, sometimes because I'm working on a pet project that I shouldn't be working on, sometimes because I hate budgeting and I don't know when I'll be done, sometimes because I want to deliver a higher quality than was requested and I know I'll be asked to stop being a perfectionist and just check in my changes. I see others not wanting to be transparent about what they're doing for the same reasons. But making sure that transparency exists is probably the only thing I've seen that works. Checking in often, making sure incremental progress is going the right direction, and re-iterating the requirements and users' point of view.
Too much formal process is usually bad unless you're NASA, and by the time it's called a "methodology", it's probably too much. It gets in the way of a lot of the good things that need to happen. Two week sprints get exhausting after a while, it teaches devs to aim smaller, and it causes undue burdens from management on tasks that legitimately take a couple of months. Being forced to estimate everything in story points has some advantages, but ultimately makes measurement harder, it's subjective and easily manipulated, and it's just contrived anyway.
So, I agree about formal methologies not working well, by and large, but I think the basic intent to keep focused and communicate frequently are good goals. It is ironic that most software methodologies are reasonably good at helping people evaluate how to make certain kinds of focused technical decisions, but they're very bad at helping people evaluate when a formal process is wasteful or bad, or to suggest a different formal process.