The TL;DR of this is "work less (hours), avoid burnout." But this prescription needs a few more paragraphs of caveats that describe the company, team, product

The TL;DR of this is "work less (hours), avoid burnout." But this prescription needs a few more paragraphs of caveats that describe the company, team, product and other factors that affect whether this strategy is viable. The simple answer is "do what works for your situation" but that's light on useful information. If you can make Agile or Agile Light or Waterfall work for your team, go ahead. If your team cannot wait 7 weeks for a production issue to be fixed because "we don't add issues to sprints" then you might not be able to work with this system. When I saw 3 weeks on/1 week off, I was actually thinking of a sort of reverse - 3 weeks of active development with a final week of catching up on QA and bug fixes discovered in the sprint, as well as retrospectives, grooming and sprint planning (though, presumably, a dedicated product owner would get most of that work done concurrently with ongoing development.) You don't end up with an actual week off work but it is a lighter week. The main issues I've seen with Agile were not burnout related, but simply having an incorrect or weakened team structure. Not enough testers, insufficient engagement of a product owner, overloaded manager/scrum master/architect. It kind of goes without saying that if you try to follow Agile but you omit key team members, the existing team members are then more likely to be overloaded to pick up the slack, quality will go down, and the smoothness of the sprint cycle will decrease.