Agile Lite: Agile without all the burnout

That's a good idea. Consulting firms have really overcomplicated Agile a lot. I've been displeased to meet bloated implementations these last years.

My only point is that, at least in the companies I've worked for so far, a practical Agile implementation must provide some device for making a "pressure" over the team to avoid too many items ending up carried to next sprint.

Of course there are lots of legitimate situations where an item doesn't fit in the sprint and this should be acknowledged, providing inputs for the estimation of the next sprint and making those estimations more accurate. However, in my opinion, it should also be clear to everyone that those slippages have consequences and everybody should be employing their best efforts.

I don't consider this a deficiency in the article though, since Agile in itself seems to be optimistic about teams by its very nature.

I believe this is going to get me some downvotes, but this is unfortunately the reality I live in and if I were going to devise an Agile implementation for my team I would take this into account.

Telling your developers to bugger off for 1 week every month will never work out. They still need to be at the office, but they can pursue learning, help with planning (this is critical), or focus on other development tasks they actually want to make.

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.

>Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.

You’ve succinctly defined the problem in a very profound way. A verbal punch to the gut for sure.

> I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do.

Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.