I got together for breakfast awhile back with a colleague of mine in the industry who has been instrumental in getting me to drink the Agile/Scrum kool-aid and we got to talking about some of the more challenging fallacies we've both run into surrounding Agile.  The one topic of our discussions that really stands out for me dealt with the idea of having your team work at a Sustainable Pace.  First off, what is sustainable pace? Well, Ron Jeffries has described it thusly in the context of Extreme Programming teams (my paraphrase in brackets):

[Agile] 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. [Agile] teams are in it to win, not to die.

In my mind, and on my teams, this means that chronic 60 hr "firefighting" weeks are out in exchange for giving up that 90 minute lunch and focusing on hard-charging 8-9 hour days with precious little time for Google news and other time eaters.  Work hard, work smart, work efficiently...and for gosh sakes go home!  If I've got a perfectly good programmer who knows his or her stuff and is constantly adding value, what do I gain by burning them out in a year or two through firedrills and "Custer's Last Stand" development scenarios? But there's a bigger point buried in here somewhere that deals with the evolution of the Agile team.  I've run across plenty of managers in my time in the industry who are in the habit of sending out an email like this:

Team, Just wanted to send out a big kudos to John "I'll be burnt in 6 months" Smith for putting in his third consecutive 70 hour week which included throwing away weekend and family time.  This is the kind of dedication we're looking for.  We got the project done on time and waaaaay over budget so let's all give a big thanks to this team player and dig deep to try to mimic his dedication.

WRONG!  So we can all see that this completely ignores sustainable pace right?  So why does it reveal flaws for the Agile team (and arguably any team using any process)?  The reasons are threefold. 1. Management is reaching down using a command and control paradigm.  Clearly John Smith thought he had to work all that time so someone gave him that impression.  Agile abhors command and control and its likely that agile adoption in this case is in some serious trouble.  Trust your team to self organize, trust them to work hard, and trust them that when they say Feature X can't be done in Time Y, they're right. 2. Are the right people in the right place at the right time on the team in this example?  Maybe...maybe not.  Perhaps John's experience level is such that he needs to take on less backlog.  Perhaps John is being supported by three total yutz's who sit around watching dancing monkeys on YouTube all day.  The problem is, nobody has bothered to look or ask the questions. 3. Are our time and velocity estimation methods correct? More fundamentally, did we underbid or overpromise?  Who knows and who cares as long as we've got John Smith to bail us out?  This is perhaps the most disturbing eventuality.  Surely the organization did not bid the project based upon John Smith's 70 hr weeks.  There is very likely a glaring issue with the process rearing its ugly head that is being ignored.  Again, people hardly ever look in to how we got into this mess, they just want to be out of it.  Once they're out, problem solved...unfortunately for our mythical John Smith, he'll likely be repeating this little exercise next week too. Now, if the above described scenario happens once in a great while, no biggie.  We've all been there and sometimes stuff happens despite the best laid plans.  But killing your development resources repeatedly without every looking at how you got there in the first place is just plain illogical and bad for business and employee retention.  Sustainable pace...using your developers in a full, but not overfull, work week to ensure team cohesiveness, job satisfaction, and measured growth.  And demonstrating your trust in your team to work hard and work smart to get the job done. A not so novel idea whose time has come.  So what do I think that manager's email should look like?  Here ya' go...

Team, It has come to my attention that John "We're gettin' to the bottom of this" Smith has put in his second consecutive long week to achieve backlog targets.  While I appreciate John's effort, this trend is indicative of room for improvement in our Agile adoption process.  I would like to schedule time at the end of the current sprint to come together as a team and discover what it is we can do better as an organization to avoid these situations in the future.  We're not going to hide our flaws...we'll inspect and adapt as a team.