Playing the Overtime card...

In a perfect XP—Extreme Programming—world, no one ever works overtime. In fact, I would venture to guess that the inability to meet this expectation is the reason XP fails at many organizations.

Scrum has no such expectation.

Yes, I realize that many agilists are now screaming at me, but you must remember that in spite of how you are using it, Scrum is not a development process. It is a management process. It dictates how a team is managed—not how it develops code.

Now, you are likely considering the fact that a decision to embrace overtime is a management decision—and you are correct—but unlike XP, Scrum is not that rigid. The team decides how—whatever that may entail.

I explained all of this above, so that you understand how the team is solving it's current sprint problems. Everyone is working OT until we are back on schedule.

To be clear, Scrum has enabled us to decrease overtime this year, while still delivering more than we ever have, and beginning next sprint, we will commit to less work with a target of maintaining forty-hour weeks for everyone on the team. However, like everything else in the world of process improvements, the elimination of overtime has been slow, but with the help of Scrum, we will get there.