The exception to this is of course open source projects operating at a much larger scale than most software companies. But they have come up with highly structu

The exception to this is of course open source projects operating at a much larger scale than most software companies. But they have come up with highly structured ways to develop that don't involve planning out everything in detail, which is a waterfall thing to do. Linux project: releases regularly every eight weeks or so. Chrome & Firefox: same thing. In fact most well run larger OSS projects seem to end up using date driven milestones rather than content driven milestones. Inside these projects you of course find people or groups of people that may have their own roadmaps and plans but they keep these separate from the overall plan, which is simply to ship whatever on date x. Either their stuff is ready and it gets merged and released or it stays on a branch until it is ready for a next release. Branches changed everything for open source developers. Every change is now a mini project. The last step of that project is to merge it, when the project is over. Some branches only last minutes, some last months/years. And those can break down into sub branches/projects. That's actually how the Linux project moves forward. Mostly Linus Torvalds is continuously integrating what is deemed ready. The mistake many companies make over and over again is managing whole products as one project. It doesn't work. Stop doing that and life gets better. Look at how big companies release big software packages these days. They use calendar driven milestones as well. They have lots of internal projects about things that may or may not end up in there. But the releases mostly go out as planned, i.e. when they are supposed to go out with whatever is in a stable state. The show must go on. That wouldn't work with waterfall. They'd constantly be missing those deadlines. The only reasons for moving deadlines are usually quality related. I always like this notion of inversion of control. You don't plan what ships, just when you ship and at what level of quality. This is much easier to plan for. Basically it becomes a game of quality control. If it's not ready, don't merge it and it's not on the critical path to anything. The rest just involves looking at the calendar. Product owners hate this inversion of control because they want to put content on the calendar. A good PO actually understands this and can adapt to that. An inexperienced one will indeed revert to planning lots of silly content milestones in a calendar. And then you are doing waterfall and falling behind the unrealistic schedule. Simple solution: don't do that. A POs job is to prioritize and keep amount of work in progress low to ensure that the right things get done well and as soon as possible. A high amount of work in progress signals slipping deadlines, poorly prioritized work, and lots of people stressing out about everything being super important. Agile processes tried to fix this. But you still end up with POs in control and sweet talking to senior management. So you end up doing waterfall if they don't know what they are doing (which happens a lot). Writing this as a CTO who is doubling as the PO (until we can hire someone that is better at that than me, I'm not bored). My approach to this is very simple. I have a hundred things I want to get done. I pick the top two and do those and than we do some more. The hard part is picking the right two things. Not coming up with a hundred more things to do. That requires discipline and a grasp of business and tech. That's my job. A key insight here is that you shouldn't plan out those hundred things in any amount of detail until you are ready to do them. That's waterfall thinking. You are just building an inventory of crap that will never get done and is probably the wrong thing to do by the time you get around to doing those things months/years later. Instead, I set high level mid term goals and plan short term according to those goals. The short term is about what we do right now and making sure that is the best thing to do and then doing that and only that well. We have continuous deployment so I don't care about calendars. Sprints are our short term planning horizon. Day to day work is Kanban driven. Do the most important thing, do nothing else.