Most software development methodologies - including what's become of some of the supposedly "agile" ones - are a vain attempt at formalising and industrialising

Most software development methodologies - including what's become of some of the supposedly "agile" ones - are a vain attempt at formalising and industrialising a process that's inherently non-industrial. Writing software isn't the same as producing physical goods but instead is similar to designing a product. Therefore I'd recommend design thinking and the double diamond model for design processes: 1. Explore the problem space. 2. Narrow down to the actual problem you want to solve. 3. Explore the solution space. 4. Develop and deliver the appropriate solution from that space. 5. Rinse and repeat. These aren't rigid methodologies but rather general approaches. Furthermore, proactive, goal-oriented communication is essential. The people / roles responsible for designing and developing the deliverables should also be the ones to gather requirements and talk with the users. Additional layers of organizational indirection such as dedicated business analysts often are detrimental rather than beneficial. Relevant communication should be recorded digitally and relentlessly. Requirements only exist if they're available to everyone through some sort of digital system, such as JIRA and Confluence, which are tremendously useful and usable tools if configured for enabling communication rather than for imposing some rigid and often inappropriate process.