Two Forgotten Agile Values: Ease and Joy
The short version: Valuing ease at work means that the team is always trying to make difficult or annoying tasks more pleasant. It can be hard to justify that effort on short-term utilitarian grounds, which is why ease needs to be a value in its own right. Joy is perhaps even harder to justify, but people nevertheless deserve to work on projects so great they rave about them at parties.
In a previous essay, I argued for the values of discipline and skill. That's not exactly a brave stance: few people are running around saying "I'd never hire anyone who's disciplined," nor do you see many job postings saying that those skilled at unit testing need not apply. The next two values are a little braver.
The more easily defensible one is ease at work. When I visit good Agile teams, I see them relentless chipping away at hard or unpleasant tasks, gradually converting them into tasks no one dreads. There's a pervasive attitude that, once we have the right skills and the discipline to apply them, software can be soft. Deployment doesn't have to be a nightmare. Testing a new release shouldn't require painful poking around in some copy of the production database, searching for test data. You can even afford to get the database schema wrong and fix it later.
The problem with this chipping away is that a reasonable person can always be argued out of it. After all, an hour spent making deployments easier is an hour not spent on some task directly relevant to business value. And how many slightly easier deployments is it going to take before we earn back that hour? Such crisp arguments win out over woolly arguments about how a change useful for deployments might turn out to help something else, or that maybe once deployments are easy we'll be able to do them often (even though no one is asking for that now), or that too many locally good decisions can lead to global inefficiency. The way to counter such a tragedy of the commons is to make ease of work a core value.
That's not to say that ease of work doesn't increase the need for discipline. The lore of testing is full of people who spent weeks improving test automation libraries without ever, you know, quite getting around to automating any tests. The trick is to make improvements in small steps while simultaneously continuing to frequently deliver the business value that makes the project worth funding. There's a real skill to moving gradually and continuously and simultaneously toward several larger goals.
Joy was one of the things that attracted me to Agile projects. On so many of them, people made sure to tell me theirs was the best project they'd ever worked on. It was especially gratifying to hear that from business representatives (XP customers or Scrum product owners: what I call a product director).
Joy is one of those things that everyone claims to value, but how many people, faced with a specific business or technical decision, give weight to which choice makes people on the team happiest? For example, you can make an argument that the programmers need higher-power, better equipped machines than the testers. And yet, the testers are probably already a bit touchy about their relative status, and buying them low-end machines will exacerbate that. Who would get them equivalent machines (plus a few low end machines for representative-user testing) just to make them feel better? Or consider two programmers locked in an intense discussion about which design direction to take. How many would let the other person have her way, just because that's a pleasant thing to do? (And because, after all, the point of Agile projects is to be able to change direction gracefully when you realize a new one is better.)
Even leaving aside how many supposedly cold-blooded decisions are nothing of the sort, a constant stream of decisions that ignore feeling breaks the spirit. As King Lear put it:
O reason not the need! Our basest beggars
Are in the poorest thing superfluous.
Allow not nature more than nature needs,
Man’s life is as cheap as beast’s.
People deserve joy at work. I could say that a joyful employee is a productive employee, and that lack of joy on a project is like a canary keeling over in a coal mine: a sign that something big is wrong and you better pay attention. Maybe that’s true. I’d certainly like to believe it. But, fundamentally, I don’t care. I think joy is its own excuse.
Having said that, I hasten to add that joy—like ease—is something achieved within (and even because of) the steady and frequent delivery of business value. It's a joy in doing a particular kind of work. Should you hire me, I will not try to turn your project team into a permanent floating party!