This week, I was reading “Agile Principles, Patterns, and Practices in C#” by Robert Martin. In one of the early chapters, he talks a bit about Scrum, and mentions that working overtime (excepting the week of the release sprint) is a big antipattern.
Now, I’ve been on a team that practiced Scrum, and we worked at least some overtime fairly regularly-our single goal was to complete our chosen tasks for the sprint. We felt that we’d made a solid commitment that because we’d said we’d do those things, we’d do them. On my team, overtime was a good thing if it allowed us to keep our word and finish the sprint. In fact, finishing sprints was the whole key to our version of Scrum… the company expected us to finish our sprints, and in return, we got to have sprints.
How does the team’s regular use of overtime mesh with Scrum? It doesn’t. We had it wrong. Scrum’s not about completing sprints, it’s about learning how your own team works. When I read about overtime was pretty much forbidden in Scrum, I finally got it-if overtime is forbidden and you’re behind, sometimes you just don’t get everything done. If you couldn’t get everything done in the time allotted, something is *wrong*-and whatever it is, you’ve gotta bring that out into the open so you know about it, as soon as possible. If people work overtime every sprint, you may not even know that the team is consistently unable to finish in the time allotted, and the root problem may compound over time. Whatever it is, be it an increasingly degraded/unreliable codebase, team disagreements, an underperforming team member, frequent interruptions, or tasks that just ended up being a whole lot more difficult than expected, if you don’t know about it, you can’t fix it. Forbidding overtime and allowing the sprint to finish uncompleted when things don’t work out keeps the need for introspection on and resolution of the underlying issues at the forefront. How you fix the problems is up to you and isn’t specifically addressed by Scrum-it may involve team building, examining distribuion of work, taking aside some people to find out why their velocity is down, or focused efforts to increase team velocity such as training or bringing in some XP(Extreme Programming) techniques. Whatever you try, Scrum can be a companion in making sure you know how you’re improving.
In the end, consistently completing sprints is really kind of a side affect, a wonderful reward that comes from the hard work of building and understanding of the truth about your team, and then making the tough changes based on that knowledge. Sure, completed sprints is what you hope for, but overtime isn’t the answer-it’s just a short term solution when what you’re dealing with is a long-term problem. If finishing the sprint tasks becomes more important than understanding the team’s weaknesses, then Scrum becomes simply a way to organize tasks-you’ve lost all the introspection and growth, leaving just an alternate form of Microsoft Project.
Leave a Reply