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.
Best Answer
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:
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...
Edit: Clarified my criticism of the ideas presented in the question.