Hacker News Reader

I'm not sure the author is advocating for no developer presence during the planning period.

> The first week of each month is spent with project leads and stakeholders defining the upcoming sprint

At the very least, I'd suggest that developer leads or engineering managers are stakeholders and therefore involved. They should be liaising with their development team (also stakeholders) during the planning phase.

Perhaps this sentence is overstated:

> It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.

People should perhaps take SOME time off to relax, but likely not the whole week.

I agree. I didnt read that as an invitation to take 5 days off every month, therefore advocating 60 additional holidays in a year.

I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you wanted to work on to make your work life easier, or leave a little early to wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have is actually feasible or not.

Yes, this is more along the lines of what I'm talking about. I'm advocating common sense over religious adherence. Do what works for you.

I am saying there's a lot of burnout in the tech industry and it's at least partly a process problem.

Maybe it's just me and I'm "doing it wrong", but I think it speaks to the issue that the suggestion of "taking it easy a week out of every month" is met with cries of "This is madness! It will never work!"

You may want to look at some of the arguments for "slack" in agile. Other agilists have thought about this from various angles, from scheduling it via WIP limits in kanban to dedicated 1-2 days at the end of a sprint. You're not "painting or surfing or whatever." At the same time, you can't capitalize that, and capitalization drives a large portion of IT.

Edit: I misread this to mean “all devs take a week off” instead of “a light week in collaboration on some backlog stuff” - that makes total sense.

I also misread the "first week" stuff to mean that you leave the room and take a week off.

Having a light week while this is happening makes sense. It ends up being light anyway while the transitions happen. Apologies for the misread.

As for madness - I was not at all implying the suggestion was madness, and different things work for different teams / projects. I personally find standups are super helpful so I wouldn't want to get rid of them. That regular cadence it creates is very helpful in making sure we all stick our heads up and incorporate what's going on around us. If your teams are doing this already without the regular touch-points, that's awesome, but I find that with most teams that is a learned thing that takes a lot of time, and regular scheduled places to update are important to success.

I read it as a proposal to declare 36 weeks a year off-limits for days off, because, you know, there are those well-defined special weeks where vacation days are supposed to be spent.

Ah! My initial read on this was “devs take the week off and the project leads and stakeholders do the work.” The “with” did some work that I interpreted differently. That makes sense.

I agree. The team (which includes developers) should be the ones pulling issues into the sprint. Leads and stakeholders can prioritize on their own, but again developers need some say in that process because technical issues my drive some prioritization.

I get the concept, but a week off seems a bit extreme and a hard sell. The team should already be working in some slack time in the sprint. The reason for slack time is that it gives a bit of a cushion if something runs over, and it keeps people from burning out. The other big upside for those on the outside is it helps build confidence that when a ticket is pulled into a sprint it almost always get completed.

No no no!

Agile has never been about predicting what you will do during a spent and then having slack or crunch time. Agile is about ranking your work by priority and dependency, setting meaningful milestones, and then adjusting your estimates frequently to avoid false promises and react to changes in the environment. If you don't finish planned work in a sprint, that is a planning success because after only a brief 2-4 week delay you actually know your performance against estimate and got clear information about how much you can do in a month, and a better chance at estimating what you can deliver next month.

> If you don't finish planned work in a sprint, that is a planning success...

In practice, most companies don't do this. They mark it as a failure and put it in red on the the big screen for all to see. Too many reds and there's disciplinary action.

Yeah, I kind of agree. If you want 12 weeks of vacation a year, you have to plan spectacularly. I am not sure 2 hours a month is enough.

It says that the sprint planning takes about 45 minutes. What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more.

So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.

Yep. If everyone’s updating issues in the ITS, it’s easy to plan a sprint. Priorities are mostly already assigned and the sprint planning meeting should be more of a sanity check.

Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.

So is the burnout because you’re just grinding all the time on tightly defined stories and you feel like there is no room to slow down? Legitimately curious and I appreciate you writing this up and putting it out there.

It's not even tightly defined stories, it's just teams working too much with no downtime, no time to slow down and catch your breath. There are always more things to do than time to do them, so unless lines are drawn the default is perpetual overwork.

Many seem to freak out at the concept of working less. Yet the 40 hour work week was considered radical at one point. Googles 80% time is by most accounts not a real thing, but it's a start. I'm at 75% time here. Then there's 996 if you want to go the opposite direction.

Sure, if this dialog is happening the whole time that makes sense, but burnout also seems like something that would be dealt with using the backlog - make time for exploration, test spikes, learning, etc. If all this work is well defined already and the backlog is owned by the devs, that seems like a solved problem. If, however the devs are actually spending a boatload of time refining stories before planning then sure, take a week off while others talk about it, but that has a bit of a smell to it also in terms of a happy medium.

If the overall message is “slow down sometimes” then I agree 100%.