A plan and a backlog are two very different things. A backlog is not a plan. But having a backlog is still a good idea. Especially if it is prioritized and you

A plan and a backlog are two very different things. A backlog is not a plan. But having a backlog is still a good idea. Especially if it is prioritized and you have a clear idea of what you need to do short term and why. That prioritization does not come out of nowhere, there need to be some business goals and a strategy. Those are longer term things that change less often. Often that is summarized in some kind of roadmap. A roadmap is also not a plan but more of a tool that you use to align short term planning with long term goals. Ours is adjusted on a quarterly level and we tend to try to figure out the two or three most important things that we need to make some progress on. And we set some targets based on that. But a list of items that you want without a clear idea of how you are going to do these things is not a plan. Simple reality: unless you do waterfall, you won't have such a plan. And if you do, it's likely a bad plan. Adjusting plans regularly and figuring out business goals is something that happens a lot in software engineering. A classic misunderstanding is that that is a problem that needs to be fixed. It's a feature, not a bug. Building software is simply not like manufacturing, architecture or other engineering disciplines where you work off blueprints on predictable schedules. Until those blueprints are done, planning an engineering project is not doable either. You are not going to start building say a nuclear power plant without a very detailed plan and some blueprints and lots of analysis having taken place already. Of course, creating such a plan typically takes years and represents a massive investment in itself. And of course a common complaint with nuclear plants is that the planning stage is expensive, runs too long, and seems hard to plan. Agile nuclear plant design seems to be not a thing but if you think about it, the process of coming up with detailed plans for a nuclear plant has some similarities to how software projects work. Lots of uncertainty, constantly changing rules, requirements, legislation, and other factors. Maybe they should be more agile? Anyway, in software, the blueprints are the main thing that you build. That's why it's called software. It's an executable specification of some sort. Building that specification is the whole work. Having a blueprint for the blueprint is not really a thing (though of course many have attempted this). You might sketch out bits of it on a whiteboard and do some mvps, prototypes, and what not. But that's not the same as a detailed plan either. What's interesting is that some engineering companies are actually applying agile practices. E.g. the way SpaceX rapidly iterates on their prototypes seems a lot like the chaos you see in software companies. It seems to work for them and is very different from the way some of their old competitors work. What has changed there is that a lot of the work has moved inside computers. They are iterating on software, cad designs, using simulations, etc. Modern engineering inherently involves a lot of software. And you need to plan accordingly.