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.

Follow-up on the recent PMI panel discussion
Topic: Events

I received an email from Jesse Fewell this morning thanking the participants in the recent agile panel discussion hosted by PMI, where I had the honor to serve as a panelist. He pointed to the write-up of the event he posted on his blog. His post includes a couple of photos and a summary of some of the panelists' comments.

It certainly was a pleasure to work with several of the big brains in the agile community - Richard Cheng, Linda Cook, and Rodney Bodamer. I look forward to working with them again soon.

Mentoring the value of pairing
Topic: Value proposition

I'm coaching a team that is relatively new to techniques like TDD and pairing. A team member asked me to pair with her the other day to have a look at her unit test cases. Like many people who are still getting used to building up a suite of automated tests, she had been writing Happy Path tests and only an occasional abnormal case. She felt that she wasn't considering enough test cases, but she wasn't sure what to add. In the course of the pairing session, we started building a new feature in the application and wrote test cases for boundary conditions, null arguments, exceptions, resource unavailable situations, and so forth.

The TDD coaching as such was pretty typical, but the interesting thing was that she asked why people should pair unless they're transferring knowledge or mentoring one another. I took the opportunity to demonstrate one aspect of the value proposition of pairing. As we worked, whenever one of us helped the other by noticing a minor mistake — mis-keyed keyword, missing closing tag, forgotten semicolon, etc. — I made a tick-mark on a piece of paper. Furthermore, whenever we had a brief design discussion as we were working — pull this method up? break up this if/else block? etc. — I tracked it with a second set of tick-marks.

After our last check-in for the session, we took a few minutes for a mini-retrospective. I asked her to make a reasonable guess about the amount of time we had saved each time one of us noticed a minor coding error in the moment. She figured each one was worth about 30 seconds, based on the notion that finding the error after the fact while debugging would have taken about that long on average. We also talked about the brief design discussions that had taken place. We figured that on average each of the resulting design improvements prevented two hours of future code maintenance effort by avoiding a little bit of technical debt.

In one of his early books, Alistair Cockburn computed that the cost of an IT professional amounts to about $2.10 per minute. That's a little higher than my own scratch calculation, but he's a Doctor so I'll go with his numbers. In our pairing session we had two mini design discussions that led to small refactorings. By our reckoning, that saved four hours of future code maintenance effort. That's worth about 2.1 x 120 = $252.00. There were 12 moments when one of us noticed a minor mistake. If those occurrences saved an average of 30 seconds debugging effort, then it was worth .5 x 2.1 x 12 = $12.60. In total, we saved the company $274.60 in 90 minutes' time, or an hourly saving rate of about $180.00.

Bear in mind these numbers are just rough-and-ready estimates based on our observations of a single pairing session. They may be high or low. The calculation also ignores the opportunity cost we avoided by keeping the code base clean. What I mean by "opportunity cost" in this context is the cost of the time developers could not have spent on value-add work in future modifications, if they had to spend the time working around the technical debt that we avoided. (That's a clumsy way to say it; I hope it's clear enough.)

The company has a small IT department with a total of about 40 developers working in several XP teams. If we assume the developers pair about 5 hours a day, then that's 20 pairs x 5 hours x 5 days per week = 500 pairing hours per week. Assuming a savings of $180 per hour per pair, that makes the average hard savings attributable to pairing $90,000 per week. If that rate of work is more-or-less constant throughout the year, and the teams work 50 weeks a year (it's in the United States, so vacation time is short), the company enjoys a savings of about $4.5 million per year specifically because its software development teams pair-program as a standard practice.

Of course, by projecting the results of one pairing session in this way we are subject to the effect of cumulative error. If you think the numbers are inflated, then go ahead and chop them in half and say that the company is saving a mere $2.25 million per year. The precise number isn't really the point; the point is that pairing really does deliver hard value. Given that a professional's time is the most expensive component of IT cost, techniques that save professionals' time are well worthwhile.

The team member found the numbers quite surprising. I think her reaction is normal. We humans tend to look for dramatic, memorable events as evidence that something yields value. Pairing rarely generates dramatic, memorable events. The value of pairing comes in the form of very small course corrections that prevent errors from occurring in the first place. The course corrections are of such small scope and they occur so seamlessly within the pair's work flow that they are usually not noticed at all.

This is as it should be; clean code should be a natural outcome of our work, and not something that calls attention to itself by virtue of being abnormal. The value is easy to overlook because the effect of pairing is to prevent situations that would have caused extra work at some future time. Defects do not enter the code base. Technical debt does not accumulate. It's not easy to observe or quantify these effects after the fact, because the bad stuff never happens.

PMI PMTools meeting at Tyson's Corner, Virginia
Topic: Events

I'm honored to have been invited to participate as a panelist at the upcoming PMI PMTools meeting in Tyson's Corner, Virginia, on Tuesday, June 16. The other panelists are Linda Cook, Richard Cheng, and Rodney Bodamer. All four are consultants in the lean/agile space. We will be taking any and all questions from meeting attendees. A few starter questions have been prepared by the meeting organizers in case no one has anything to ask (yeah, right). These have to do with the challenges in implementation, whether agile methods live up to the hype, and how the PM's job changes when an organization moves toward agility. I think it's going to be informative and a lot of fun. You can register here: http://www.eventbrite.com/event/309542851. I hope to see you there!

Success factors for self-organizing teams
Topic: Agile management

The notion of the self-organizing team is fundamental to agile thinking; but not everyone agrees that self-organizing teams are practical. As for me, I think the viability of the self-organizing model depends on the team members, their management, their organizational context, and (possibly) on the nature of the work they do. If we limit the discussion to software development teams, then I would say there are three critical success factors for growing effective self-organizing teams.

1. Clearly define the boundaries. The team has well-defined boundaries within which they may feel free to self-organize and self-manage. Without this, teams aren't sure how far they can go or how much they should attempt to do to manage themselves. When people are uncertain about this, they tend to err on the side of caution and do little or nothing without asking management's permission. That pretty much nullifies the benefits of self-organization.

2. Tolerate mistakes and allow time for learning. The organization is tolerant of mistakes and of learning-curve time. All too often, management declares teams to be "self-organizing," and the first time the team makes a mistake they step in and take "control" of the situation. Once management does that, the self-organization experiment is finished. It will take a very long time and considerable effort before teams will believe management is serious about allowing them to try and self-manage again.

3. Keep the team challenged, yet not frustrated. The team's administrative or functional manager is sensitive to the team's limitations, and adjusts boundaries and expectations carefully so as to provide the team with sufficient challenges to keep them in a state of learning and growing, while not expecting more of them than they can handle. I think it is unlikely that every team in any given organization will be at the same level of readiness and maturity for self-management. Each team will need its own boundaries and challenges so that the organization as a whole can improve its effectiveness.