Home | Login | Recent Changes | Search | All Pages | Help

WhyCrunchModeDoesntWork

Why Crunch Mode Doesn't Work: 6 Lessons

http://www.igda.org/articles/erobinson_crunch.php

Did you know that when Henry Ford did 12 years of experiments before picking 40 hours as the length of the work week at Ford? And that he took flack from other manufacturers for proposing it? I didn't.

DaveSmith 2005.03.03

I read the paper on 6 lessons. I enjoyed it. It didn't know that there was so much research done over so many decades. I went home from work immediately (I had already put in 50 hours for the week). I gave copies of the paper to my bosses.

DwaynePhillips 2005.03.05

For me, some work excites me and can help me get into a flow. I believe that my productivity can, but not always, increases despite long hours. But there can be serious drawbacks to this approach, see my article Looking Back, Looking Forward.

I'm willing to wager money that Henry Ford worked more than 40 hours per week. But he didn't see it as work because it excited him.

SteveSmith 2005.03.06

Even with interesting, "in flow" work, my brain has a limited half-life. I find now that after an intense day of pair programming (on interesting stuff), I'm mentally exhausted after 9 hours. Drop that to 8 hours, and I have brainpower left for some side projects in the evening. The folks I work with report similar time limits on brain function. --DaveSmith 2005.03.06

I find Steve's comment very interesting. In President Summers controversial comments at Harvard, it came out that a typical math/science professor there works an 80 hour week. I've long read about Washington types who put in 16 hour days. I have worked as much as a 100 hour week (just once, thank goodness) while in the Navy. My personal experience is that for short bursts, this works. But I have my doubts about it being standard for an academic or political career. Yet people say it is so. Am I missing something? Is it the interest factor that Steve notes? Or is it an appearances thing?

In any event, I believe that a _dictated_ work week of that magnitude quickly becomes a way of life for those required to meet it. That is, all of their socializing and play somehow get worked into the schedule so they can sustain it.

MikeMelendez 2005.03.07

DwaynePhillips 20 March 2005

SherryHeinze 2005.03.20

Any more? - JerryWeinberg 2005.03.20

I think at least some of the keys to making occasional crunch mode work are:

• a job that’s a genuine challenge, and therefore in the realm of the possible
• a short enough timeframe that you don’t grind people into the ground (3 months max)
• leadership
  • telling people the truth
  • being in the trenches with the troops. NOT trying to do their jobs, but doing your own, and being there to help solve problems and remove obstacles for them
  • shielding them from upper management idiocy
• NOT legislating hours, but empowering the team to decide together and individually how they are going to deal with the work in the allotted time.
• Having small goals, frequent monitoring and course correction, with full team participation.
• Maintaining a supportive and encouraging atmosphere: making genuine and frequent expressions of appreciation; celebrating achievements; understanding and accommodating people’s needs to visit their aged parents or pick up their kids; encouraging laughter and trying to make it fun
• Ensuring that it all stays as physically healthy as possible: providing healthy food instead of pizza, sending sick or over-tired people home, etc.

On reading this, I realize what I’m saying isn’t much different from how we’d normally proceed on a project, and maybe that’s the point. We can’t throw everything we know out the window just because we’re in a crunch. Crunch mode shouldn’t equal panic mode - or we’re really in trouble! (Too often it does. And we are.)

FionaCharles 20-March-2005

Yes, and...

Crunch mode doesn't work when it exonerates the team from responsibility of failure. "The project tanked. But then, we'd been in crunch mode for weeks - what would you expect ? That's not the way to do quality work."

Jerry, the effectiveness of crunch mode, or lack thereof, really doesn't have much to do with the number of hours. I can experience crunch mode from a one-hour task - and it can be every bit as excruciating as a one-year project. What makes it a "crunch mode" task is that, when I undertake it, I believe I don't have the choice of turning it down.

As a way of inflicting misery, crunch mode will work most of the time. As a way of getting work completed to the client's satisfaction, it will fail most of the time, because I won't do good work unless I have committed in good faith to the effort.

(There's the disturbing fact that in some contexts, people can actually turn out work that's "satisfactory" from the client's point of view, even under considerable pressure; I'm thinking of factory work, cutting up chicken all day long for instance.)

LaurentBossavit 2005.03.21

Laurent, you've raised the issue of what it is that makes a crunch mode--a darn good question. Let's have different definitions laid out here, then perhaps sharpen the discussion with crunch-mode-sub-1, crunch-mode-sub-2, etc. - JerryWeinberg 2005.03.20

FionaCharles 21-May-2005 (First day of spring!)

When I hear "crunch mode" the analogy I think of is: A long distance runner is running a race. For most of the race, the runner picks a sustainable pace. Very close to the end, the runner picks up the pace and sprints the last little bit. Begin the sprint too soon, and the runner collapses before crossing the finish line. Begin the sprint to late, and there is less chance of winning. I know nothing about running races, so I don't know if this is an accurate model of runners running races.

I do know a little bit about motor racing. Many of the professional races are not run at a sustainable pace. In a five hundred mile race, a significant number of the cars do not finish (DNF). And of those that do, they could not carry that pace on for another five hundred miles.So the race analogy is probably the wrong one to use for deciding how to run most projects.

ShannonSeverance 2005.03.30

Shannon Severance writes I know nothing about running races, so I don't know if this is an accurate model of runners running races.

You know a lot more about running than you many think. Your description hits the the bulls-eye. It's a great analogy for how project managers often sprint for the finish line too early.

Nice work.

SteveSmith 2005.03.30

I came up with these ideas:

• Measure the Fault Feedback Ratio. Frequently, developers make mistakes and can't stop making them
• Measure the total number of problems discovered
• Measure the cost to fix a defect

Unfortunately, all of these are reactive measures. Are there more quantitative measures? Are there qualitative measures? -- JohannaRothman 2005.03.31

I wish I had an answer to Johanna's question.

MikeMelendez 2005.03.31

I'm not convinced it's always true that crunch mode doesn't work. Used moderately, and managed properly, I think it can work. Trouble is, it's almost never done that way.

FionaCharles 31-Mar-2001

I'm trying to think of leading indicators that would show the staff is about to start the downward productivity trend. Don't have one yet. The second derivative of your data set would show when the accelaration has passed from positive, though 0, and gone negative before the data points actually do.

I prefer and educational approach. In SLACK Tom DeMarco does an excellent job showing the problems with several pet management ideas (fungible workers, unpaid overtime ...). Get your manager a copy of the book to read BEFORE crunch time arrives.

Of course, if the managers believe in crunch time, they probably have other incomplete thoughts too ... DonGray 2005.0.01

Don Gray writes Get your manager a copy of the book to read BEFORE crunch time arrives.

I've tried this idea.

It assumes that a manager likes to read books about his or her profession and makes time to read. In my experience, these assumptions are false. The book sits on the manager's bookshelf and gathers dust.

SteveSmith 2005.04.01

Fiona Charles writes I'm not convinced it's always true that crunch mode doesn't work. Used moderately, and managed properly, I think it can work. Trouble is, it's almost never done that way.

It depends on the effect management is trying to achieve by instituting crunch mode.

Management get distressed when they feel that the employees don't have the same sense of urgency that they do for getting things done.

When management creates a crunch mode project, they like the emotional response they see. The employees who engage or act like they are engaged gain the they "get it" label. The employees who resist are often labled as (they) "don't get it."

Management believes that crunch mode creates an environment that triggers its employees to fully engage.

SteveSmith 2005.04.01

CharlesAdams 2005.04.01

Charles,

what Steve Smith is saying not controversial nor unusual. Last year I overheard the CEO at the startup I was working at on the phone. He was explaining that his philosophy was that the amount of work completed was directly proportional to the pressure that his employees were under. He felt that lots of tight deadlines created an atmosphere where work would be accomplished. He was having a hard time finding managers who could keep a high level of pressure on the employees for a long period of time. At my annual review, I received no praise for the work that I completed. I did get lots of praise for working weekends and holidays.

KenEstes 2005.04.01

I’d like to continue cherishing the illusion that not all managements are completely stupid and abusive, but it’s not easy in the face of what Steve and Ken are saying.

Yes, there are managers out there who think pressure is the way to motivate people, and that people aren’t “engaged” unless they’re working 24/7. I worked on a project with a client manager who kept exhorting his team to think of it as a life-or-death situation. (Oh get real for heaven’s sake—it’s retail software!) We can only hope these idiots will pressure themselves to the point of implosion. Unfortunately they don’t look like dying out at any point soon.

When I talk about crunch mode as something that can be workable, I’m talking about a time-limited period within an otherwise normally and intelligently run project. (Making the large assumption that we still can use the term “normal” to describe a 40-hour week.) I’m not talking about a “crunch mode project”, which is a death march by another name and an obscenity. Nor am I talking about the equally obscene and anti-human “business as usual crunch mode”.

Are these really becoming the norm? -- FionaCharles 2-Apr-2005

Fiona Charles askes Are these really becoming the norm?

Although I know my sample is flawed, more than 50% of the IT organizations I visit are in perpetual crunch mode. It's ridiculous. And, yes, it's anti-human.

Fiona Charles I’d like to continue cherishing the illusion that not all managements are completely stupid and abusive

I would too. There are good managers out there who do the right thing. But they are the exceptions rather than the norm. If you have a good manager, cherish them. Be sure to tell him or her how much you appreciate them for specific things that they do.

I wish people would tell me the sample I see is NOT representative. Please tell me I'm wrong. Tell me that crunch mode is the exception where you work.

SteveSmith 2005.04.02

DaveSmith 2005.04.02

Dave Smith writes We start the day at 8:45 with a standup meeting, and working until 5:30 or 6 PM. Then we go home. I've been at the company a year, and I've been in on a weekend twice

Dave, Congratulations! I remember how much those previous jobs weighed on you.

I'll bet your happier and more productive.

SteveSmith 2005.04.03

Steve, most managers where I work are not forcing people into crunch mode. At least they are not telling people, "you must work 60 hours this week!"

Their example, however, is a little confusing to many. They typically work over 50 hours each week. It is hard for people to ignore their lead and work 40. Another factor is that this is the Department of Defense and the country is at war. People want to do their part. I believe, however, that they would be doing more if they spent fewer hours in the office.

DwaynePhillips 3 April 2005

Dwayne Phillips writes They (managers) typically work over 50 hours each week. It is hard for people to ignore their lead and work 40.

Dwayne, Nice observation. I couldn't agree more. I'll bet that the managers who work long hours are more likely to move up the ladder, regardless of the results they produce, than those that don't. If a manager doesn't work long hours, they are deemed lazy. The same applies to the employee.

The manager or employee who wants to be involved in their community, such as coaching their kids sports team, may have to choose between working on their crunch project or giving up the coaching role. Too many give up the coaching role.

SteveSmith 2005.04.03

A couple of years ago, I finally got to the point where I started saying in interviews that I was more productive 40 hours a week than 50 or 60 and that I would not work more than 40 (or 45 briefly). I am not getting all the contracts I interview for, I never did, but I am getting all I need. And I am not working insane hours.

Part of my ability to do that is that the contract market is good enough to keep me busy, but part of it is that my work at 40 hours a week is good enough to get me extended, invited back or recommended elsewhere. I am not convinced that my work at 50 or 60 (or more)hours a week is good enough to keep me busy over time. And as Jonathan Kohl pointed out on SHAPE a while ago, contractors do not get paid for play days or long lunches after the crunch is over.

SherryHeinze 2005.04.03

I have been fortunate to not have had any managers with the viewpoint that crunch mode is a good thing. That is why I say that the familiar is more comfortable than taking a risk on the unknown. I know it is with me.

CharlesAdams 2005.04.04

When you look at the development organization as a unit, "crunch mode" rarely, if ever, makes sense. When you look at the larger system, I think crunch mode may make sense in the same way that burning fuel anaerobially makes sense during a sprint, and even burning muscle and other tissues to make energy makes sense during a famine or a period of exceptional effort. The organism survives, at a price to some parts of the organism. If you stay in this "crunch mode" long enough you destroy fundamental things the organisim needs to survive, and the organism dies.

I've had better success managing up about demands on technical staff using "sprint" vs. "crunch mode" (with apologies to SCRUM folks.) "Crunch mode" sounds like it can last indefinitely, somehow. Most people I have encountered have the experience of a physical sprint leaving them panting and breathless, or worse. I've had succes with: "The trick with a sprint is that you have to be able to hit the finish line before you run out of energy, and you have to allow for recovery afterwards." It turns out that a sprint in sports is for a defined distance, with a well-defined finish line and the ability to recover after you cross the line. The people who benefit from a sprint in sports are the ones who hang on to enough form to make the exceptional effort pay off in distance travelled. I think it's a strong metaphor for "sprinting" with development work. "Crunch mode" I don't understand. It's wrong at least three ways.

- JimBullock, 2005.03.04

These past few months we have been battling sicknesses of all sorts with several people on the project. I am quite concerned about these people and it pains me to see them come to work on some days. I encourage them to go home, rest, heal, then come to work.

DwaynePhillips 5 April 2005

Steve Tell me that crunch mode is the exception where you work.

I wish I could tell you that. I belong to a group of four developers who do not attempt extended sprints and do not have short sprints very often, but we are the exception where I work. I do not know how long we will "allowed" to continue working this way

ShannonSeverance April 5, 2005

Crunch mode as the sprint at the end of a marathon is a useful analogy. However, at the end of a race, the reason to sprint is to stay ahead of those behind or to overtake those ahead (or to set a record). If there's no one near you, you may not bother sprinting. Most crunch modes are probably not driven by the immediate need to beat competitors.

A race is more about getting to the finish as fast as possible (or faster than anyone else), whereas my development experience is more like getting to the finish line at a previously-agreed-on time. To be crunched, you need to squeeze up against some relatively hard limits (preferably elastically rather than plastically).

For me, choosing crunch mode should be more like deciding to run to catch the bus.

You know when the bus arrives at your stop. The best thing to do is plan get to the bus stop just ahead of time. How much ahead depends on the variability of the bus, which you learn eventually. (The first few times you take the bus, you allow a bigger margin.) Getting to the stop on time depends on all the activities that come before it: what time you get up, having a shower, eating breakfast. Probably most of these activities are adjustable and some may be optional.

No matter how many times you've taken the bus, sometimes things go wrong, and you end up walking out the door late. (Usually, you've already figured out that you're going to be late despite adjusting your earlier activities. Being late is rarely a complete surprise, unless you've lost track of the time.)

Then you have a choice: do you run to catch the bus (go into crunch mode) or wait for the next one (slip)? Depends on how far from the stop you are, how you feel, how long until the next bus, and whether you can afford to be late for work that day. There are risks to running for the bus: heart attacks, running across the street and being hit by a car, slipping on ice, or dropping your laptop. There are costs as well, like getting your clothes sweaty.

Sometimes it is worth running, sometimes not. You should have some understanding of why you need to catch this particular bus on this particular day (rather than just habit), balanced against the costs and risks of running, and the probability of catching the bus. Even if you choose to run, you may miss the bus anyway, and you'd better be prepared for that outcome too. (If you think about it, you may have other choices too, like taking a car or taxi.)

Some people run for the bus, even though they know there is no way to make it, just to be able to say they tried. Sometimes, if the bus driver sees you running, she will wait for you. There are people who never leave enough time and always run for the bus. Most people want to make running for the bus the exception rather than the rule.

StephenNorrie 2005.04.05

Stephen, Thank you for sharing the wonderful simile for crunch mode. I enjoyed every word. Please consider turning your writing into an article. I would happily post it in our article section.

SteveSmith 2005.04.06

What Steve said. - JimBullock 2005.04.05

So, here's one measure I use to monitor how I'm doing running a development department: Do I have to chase people home, or ask them to get cracking?

Most developers want to deliver, want to do a good job, and want to pull their own weight on the develoment team and in the larger context. Many developers want these things to the point of risking ill-health and worse. I have found (so far) that the level of commitment of the tech team tells me more about the organization and it's management than about the tech team:

• If they've checked out, there's something preventing them from contributing - their work doesn't matter in some sense, or they can't figure out how to deliver.
• If they know what the goal(s) are, how to deliver (in this environment), and have the tools & other resources to do so, congenital developer-ism sets in, and you have to chase them home.

I know this about developers because I am one. The coolest thing is watching something we built work that didn't exist before. There is no rush quite like it.

I'm working at a start-up where we have occasional "running to catch the bus" events, not least because we're new to the neighborhood. I think some amount of this goes with the territory. If you want everything to be predictable, do something that's been done. If you are playing in terra incognita, expect some surprises. Some surprises you budget for. Sometimes it makes more sense to soak-up the difference, and sprint for the bus.

I look for a few things around any "sprint" event around software development in organizations:

• Is there a defined end-state? If not, we ain't running fast.
• Do we know how we'll get there? If we decide to go heads' down and crank for a couple days, there won't be a lot of thinking about the broader context or our processes while we're there. So our processes and target had better be well established before we start.
• Are we going to learn from this one, so we won't necessarily be running to catch this particular bus again.
• Did we learn from the last time we did this? If not, explian to me why this one is different (why it's an exception vs. a habit.)

This last is the most important, I think. I have had some interesting conversations with my management (at more than one company) about recurring "sprints" that go: "Well, I understand the business need right now. However, this is the third (Nth - ed) time. It isn't sustainable - this kind of repeated emergency destroys the very team that's so critical. Needing it repeatedly is either consistently bad management on our part, or a kind of "stealth overtime." Since we are neither dumb, nor dishonest, let's figure out a way out of this habit."

This thread is very timely. The development team I'm responsible for just came off a five day "heads-down" sprint for good and sufficient reason. They totally nailed what the business needed. Right now, they are cranking on the next round of stuff - at the good, sustainable pace we've had pre-sprint. We're already doing the things that will keep us from needing sprints like these in the future. We happened to be a few steps behind catching this particular bus.

Most interesting to me is what the CEO said in yesterday's "all hands." Along with recognizing the exceptional effort as exceptional, the CEO went on for a good 5 minutes about how the sprint was just a short-term acceleration of the focused, disciplined, sustainable efforts of the engineering team over months. Later, in a management-team meeting, the CEO used the engineering team's sustained execution last quarter as an example of how to deliver when you have too much to do. Not the sprint. Not "crunch mode". About 13 weeks of steady, sustainable execution.

Some CEOs are trainable, it seems. Not most. Some.

-- JimBullock 2005.04.05

-- DaveSmith 2006.04.01