The problem with divide and conquer is that the finished product has to be back in one piece that makes sense. Often times the act of `divide` also reduces cont

The problem with divide and conquer is that the finished product has to be back in one piece that makes sense. Often times the act of `divide` also reduces context for what conquer actually is. Plus `divide and conquer` is used like a task you need to do with the goal of finishing, but Sprints never quite get to the end of the conquer phase, generally it's divide, and conquer...some tasks, and then divide in some more... and more... and more. You end up losing all sight of what you are actually trying to do or make. The only way to fix sprints in a small to medium size company that exists and is shipping products is to realize that they should be tied to a set series of tasks and that every now and then you really need a stop point where you can take a week or two, define what your goals, needs, and issues are for the next 6 weeks or so, and then start anew with a clean backlog and roadmap with full buy in from the developers of what they are making. Otherwise you just turn developers into ticket pushers for tickets that they themselves do not understand, or have any context to understand why they are doing them. It's depressing and causes burnout and bad products. It's a symptom of the hustle culture bleeding into development and a lack of understanding that having long term end goals and sustainable pace is healthy to good products rather than `move fast and break things`.