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.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
|||||||||||||||||||||
|
migrated from stackoverflow.com Mar 14 '11 at 19:51
|
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 |
|||||||
|
|
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 :) |
|||
|
|
No, it does not.
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. |
|||||||||
|
|
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. |
|||||||
|
|
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. |
|||||
|
|
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. |
|||||
|
|
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. |
|||
|
|
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. |
|||
|
|
