Decent article, but I have to nitpick one comment:
> Heavy sprints are important to achieving milestones for major events
No, they are not. Heavy sprints reflect planning.
If we're talking about a one-off, once-in-the-lifetime-of-a-company type of event, it's understandable.
But in most situations like this, one can usually chalk it up to "lack of preparation on your part does not constitute an emergency on my part". Whether you agree or disagree, the net effect is that it kills morale. Absolutely kills it, as the product development team loses faith in the planning powers-that-be.
Heavy sprints are most often a reflection of upstream planning, and a poor one at that.
I suppose that depends on what you mean by heavy sprint. 3-months long is excessive and burnt me out, but 1 month is not so bad. I totally disagree that it should be a once in a lifetime of a company type event to do a month long sprint. Many companies have a couple of major events a year that present an opportunity to make a big splash. You either take advantage of them, or let others pass you by.
It can kill morale depending on how it's treated, and how the company culture rewards. Just because you choose to meet a goal as a team that requires more than average number of hours put in for 4 weeks does not mean everybody is being dragged along. What does upset the folks doing the heavy lifting is when requirements get added at the last minute with "oh, can we please please just have this one more thing? It would be so awesome" from upper management. That's pure bullshit, and tends to rip apart morale above anything else.
1 month sprints are certainly ok, 2 months is rather heavy and 3 months is way too long.
As for taking advantage of those major events, again it comes down to planning. Ratcheting up efforts to meet a goal is one thing, but waiting until the last minute to address those goals is another.
I think we're saying the same things here, just depends on the situation at hand. I especially agree on scope creep, which I recently heard described for one project as "flexibility to change gears". The long-term negative effect so substantially negates the short-term gain, yet project owners are remarkably blind to the situation.
Maybe I have been fortunate in choosing employers, but is 1 or 2 days off really going to make people feel good about the extra 80 hours they worked? Even considering the "tips" in this article I feel burnt out and awful about working for a company like that.
It's ridiculous to expect more than 40hrs/wk from someone without fair compensation. Need more hours out of someone but can't afford to give them more money? Maybe they should be cofounders.
This of course with the assumption that 70hrs/wk @ 2 months is the equivalent of ~ 3.5 months of work at 40hrs/wk, which I don't buy.
I just left a startup that was doing pretty much the opposite of every point made on this list. After 4 months of 90+ hour weeks, I woke up one day and asked myself "Why the hell am I doing this?" Work environments like that are neither healthy nor sustainable, but unfortunately I think a lot of it stemmed from the mindset that there's nobility in killing yourself at work and anything less than that makes you a p*y. Needless to say, turnover was ridiculously high and morale was terrible.
> Heavy sprints are important to achieving milestones for major events
No, they are not. Heavy sprints reflect planning.
If we're talking about a one-off, once-in-the-lifetime-of-a-company type of event, it's understandable.
But in most situations like this, one can usually chalk it up to "lack of preparation on your part does not constitute an emergency on my part". Whether you agree or disagree, the net effect is that it kills morale. Absolutely kills it, as the product development team loses faith in the planning powers-that-be.
Heavy sprints are most often a reflection of upstream planning, and a poor one at that.