Actually, I'm helping a small software shop on their Scrum Implementation. Recently the Scrum Master reported me that he has a problem because the Team is working Over Time to achieve the Scope (Committed Backlog). So they have an Unreal Velocity.

My formal question(s) is / are:

Apart from speaking about on the Retrospective Meeting; do you think that is a good idea to implement some hard-blocks to avoid Over Time?

If so, what techniques / tools do you suggest?

Revision Control system (SVN, GIT, HG, etc...), blocks by hours (8 to 5)

Work station blocks by hours (8 to 5) or cumulative hours (up to 8 hrs/day)?

Other(s)...

Or, maybe, do not hard-block this kind of things; but implement some "Penalty System" for Unjustified Extra Hours?

First: Tks all for your fast responses.

@Baqueta (and others with similar questions): No they are not been paid for Extra Hours. My first advise to them was to review their estimates because maybe they were underestimating.
This was my favorite advise:

If they have an interest in working overtime, remove it. Development isn't something you can do for 60 hours a week and stay productive, and there are numerous studies out there that prove this. If overtime pay is the issue, get rid of it and improve their base pay so they're getting what they're worth.

Also, I think that the root problem (for this team), is a combination of the following:

The developers are being told what they must achieve in a sprint/aren't being consulted on what's achievable/are being ignored when they say there's too much work.

The developers are consistently underestimating how much time tasks will take/how many units of work are involved in each task.

Summary: I'll talk to the Team to review their estimates, and with the P.O. because I feel that they are not being consulted about the scope, as you mentioned.

Have you ever seen the movie Cool Hand Luke? youtube.com/watch?v=SOWkPk2ETXc It sounds like you want your team to spend a night in the box because they're working outside the box. That just seems weird to me.
–
jfrankcarrAug 1 '12 at 3:43

Why are they working overtime? Is there a looming deadline that they do not have control over?
–
DaenythAug 1 '12 at 4:12

Penalties are not good policy for software developers. Better to stimulate and encourage team building and share issues as a team. Srum implementations are all about team soul. what is your Scrim master is doing? Does he intervene to this situation?
–
YusubovAug 1 '12 at 8:14

8 Answers
8

Frankly, those "hard blocks" you mention in #2 are the worst idea I've heard in a long time. What happens if a top-priority bug is found at 4.45pm and the guy who has the ability to override your blocks is off sick? As for #3 - you're suggesting punishing people for doing their jobs.

If the team are consistently working overtime to complete sprints, then either they have an interest in working overtime - e.g. overtime pay or getting overtime back as holidays - or they are committing to doing too much work in the sprints.

If they have an interest in working overtime, remove it. Development isn't something you can do for 60 hours a week and stay productive, and there are numerous studies out there that prove this. If overtime pay is the issue, get rid of it and improve their base pay so they're getting what they're worth.

If there is too much work going into the sprints, this is usually for one of three reasons:

The developers are being told what they must achieve in a sprint/aren't being consulted on what's achievable/are being ignored when they say there's too much work.

The developers are consistently underestimating how much time tasks will take/how many units of work are involved in each task.

The developers keep being pulled onto tasks which aren't part of the scrum.

If it's #1, you're doing it wrong. No two ways about it!

If it's #2, the usual cause is inexperience - either with doing time estimates, or with the system being developed. A good way around this is to stop doing time estimates and start estimating 'units of work'. Use some abstract unit, just make sure it isn't real-time hours (ultimately you're still representing a time interval, but the abstraction is important!). You can then start calculating how many units of work actually get done in a week, then set up sprints using that data.

If it's #3, you need to start factoring in those other tasks somehow. If it's consistent it should be easy to account for (see #2 above). If it's frequent but unpredictable it's much tricker to deal with. You'll want to take a look at why it's happening (e.g. serious bugs in 'live' code => is your testing thorough enough?) but if that can't be fixed then ultimately scrum might not be the right approach for you. My team recently switched over to Kanban for this very reason...

I'd add a #4, the developers have a hard deadline (tax season, annual conference, new gov't regs, etc.) that has to be met no matter what. This can require a short term extraordinary effort but shouldn't be the norm within the organization.
–
jfrankcarrAug 1 '12 at 13:10

First of all, it sounds like they got too much work on a sprint if they have to work overtime to get it done. Are all the hours logged? If so then you could count how much actual work is a story point and use that number to calculate work for next sprint.

It is also important to make sure the team understands they are only harming themselves by taking too much work. Even the agile manifesto talks about sustainable pace:
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." Working overtime all the time is not sustainable.

All in all, I'd suggest communication instead of force and penalties. I'd imagine that would only lead to demoralization of the team.

The devs working overtime are likely responding to some incentive, either actual or perceived. The is to either remove the incentive if it is actual, or to communicate that a perceived incentive is not operational.

Each suggested hard limit has some workarounds or other problems. Source control blocks would just lead to developers holding onto their commits until the window opens again. Workstation blocks would have to go as soon as there was some support issue or one of the devs needed to shift his hours for some reason. Penalty systems will just lead to hiding or burying overtime hours.

I think the problem is more fundamental -- the team has some incentive (or believes they have an incentive) to work overtime.

This is what needs to be addressed. Are their performance appraisals tied to their velocity numbers? Does management work overtime? Are promotions and awards given to those who work long hours? Are they contractors who are paid for overtime?

This may cause them to not be able to finish some work. That's not a problem, that's a data point. They can then use that data point in planning the next sprint. Again, don't let them work overtime. Whether they finish or not, they have another data point. Lather, rinse, repeat.

No amount of tricks or limits are necessary. Just don't work overtime. Learn how much work you can accomplish, and adjust your sprint planning accordingly.

Telling the team "not to work overtime. Period" is a limit! And besides, what if there's a requirement to create a deliverable every sprint? Or if one guy's work being behind is blocking the rest of the team? (To be avoided I know but sometimes it does happen.)
–
vaughandroidAug 1 '12 at 11:14

1

If there is a requirement to deliver, that requirement should be achievable within the normal working hours. The team should never commit to something they can't deliver with a sustainable pace (*except for mature teams in exceptional situations). And while the "no overtime" rule might be a limit, it's a good limit. The scrum team is currently disfunctional; limits are needed to get it back on track. Once they have an established, repeatable, sustainable velocity, they can lift the restriction.
–
Bryan OakleyAug 1 '12 at 11:18

Exactly. If you're using a tool like JIRA and estimating the hours of a task, you can see the number of hours of work your team can realistically accomplish.
–
omouseMar 7 at 16:59

Maybe there is an issue of not how "much" they are working but when. This can be a problem when there is a scheduled work day, but much of the normal hours are made up of meetings and other social and personal distractions. Are they working during over-time periods because they just feel more productive.

Cut down on the amount of work in the sprint and start working on flex time. Allow them to come in later. The person in charge needs to just tell people to go home; it's all right. There are some corporate cultures that create an environment where leaving early can bring some frowns.

I advise strongly against "hard blocks". Such controls could be perceived as micro-management and may fail to address the underlying issue.

I suggest that you find out why programmers are working overtime. The answer may surprise you. It sounds like you are an "outsider" (not an employee of the company), and programmers may be willing to be candid with you if you meet with them privately (one-on-one).

Is the reason for working overtime truly the workload, or is the reason more to do with culture or expectations?

Workload reasons could be

The committed backlog is too big

Either programmers or the product
owner is "gold-plating" (making features more complex than needed)

Expectations could be

Some sort of financial or recognition reward for working overtime

Fear of failure. The programmers are afraid that they will look bad or be punished if they do not meet the deadline

The programmers are underestimating the harmful long-term effects of working overtime.

I struggled with this when I first switched to scrum. It's natural to want to put in extra effort near a deadline, but scrum has deadlines every two weeks so it's an adjustment. In addition to the suggestion others have made to cut back on the committed story points every iteration, I would also suggest ensuring the stories are broken down enough, so each developer can finish at least two or three in an iteration.

That not only ensures each developer feels like they have accomplished something each iteration, it also gives you some slack in your scope. When your burndown shows you won't be able to finish a story, you can pull it out and reallocate people to the stories that can be finished. When people see that scope can be adjusted, they will be less likely to stress out about unrealistic deadlines. If you start an iteration with every story in progress, you have no room for adjustment.

An ideal cumulative flow chart should look something like this if everyone is finishing two stories per iteration:

It never looks like that because in reality it's very difficult to time all the stories to end on the last day while keeping everyone busy, but it's a good rule of thumb. If you are overcommitted, the red area will be larger and you can remove stories. If you are undercommitted, the blue area will be larger and you can add stories. If your stories are too big, the green area will be larger and you should split stories.

If you notice, at the product definition and requirements phases, you have a huge variance in estimation of effort. You can't be sure if it will take a month or a day to implement the feature.

I'm betting that none of the tasks are done done because they're simply too large and unspecified and there's too many of them.

If your team can handle 10 tickets in 5 days, and they're assigned 20 tickets, cut that number down, kick it up to the product owner/project manager/manager/client and tell them to prioritize.

At this point that's the only way to save the team from overtime. You can't deliver everything, but whatever you do deliver will be less likely to have bugs.

I would also advise looking for a new job and helping your team mates to do the same and fix up their resumes and professional portfolios. A company that expects overtime is one no one should work for and the software produced will be buggy as hell.