Breaking the Rules of Agile - Working Overtime
Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It’s pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.
The text I find interesting is “…means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out.”
I used to get hung up on this and even today I continue to see others getting hung up on this. I used to think that I had to work at a sustainable pace and that I would fail if I worked overtime.
Simply put, this is just not true.
So, how does one know when it is effective or not effective to work overtime? Simple. Teams work overtime when its needed, not demanded.
Not demanded? From my experience, when things are demanded of teams, it’s a sure sign of an old command and control structure.
Mr. Program Manager, you need to have your team come in this weekend to ensure your project stays on track. I didn’t like what was reviewed at the last review meeting and you need to get back on track and stay focused.
Yes, I’ve had conversations like this in both supposedly agile environments as well as traditional environments. I was lucky however. The team I was on was fully agile - practicing XP and Scrum, absorbing and living the principles.
We asked ourselves: “do we really need to come in this weekend? Is our project really in peril?” Turns out it wasn’t. What happened in the case above was the upper manager was mis-informed because (s)he missed some meetings prior to the Scrum demo meeting (s)he attended. As a result, (s)he was out of the loop on the project and didn’t like the direction the team was taking based on customer input (architects in the larger organization were one class customers, for example).
By simply asking ourselves, as a team, “do we need to come in this weekend; do we need to work overtime at this point of the project?” we often found that we didn’t. When we did answer yes to these questions, we were dedicated and focused to accomplishing our work.
The team laid out the work it needed to get done in order to go home at the beginning of the overtime sessions that spanned weekends. For late nights, we would often have a quick team meeting at the end of the day and decide our goals for the night - the exit criteria that would allow us to leave.
Often times the entire team would not need to stay - this introduced an interesting conundrum - is it OK for some to stay and some to go? What do we do if this occurs on a regular basis? What we did is talk about it. We surfaced the possible perception issue that some team members were working “harder” than others and talked about it. What we discovered was that we were each very dedicated to the success of the project and that we would each do what was needed to make it succeed, within reason.
Within reason? Yes - team members had families (some large). As a result, it was not reasonable for some people to stay late, especially since they came into the office at 0700. This, of course, will vary by team.
If you find yourself in the position where your team (or a team you coach or “manage”) needs to work overtime, have the team ask itself if overtime is needed. If it is, talk about it, define the goals of what will be done in the overtime sessions (or weekends) and outline the exit criteria. Follow this with a discussion on who is needed to do the work, and as a result, work the overtime. Remember, this is a team exercise.
Note: I recommend having at least two people work together as a pair when working overtime. This helps disseminate the information to the rest of the team following the overtime session and helps keep the overtime session focused.