Does SCRUM usually involve massive overtime?

I would like to know if overtime is normal for sprints, or if it is an abuse of this methodology. I feel naive and spineless doing all-nighters if I don't have to.

Question is SCRUM specific. Compare methodologies.

-

migrated from stackoverflow.comMar 14 '11 at 19:51

This question came from our site for professional and enthusiast programmers.

all-nighters are never good for productivity -- you can do lot of work in one go, but in the end you have to sleep double. Also, I imagine the code quality after 8+/16+/24+ hours of coding. Sprints are necessary sometimes, but I would not suggest working more than 12 hours for more than 1 week. You're a human, you know :) You'll be tired for next two weeks after. –  Timo Mar 14 '11 at 19:39
if SCRUM involves overtime I would call it 'screw' not 'scrum' –  Imran Omar Bukhsh Mar 14 '11 at 21:57
That would be UNPAID overtime, right? Voluntarily contributed, for fear of losing your -- I mean, for fear of disappointing your colleagues who also, strangely enough, work unpaid overtime. Need I say more? –  Paul Mar 15 '11 at 7:50
Do you have a pointy-haired boss? –  HuBeZa Mar 15 '11 at 8:58
Massive overtime is an abuse of whatever system you're using. –  kubi Mar 15 '11 at 9:23

If you are doing overtime, you are doing it wrong!

Fail one sprint, adjust the focus factor and accept the REAL pace.

It sounds like there is some sort of pressure from the Product Owner?

Speaking from my own experience, you will not get this software finished earlier by working overtime. You will write software with bad quality. How smart are you after 10 hours in the office?

Plan better for the next sprint and try get everyone to accept the reality. It is OK to fail as long as you learn something from it. If you fail your next sprint and learn to plan better, you will improve the overall process.

Go home and sleep!

EDIT: and when you wake up, hand this book out to the team (helped me a lot): http://www.crisp.se/ScrumAndXpFromTheTrenches.html

-
There's two things that happen if you work too much: you write worse code; and you spend more time in unproductive loops (where you run the code, see the bug is still there, make some random edit to the code, then repeat). It drives management insane, but often the best approach to persistent problems is to relax, do something else, and come back in a couple of days. If "do something else" is have a weekend off, all the better. –  Мסž Mar 14 '11 at 21:10
Totally agree here, basically after 8 or 9 hours im spent, pretty much pointless to stay and just write crappy code. –  Mercfh Mar 15 '11 at 12:38

Massive overtime is a problem with schedule management, it has nothing to do with Scrum or XP or Waterfall or anything like that. It's usually a direct result that the decision-makers don't respect their people's time (and don't know about diminishing returns).

That being said, if your group is early in implementing the Scrum process then expect some growing pains. This should be communicated to and understood by the decision-makers as well. Estimates will start off bad (we're all bad estimators, right?) and should get better with time. Different developers have different velocities, different tasks can run in parallel vs. serial, etc.

The process should be structured to account for this. If the estimates were bad in Sprint 1, stuff gets moved to Sprint 2. Burning out on Sprint 1 isn't going to help Sprint 2 at all. Burning out creates a slippery slope. The process needs to be able to re-adjust and bounce back to an equilibrium, not continue down a path to destruction. Basically, the process needs to be "agile" in accounting for problems :)

-
Does SCRUM usually involve massive overtime?


No, it does not.

I would like to know if OT is normal for sprints, or if it is an abuse of this methodology. I feel naive and spineless doing all-nighters if I don't have to.

The whole point of Scrum and the amount of work you produce in a sprint, is that your velocity (how much you plan on doing) has be defined on a repeatable and sustainable pace. This is extremely important. Once you start violating this, things start to break down, as you have overestimated what you can do.

That being said if you all like working 60 hours a week, by all means do so. Just remember you have to be willing to do that on a normal basis :)

-

If you're doing all-nighters, then the sprint was very badly estimated; the fact that you're doing all-nighters is just making it worse, next time the estimate will be made based on the amount of work you did during the day and during the overtime.

-

I suspect one problem is the use of "sprint" in SCRUM. In track, a sprint is a short run, very fast, that isn't sustainable. It uses anaerobic energy, energy stored in the muscles for ready use, because there isn't enough time in a sprint for breathing to do anything useful. Sprinters have little energy after the race, and have to spend more than the time of the sprint recovering. Running back-to-back sprints would be silly. It would have to be treated as a longer race, in which the runner would pace himself or herself at a slower but more sustainable speed.

The equivalent of a sprint, in programming, would be to pull an all-nighter or two, accomplishing as much as possible in a day or two without regard for productivity after that. The use of the term in SCRUM can encourage some really bad practices.

-
The key word is sustainable pace –  DisEngaged Mar 14 '11 at 20:46
I agree here: people sometimes use sprint to mean "a weekend of 48 hours of work". Which is not what sprints mean in the context of scrum. I prefer the team "iteration", which avoids this (wrong) association. –  RyanWilcox Mar 14 '11 at 22:01

Just the opposite: according to Scrum you should reserve at least 25% of "slack" time. For example work estimated for 8h is expected to be done in 1⅓ days, not in one day. Scrum specifically calls for not doing overtime. Tasks from the bottom of backlog that didn't get done get either dropped or reassigned to next sprint.

-
That's what I thought. –  DisEngaged Mar 15 '11 at 1:40
A reputable source would be very nice. I don't think "some guy on SE said..." will hold much weight. –  Buttons840 Jan 20 '12 at 19:35
@Buttons840: meh. Read anything about Scurm. –  vartec Jan 23 '12 at 9:32

One of the key tenets of the Agile movement is working at a sustainable pace. Yes they call iterations "sprints" in Scrum but that doesn't mean you should run at breakneck speed.

-

It sounds like someone in management thought that SCRUM would fix scheduling mistakes. Scrums are for increasing communication, identifying important issues, and removing blockages as early as possible, but it doesn't mean that developers can code twice as fast. I'd recommend against working lots of overtime, as this is not sustainable and will give managers a false short term view of what they'll start to think is a target velocity for future projects.

-
dilbert.com/strips/comic/2005-11-16 –  mmyers Mar 15 '11 at 12:58

Scrum doesn't automatically increase your velocity - unfortunately, as velocity is a measurable metric, management automatically assume they can tweak it upwards.

The way to keep sprint momentum is to stick rigidly to the 6 hours of productive work per day guideline.

-
6 hours a day is overly optimistic, especially in an environment with things like SCRUM in place that demand excessive amounts of "progress meetings", "time management planning", etc. etc. (not SCRUM specific, but SCRUM is often a symptom of such an environment). Estimate 4 hours a day overhead per developer in such an organisation, 1-2 hours lunch/coffee breaks, and 2-3 hours productive time. In an organisation where developers can work as effectively as they can manage themselves, 5-6 hours can probably be attained. –  jwenting Mar 15 '11 at 6:39
Yeah, i'd say the maximum estimate is 6 hours a day - but each developer should be able to feed in their personal overhead. This actually points to one of the 'problems' with scrum - in order for it to work it has to have heavy buy in and participation from developers. This often ends up with a managers role being squeezed out - or their perception of control being lost (not that they had much control over schedules to start with). –  cbz Mar 15 '11 at 15:43

The #1 problem with something like scrum is "phase mismatch". It is trivially easy for the person measuring to "be out of phase" with the person being measured. This can cause the perception of problems where they don't exist. Consider the case of a daily scrum with someone doing tasks that take 1.5 days. The impression left in that case can be "not done, not done, not done, etc". A sampling frequency of 3 days, on the other hand would be "on track", "on track", "on track", etc. The cliche "what a difference a day makes comes to mind". As a leader your job is to align your sampling frequency with the nature of the work your team is doing. Sometimes that means sample every day, sometimes that means sample once a month. If you are working overtime to meet an arbitrary sampling frequency, it means you and your boss are out of phase. You should resync with each other on a more natural frequency. Things will be more harmonious that way.

-

using a planning system like SCRUM gives managers a tool to blame developers even more for not meeting deadlines. After all, the planning was done correctly according to all the guidelines and you still couldn't do it, therefore you're bad and I'm brilliant...

But that's not because of SCRUM (or whatever method is used), but just uses it as another excuse for inept project management practices.

-

This was a problem all of us lived day-in and day-out at Clickbooth.com.

The truth I think I've learned is that many organizations are too dysfunctional to do SCRUM. For example, things like failing a sprint, or even marking a ticket as 'blocked' would cause a Category 5 shit storm.

If you have a dysfunctional organization like that, SCRUM is destined to fail. My nickname for SCRUM there was "SCREW'EM" -- meaning the developers -- because management (eg the CEO) just couldn't accept the reality of the pace of software development and tried to fix it by repeatedly just saying "Go Faster" -> "Really, Go Faster" -> "Go Faster or we'll find people who CAN."

If you have a healthy software development orginzation they'll see that, for example, it's better to ship what's ready, to embrace reality, to fail a sprint if needed, that any one of those things is not an indication of poor performance but merely an acceptance of the reality of building something complex.

Sporadic OT, maybe for a couple sprints, where you at least feel your management is clued-in, then accept it and slog though. Because the nature of our business is product delivery. I've never seen a product delivered without some pain. It's always hard at the end. No matter your budget, your skill, your team, there's always a crunch at the end. So embrace it and even learn to CONSUME IT and you'll look like a clutch performer.

But wall-to-wall OT is a systemic problem. If that's what you're dealing with, get out of there. Nothing will fix it. At least not anytime soon.

-
That "crunch" at the end is not inevitable. It's a result of poor estimation. If it lasts more than a few days it's also ineffective. –  kevin cline Jan 24 '12 at 22:56

Overtime is a fact of life in software (or in engineering for that matter). I know it's cliche to blame poor management for OT, and sometimes it is. But good work, specially the challenging one will always involve some OT. On average, I've always worked 45hr/week, and when doing consulting, probably 50-55.

It is not just of Scrum and AFAIK, a well-run Scrum project won't constantly put people into overdrive (a truth of most well-run companies, almost independently of the project management methodology.)

-

Continuous overtime is an indication of either inaccurate effort estimations or an unwillingness to trust or accept the estimations. This is methodology independent.

SCRUM is to some extent self-correcting in this area, if implemented correctly. It's the team's responsibility to provide effort estimations on each issue but it's also the whole team that should sign off on the scope of each sprint. So, if you are constantly working overtime, you are either accepting a scope that is unrealistic OR you are consistently under-estimating the effort required for each issue.

Or, you are simply being made to accept a scope without any input, which is just as common as it is bad. What it is not is SCRUM. SCRUM aims to build trust and responsibility by getting the entire time to sign-off on each sprint's scope.

As a very simplistic example: say the total cost of all issues in a sprint is calculated to X units but at the end of the spring, you only completed (X - 10) units worth of issues. Then, your team clearly can only deliver (X - 10) units of work, so next spring you only add (X - 10) units worth of issues to the scope.

Your project owner/manager might feel that your team should be producing more than you are and he might be right; I don't know what your team is like. It's not relevant to the issue of SCRUM though.

SCRUM does not, in and of itself, increase productivity. SCRUM aids in IDENTIFYING areas of improvment, it makes it easier to MEASURE performance and it makes deliveries more PREDICATABLE. Boosting productivity is still a fairly traditional trade. Remove obstacles and distractions, motivate and develop people and, as a last resort, replace people who don't cut it.

-