The beatings will continue until morale improves
Topic: Human factors

I've been involved with agile software development for seven years now — doing it, reading about it, hearing about it, speaking about it, writing about it, teaching it, coaching it. No two organizations or teams put agile thinking into practice in exactly the same way. For that reason, there's always something new to learn; something I haven't seen before; something unexpected. It shouldn't surprise me to be surprised. Yet, I must say the last thing I ever expected to see was an agile sweat-shop.

I've worked in software development sweat-shops before. They used to be pretty common. Software professionals (in the US, anyway) used to take it for granted that they were expected to work 80+ hours a week all the time. Career burnout, divorce, and nervous breakdowns were the price one paid to work in the software field. It was considered normal. This was one of the reasons (along with role silos, lack of feedback, lack of collaboration, lack of accountability, lack of career advancement options, and soul-crushing bureaucracy) that prompted me to exit the IT profession in 2002, when a colleague caught me by the leg (not in the Russian sense) on the way out the door and introduced me to a different way of working. For me, "agile" rekindled the enthusiasm and passion that I had felt earlier in my career, before the bureaucrats took over the IT field. I'd sooner open a donut shop than go back to the Old Ways.

It may be because of that background that I was caught completely off-guard when I learned about an agile sweat-shop just recently. It wouldn't have occurred to me that a sweat-shop could be set up on the basis of agile values and principles. The two seem fundamentally incompatible. Nevertheless, it can happen. It's happening right now in a certain company, and that fact makes me wonder whether it's happening elsewhere, as well. Some people are rather antagonistic about the idea of agile software development. I've never really understood why, since in my experience it's been overwhelmingly superior to the Old Ways in every sense. If someone's experience of "agile" has been in a sweat-shop environment, then I can certainly understand why they would have a negative attitude about it.

The other day I heard about an XP team at a certain company that had decided to work four 10-hour days per week. It sounded interesting to me, since I've worked on XP teams that made the same choice. I was curious to know the reasons why this particular team had decided to try a four-day week. I remember the reasons why we did it on those past teams, and I still think they were good reasons:

1. Less ramp-up time at the beginning of the day and after lunch; eight ramp-ups as opposed to ten per week;
2. More focused time for development and collaboration; and (last but not least)
3. A three-day weekend.

From that experience we learned that there is a cost to working four 10-hour days. On an XP team, you spend most of your working time pairing. Pairing is an intense activity that demands one's full attention at all times. Working solo, one usually does not remain intensely focused continuously; focus ebbs and flows such that the mind stays fresh. With pairing this doesn't happen naturally. You have to break up the time intentionally, using an explicit time-management technique such as the Pomodoro Technique (or similar). Pairing is more like sprinting than jogging. You can keep going for a long distance when you're jogging, but when sprinting you have to stop and rest between runs. With the standard eight-hour work day, an XP team member is likely to pair about 5 to 5 1/2 hours per day, and not all in one burst. It's quite sustainable. With a ten-hour day, we found ourselves pairing about 6 1/2 to 8 hours per day. By the end of the fourth day, we were physically tired. We found that that "free" Friday had to be spent in recovery, as often as not. Ultimately it comes back around to the agile value, sustainable pace.

 

You can see why I was curious about the team that wanted to try the four-day schedule. I wondered whether they had considered the potential downside, or if they were just thinking about the fun they would have with three-day weekends. So I asked what had prompted their decision. Now I almost wish I hadn't. The more I learned about their situation, the more hairs stood on end on the back of my neck. They weren't looking forward to a long weekend. They weren't looking forward to anything positive at all. They were looking for an escape valve for needless pressure.

The first neck-hairs stood up when the team explained that they had not "chosen" to try a four-day work schedule in the sense that a self-organizing team is empowered to make such a choice. They had been begging their management and their HR department for "permission" to work four-days weeks for several months. So, this ostensibly "agile" team is managed in a command and control style.

Be that as it may, I have a hairy neck and that wasn't enough to raise a significant alarm. There may have been perfectly reasonable organizational reasons why one single XP team out of many shouldn't work on a different schedule than the rest of the shop. Command and control may have extended only as far as necessary. Perhaps foolishly, I asked for more information.

I learned that the team uses a time-management technique similar to Pomodoro to schedule pair-programming sessions and breaks throughout the day. This seemed quite reasonable to me, since I know how it feels to get into "flow" and lose track of time, and end up wearing yourself out. You can't work at peak effectiveness when you're exhausted. Hence the wisdom of controlling the amount of pairing time, not to mention the plain fact that certain activities don't benefit from pairing.

But there is a sinister side to the time-management technique. When team members have to take care of routine personal business during the day, such as visiting the doctor or picking up children from school, they are required to use up some of their accumulated vacation time. This draconian rule not only runs counter to agile values, but it also defeats the very purpose of vacations (to ensure employees have a chance to refresh themselves and reset their minds periodically) and may even violate Fair Labor Standards law by treating some (and not all) exempt employees as if they were hourly (but only at the employer's convenience). More hairs were now standing upright on the old neckeroo.

I had to wonder what might have led management to impose such a rule. The answer came from a separate discussion with some team members about pairing. They asked what the "extra" person was supposed to do. At first I didn't understand the question. How can you have an "extra" team member? What does that mean? They explained that they were required to follow the rule that production code could only be touched by a pair. They were not permitted to work on production code alone. Thus, when there happened to be an odd number of team members present on a given day, there was an "extra" team member who was not permitted to touch production code.

I suggested that they may have misunderstood the mechanics of pairing, or that they were being a bit extreme (no pun intended) about practicing pairing. When there is an odd number of developers, then someone works without a partner. The next time people switch around (and that won't be very long; just the length of one Pomodoro or however else the team manages its time), someone else will be left to work solo for a while. It's not a big deal, especially when the team is following most or all the other XP practices, since that would result in a high bus number, and a high bus number makes it feasible for individual team members to be out-of-pocket once in a while without crashing the project. I really didn't understand what their problem was. I started to probe them about their understanding of the rationale for pairing.

It quickly became clear that this team follows XP practices for one reason only: Their management requires it. The "reason" they pair is that "management doesn't trust us to work on code unless someone is looking over our shoulder." (I know from separate discussions with management that this is not actually true, but sometimes perception trumps reality.) They are unable to describe the value proposition of XP as a whole or of any particular XP practice. "It's a rule." "Management makes us do it." "We'll get in trouble if we don't do it." They are not making informed professional judgments based on principles. They are merely following rules. That means nothing less than this: They value processes and tools over individuals and interactions. At this point, the back of my neck was at DEFCON 1. What I saw before my eyes was the heretofore unimaginable: An agile sweat-shop.

This team is so stressed-out by the fact they can't pick up their kids or get a tooth filled without burning some of their vacation time that they're willing to take on an even more stressful work schedule just to free up a weekday for routine errands. Horrors!

Of course, practitioners will recognize that this isn't "really" an agile team because they're "doing it wrong," but I hesitate to call that particular spade by name because of the vocal minority who like to bash the supposed "agile religion." Yeah, you agilists (popularly mis-spelled agilest, for reasons unknown) always say "they did it wrong." How convenient! Okay. Whatever. Call it what you will. (They did do it wrong, though. A rose by any other name, etc.)

So, what could have led to this sorry state of affairs? It turns out to be a question of interpretation; specifically, interpretation of one of the seminal books about XP, Extreme Programming Installed, by Ron Jeffries, Ann Anderson, and Chet Hendrickson. Published four months before the Snowbird meeting, the book quickly became a guidebook for many budding agile teams. It became so widely known that for several years it was identified in casual conversation as, simply, The Pink Book.

The agile community has learned much and made many advances in practice since then, but The Pink Book remains basic reading for those who are interested in applying agile software development methods. There's one statement in particular, at the head of Chapter 12, on page 87 in the paperback edition, that speaks to pair programming. When I look at page 87, these are the words I see:

On an Extreme Programming team, two programmers sitting together at the same machine write all production code.

Here's what it means: Ideally, most production code should be developed by a pair who use other XP practices while they are working together, because by applying this set of practices they can produce clean code with few defects without wasting much time. If it's feasible and reasonable, all production code ought to be built this way, to take full advantage of the benefits of pairing. Short of that, pair as much as makes sense while keeping the single most important factor in mind: effective delivery value to the customer. It's a very good guideline. And that's just what it is: A guideline.

Problems occur when people interpret the statement not as a guideline, but as an inviolable rule that supercedes everything else, including the effective delivery of value to the customer. Those people would rather sit idle, waiting for a pairing partner, than to deliver value to their customer. When they look at page 87, they see different words than I see:

Brother Chet reads from the Book of Jeffries, Chapter 12, Verse 1: Firstly shalt thou code in pairs. In threes shalt thou not code; neither shalt thou code as one, excepting that thou then proceed to two. Four is right out! Amen.

This very slight difference in interpretation leads to very different implementations of XP, some of which are darkly familiar to a hairy-necked survivor of the Old Ways. Don't get me wrong — it's a great book.

But it's only a book, you know.