If You Don’t Buy the Philosophy, Don’t Bother with the Practices

I used to roll my eyes when proponents of a certain methodology, when confronted with failures of projects using that methodology, would say things like, “You’re doing it wrong! If you would just perfectly execute every suggestion in this book I’m selling, you wouldn’t be failing.” After a while you start to wonder if it’s so hard to do it The Right Way then maybe there’s a problem with the methodology itself.

The Laughing Philosopher

Lately, I’m come across several posts from writers I respect criticizing Scrum and “Agile” methodologies as micromanagement and as ways for authoritarian managers to assert themselves over development teams

Scrum's standups are designed to counteract an old tradition of overly long, onerous, dull meetings. However, at both these companies, they replaced that ancient tradition with a new tradition of overly long, onerous, dull meetings where management got to sit down, and everybody else had to stand. Scrum's attempt at creating a more egalitarian process backfired, twice, in each case creating something more authoritarian instead.

- Giles Bowkett

My personal experiences with “Agile” teams have generally been good. By the time I entered the industry in 2005, Agile ideas had spread considerably and I can’t say that I’ve ever been in a software organization that was doing Waterfall.

But, I have seen dedicated micro-managers when required to “do Scrum” turn that daily standup right back into their familiar morning status meeting where the team one by one turns to the highest ranking person in the room and reports their status directly to that person. What I won’t do though is ascribe this phenomenon as a failure of Scrum as a methodology.

Just like any large body of literature, one can essentially read anything they want into it. As I said in a previous post, I believe that Agile is a philosophy akin to egalitarianism. And at its core it’s about self-organization.

In Succeeding with Agile, there’s a good quote from Jean Tabaka:

I work primarily with Scrum teams, and those that struggle the most typically have a command-and-control project manager or a decision-oriented technical lead as ScrumMaster. Without a facilitative, servant-leader mode of team guidance, the agile adoption will be only a thin veneer over non-empowered, demoralized teams.

One of the saddest things to see is a software organization where people at the top have convinced themselves that what matters about the methodology du jour they have cast upon their people is the list of practices associated with the methodology. “If I see my people doing these practices, then I’ll know they’re embracing the methodology.”

But the practices mean nothing without the philosophy. A team can do planning poker sessions until they’re blue in the face, but if they’re working under a manager that believes he knows better than the developers how long their work will take, the whole exercise is pointless. Any practice can be letter-of-the-lawed and still give you no benefit.

Author of the popular book The Art of Agile Development, James Shore, explains in a post from his blog:

Agile development isn't just about good engineering practices. It's also about acknowledging the importance of people in software development, forming cross-functional teams, obtaining high-bandwidth communication, constantly reflecting and improving, delivering value, and changing plans to take advantage of opportunities.

Scrum includes these other points. It says that the team should be cross-functional and recommends collocating the team in a shared workspace. It says the team should deliver a valuable, shippable product at the end of every Sprint, and that the team should self-organize, discover impediments, and remove them.

Oh, and it also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That's right--Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.

If you want to benefit from a particular methodology, whatever it may be, people must buy into the philosophy first, or don’t bother.

The Library and the Bazaar

In Christopher Alexander’s discussion of his Workspace Enclosure pattern, he mentions this interesting concept:

You should not be able to hear noises very different from the kind of noise you make, from your workplace. (Your workplace should be sufficiently enclosed to cut out noises which are of a different kind from the ones you make. There is some evidence that one can concentrate on a task better if people around him are doing the same thing, not something else.)

This is an idea that seems simple, perhaps common sense, but as I’ve come to realize through my investigations into office design, common sense is not so common.

Here’s a paraphrasing of the idea, as simply as I can state it:

Put things that sound similar together, and isolate them from things that sound different.

This idea (should) affect every aspect of office layout.

Here are some examples:

  • Don’t put people who talk on the phone often within earshot of people who don’t. Put the “phone people” together, away from the non-phone people.
  • Don’t put a copy machine and/or printer within earshot of desks. Machines and people make different sounds.
  • Team rooms: people who work day in and day out on a certain project should be sound-isolated from those who don’t. Overhearing someone’s conversation is a lot less annoying if it’s highly relevant to you.
  • Group non-work things together and sound-isolate them from work things. It’s cool if the microwave and the air hockey table can hear each other, but put a wall between them and any desk.
Nope Yep
Ping pong and desk bad Ping pong and lunchroom good

There’s a fantastic white paper written by the GSA called Sound Matters, which is free and a quick read. Within, they explain the concept of the Library and the Bazaar:

The contrasting needs of the modern workplace can be seen as “The Bazaar” and “The Library,” with different acoustic needs and responses appropriate for each.

“The Library” is an analogy for a workplace environment where both quiet and speech privacy are expected to optimize the ability to concentrate.

“The Bazaar” is an analogy for the expectation that the area is not private, where sharing is the norm… Noise is far more acceptable to workers in the bazaar and a high level of intermittent background noise is expected.

The workplace needs libraries and bazaars, with sufficient noise isolation between them. The problem with many trendy open-plan offices is how they place everyone’s workspace into a bazaar.

Which way to the library?
In staged glamour shots like this, no one has to work at these desks.

There’s a certain fantasy promoted by open plan enthusiasts about how surrounding your people with a sea of random conversations and noises all day will lead to serendipitous collaboration / synergy / magic. What I’d suggest is that the bazaar is the place for these conversations, not the library.

Even if you don’t believe in a private office for every individual, don’t force everyone into a bazaar.

Technicians Get No Respect

I believe one of the fastest ways we developers can lose the respect of so-called “business people” is to behave like technicians.

Technician

What do I mean by technician? Here are some things a technician might do:

  • Become visibly angry when a business reality compromises their carefully planned inheritance chain
  • Declare that they are blocked on implementing the automated notification system the business requested until someone tells them what the subject line of the emails should be
  • After hearing the description of a report the business would like to see, their response is, “Can I use D3?”

The technician thinks primarily in terms of technology and expects the non-technical person to adapt to this way of thinking when the two interface. As Chad Fowler explains in My Job Went to India:

You might be “just a programmer,” but being able to speak to your business clients in the language of their business domain is a critical skill. Imagine how much easier life would be if everyone you had to work with really understood how software development works. You wouldn’t have to explain to them why it’s a bad idea to return 30,000 records in a single page on a web application or why they shouldn’t pass out links to your development server. This is how your business clients feel about you: Imagine how much easier it would be to work with these programmers if they just understood what I was asking them for without me having to dumb everything down and be so ridiculously specific!

The technician believes that careful choice of technology is primarily what makes a software project successful. Peopleware tells us otherwise:

The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do. […] Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work.

If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, "The light is better there."

Imagine that you were feeling depressed and decided to see a psychotherapist. After an emotional retelling of your troubles and the pain you’re feeling, the therapist responded with, “Would you like me to treat you with Gestalt therapy, ACT, or psychoanalysis?”

Avoid being labeled a technician:

  • Exercise independent judgment regarding non-technical decisions. You’re not a code monkey!
  • Also, don’t foist technical decisions on non-technical people.
  • Care about the high-level objectives of the software you make. Show a holistic concern for the success of the project.
  • Ask stakeholders about the why behind the features they want.
  • Use the language of the business when talking to non-technical people (and as much as possible with technical people).

As you move from technician to solution provider, people treat you differently.

Further Reading

Are Software Developers Respected by “Business People”?

In the Hacker News thread for my last blog post, there were a couple of comments that really got me thinking about the role respect plays in bad office design.

Is it time to get depressed yet? This has been a topic for such a long time. It was in Peopleware in 1987. I thought I discovered the topic when Joel (On Software) wrote about it in 2000. While a few people seem to enjoy open offices, the overwhelming majority of developers I know, or who chime in on HN, value a quiet place to work and dislike open offices.

And yet, not only has nothing changed, it seems to be getting worse. It couldn't be more clear to me that developers, at least on this issue, simply have no clout as a profession. There may be a few individuals who can make demands, but on the balance, these are decisions imposed on us, as a group, and we are apparently unable to do anything about it.

-- geebee

In a response to the above comment:

30 years ago programmers were highly respected. We were mysterious to others and we were able to influence things like office layouts and the like.

At some point over that time period, things shifted. Programmers became seen as "geeks" who didn't really understand business and "business guys" took over.

They have no concept that we might know what we're talking about because "office space is the realm of business."

We're not capable of decision making and we have no understanding beyond our weird obsession with those stupid computers. -- that's how they see us. They'll lie and say otherwise, but deep down and a fundamental level, that's how non-technical people see us.

-- MCRed

Is this true? Are software developers “geeks” that lack clout and respect with the “business people”?

If so, why is that? Have we earned our lack of clout/respect? I have some thoughts on this that I’ll explore in a future post.

In the meantime, let me leave you with this question: If you believed that an employee of yours did extraordinarily challenging mental work, which required extreme concentration, would you put them here to do that work?

Classic open plan office

Just Wear Headphones

In the comments people have written in response to my posts about open plan offices, a common theme was that of headphones (or earbuds) and how they are oversold as a solution to office noise.

In this post, I want to elaborate on a few issues with headphone use that hold them back from being a silver bullet.

Developers using headphones and earbuds

Physical Hearing Damage

There are permanent physical consequences from prolonged headphone use. The effects accrue gradually, and as such people don’t notice that it’s happening.

From the American Osteopathic Association, Dr. James Foy explains:

I stress to my patients and the parents of my patients that if you can’t hear anything going on around you when listening to headphones, the decibel level is too high.

As a rule of thumb, you should only use [personal audio] devices at levels up to 60% of maximum volume for a total of 60 minutes a day. The louder the volume, the shorter your duration should be. At maximum volume, you should listen for only about five minutes a day.

ENT physician, Dr. Michael Seidman, continues in an article from the New York Times:

If you listen to music with earbuds or headphones at levels that block out normal discourse, you are in effect dealing lethal blows to the hair cells in your ears.

When you’re working in an environment so noisy that you have to pump music (or white noise) into your ear canal so loudly that it blocks out the other noise, you are doing permanent damage to your hearing.

Music Is Distracting

This is one of the trickier issues to discuss, as people love music and have a hard time separating the pleasure they get from listening to music from their effectiveness while listening to music.

If you ask software developers about what they blast out of those ubiquitous headphones, you’ll get answers like this:

"It's not just something in the background to help me concentrate; it's a source of inspiration, a door to free my mind from our day-to-day routines, and, at the same time, it's a way to memorize an experience," says Ortali. "I play tracks in a loop, sometimes the exact same track all day long. It's a way to connect with the lyrics, and move the tempo beneath my skin."

Scientific minds get very un-scientific when it comes to their favorite music.

In a terrific article from The Atlantic,How Headphones Changed the World:

In survey after survey, we report with confidence that music makes us happier, better at concentrating, and more productive.

Science says we're full of it. Listening to music hurts our ability to recall other stimuli, and any pop song -- loud or soft -- reduces overall performance for both extraverts and introverts. A Taiwanese study linked music with lyrics to lower scores on concentration tests for college students, and other research have shown music with words scrambles our brains' verbal-processing skills. "As silence had the best overall performance it would still be advisable that people work in silence," one report dryly concluded.

If headphones are so bad for productivity, why do so many people at work have headphones?

That brings us to a psychological answer: There is evidence that music relaxes our muscles, improves our mood, and can even moderately reduce blood pressure, heart rate, and anxiety. What music steals in acute concentration, it returns to us in the form of good vibes.

Headphones give us absolute control over our audio-environment, allowing us to privatize our public spaces.

People conflate the positive psychological effects of creating a cocoon of their favorite sounds in an environment of noise they can’t control with positive effects on their productivity.

Feeling of Vulnerability

As I touched on in a previous post, seating people with their backs to a high-traffic area leads to a constant sense of unease and vulnerability.

Back to the action

People in this position have lost their sense of sight to detect when someone is approaching them. When you add headphones to the equation, they’ve now also lost their sense of hearing.

Headphone use in a noisy open plan environment can be a catch-22. The noise is so oppressive that you want to block it out, but then you have to deal with the feeling of vulnerability and frequent startles of people approaching you from behind without hearing them.

So What to Do?

Headphones are not the new walls. Give people a quiet place to work or let them work from their own.

 

Side Note: Noise-Cancelling Headphones

I want to quickly address “noise-cancelling” headphones in particular, as they are mentioned often as a quick fix for the problem of office noise. The technology at use was designed to cancel the low, constant rumble of aircraft engines. So while it may work to cancel the noise of your office air conditioner, it’s powerless against the voices of your co-workers (the real noise you’d want to cancel in an office environment). Read some of the reviews for the popular Bose QuietComfort noise-cancelling headphones, and you’ll get the picture.

The "Phone Room"

Here’s another office design 101 thing that I want to get out of the way: the importance of temporary private space for people stuck in open plans.

These private spaces sometimes get labeled as “phone rooms” or something similar, implying that they exist for a person to take their loud conversation away from the rest of the workers. Well, the exact opposite situation is at least as important if not more: for a person to get some quiet away from the loudness of the general office environment.

Phone room

We already know that some people need more quiet time than others. And headphones are not a substitute for quiet.

Let’s stop calling these “phone rooms” and ensure there is no judgment from anyone who matters about people using these rooms simply for quiet time.

How to Make Your Open Plan Office Suck Less

Open plan offices suck, but there are some easy ways to make them suck less. Here are three ways that simple desk positioning can make a big difference in the suckiness of your open plan.

1. Lower Density

Lower density means less noise. Put more space between desks.  

red16 Sucks:

High density sucks

yellow16 Sucks less:

Low density sucks less

2. Face Space

Don’t seat people where their line of sight goes through a nearby face. If you haven’t felt the awkward tension of having someone’s visible face right behind your monitor while working all day, then congrats, your open plan sucks a bit less.

red16 Sucks:

Face-to-face bad

red16 Sucks:

Face-to-side-of-face bad

yellow16 Sucks less:

Facing in same direction better

3. Watch Your Back

Don’t seat people with their back to a high-traffic area. People in this position feel constantly vulnerable and cannot have one moment of screen privacy. Ask these folks to wear headphones, and they’ll feel even more vulnerable.

red16 Sucks:

Back to the action bad

yellow16 Sucks less:

Facing the action better

 

If you’re committed to an open plan office (shame on you), then at least get these things right.