4 ms·

As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done i

As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done in a month is really weird. That will not lead to the absence of a death march - it is a recipe for a death march. Not only will you not have an accurate assessment of the tasks but they will not be ordered correctly, and likely way overscoped for the timeframe, and you get no chance to say no. Technical minds / engineers in the room early and often is critical to success - otherwise you’re just told what to do instead of architecting it the “right” way. Communicate when you need to but try it all for a sprint or two (really, Standup is a hardship? You may not be doing it quite right), then drop after the team finds a rhythm. Edit; after reading the author’s other works the burnout seems to be centered on a big push from stakeholders to accelerate and keep going so a sprint is seen as a reset - kinda like a new day dawning in a news room. You can plan-in your work to avoid this and still continue to make progress but it does take some discussions with leadership, or at least a clear justification about why this week is exploratory instead of hands-on. Done it many times. I would not suggest changing the whole method just to accomplish this, however - a process fix for a problem like this won’t necessarily help.

matwood 8y ago
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.
- hopler 8y ago
  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.
  - JustSomeNobody 8y ago
    > 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.
phillc73 8y ago
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.
- addicted 8y ago
  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.
  - dave_sullivan 8y ago
    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!"
    - ebiester 8y ago
      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.
    - 8y ago
jrockway 8y ago
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.
andmarios 8y ago
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.
- dave_sullivan 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - sailfast 8y ago
    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.
    - dave_sullivan 8y ago
      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.
- sailfast 8y ago
  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%.

matwood 8y ago

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.

hopler 8y ago
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.
- JustSomeNobody 8y ago
  > 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.

phillc73 8y ago

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.

addicted 8y ago
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.
- dave_sullivan 8y ago
  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!"
  - ebiester 8y ago
    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.
  - 8y ago

jrockway 8y ago

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.

andmarios 8y ago

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.

dave_sullivan 8y ago
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.
- deleted 8y ago
  [deleted]
- sailfast 8y ago
  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.
  - dave_sullivan 8y ago
    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.
sailfast 8y ago
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%.