My organization is moving to Agile process of software development. As part of it, the developers and quality engineers will sit together with the cubicle walls scaled down. I am just wondering how does it satisfy one of the Joel's test - programmers should have quiet working conditions.

Does it not contradict it? If yes, is it taken as granted while adopting Agile ?

  • 3
    agile & working conditions aren't synonymous (at least in my experience). You can roll out minor/frequent changes and still do so from the comforts of a cozy office. – Brad Christie Apr 26 '13 at 16:01

Work-related noise is common in Agile environments.

One might think that this would be a distracting environment. it would be easy to fear that you'd never get anything done, because of the constant noise and distraction. In fact, this doesn't turn out to be the case. Moreover, instead of interfering with productivity, a University of Michigan study suggested, working in a "war room" environment may increase productivity by a factor of 2.

Robert C. Martin - Agile Principles, Patterns, and Practices

On the other hand, non-work-related noise should be avoided at all costs.

Peopleware is the oft-quoted source for why thought-workers should be able to work in relative quiet. But, even Peopleware, after describing a working environment where regular tannoy announcements interrupt an entire office full of people to attract the attention of one, goes on to talk about perfect working environments where a team sit together in an office, with full control over where the desks and other furniture is positioned.

Peopleware suggests that every thought-worker should get a lot more space than most of us get, but it still doesn't suggest complete isolation. In fact, it explains in great detail how a team will develop its own cycles of noise and silence. My observations in teams isolated from the business, but not each other, have been the same.

  • 3
    "In fact, this doesn't turn out to be the case." ... In the short term. IME, beyond short timespans, teams in war room scenarios become homicidal. – Steven Evers Apr 26 '13 at 16:39
  • 1
    @SteveEvers: That's not my experience. Nor is it, apparently, Uncle Bob's. Are you sure there wasn't another factor involved? Or are you confusing war-room environment (one where everyone is constantly communicating and working toward a common goal) with the so-called high-paced environment (where everyone is shouting at each other cause they have a dozen unreasonable deadlines to hit)? – pdr Apr 26 '13 at 16:43
  • 1
    @pdr Good to point out that many people don't know the difference between those, unfortunately. – Jimmy Hoffa Apr 26 '13 at 17:57
  • 1
    @SteveEvers I worked for a year and a half in an office with 2 (sometimes 3) other engineers where we all collaborated frequently, and when we were on separate projects would collaborate as people outside of our office would come to our office for the whiteboard etc. There was never a hostile or fast-paced sense about it, just a continually collaborative environment where we knew what we were all up to each day. Anecdotally I have disproved your posit that one always leads to the other. Also your claim that all humans are so bothered as such is presented without evidence... – Jimmy Hoffa Apr 27 '13 at 1:33
  • 2
    @SteveEvers You're describing a sweat shop, not a war room. I think no one who supports the bull pen style environment would ever say to put that many people in a space. Yeah I agree; we just had a disconnect of terminology then, and I am deeply sorry you ever worked in an environment like that heh – Jimmy Hoffa Apr 29 '13 at 14:08

I would say the noisy conditions Joel's test is concerned with are things like putting your engineers in the middle of managers or a call center. When the noise is occasional engineering conversations, I would say this is not what Joel is trying to shield people against.

If these conversations are constant, and frequently not relevant to the developer, then the engineer is in a poor grouping. If they are relevant to the developer and still constant, then somebody needs to figure out what's wrong with the process that there needs to be constant dialog with the developer; who doesn't know what they're doing or what isn't clear to everyone? This is commonly an occurrence when requirements are in constant flux, which is a whole problem unto itself.

There should always be the ability to go heads down on something to get into the zone for a developer though, but for the vast majority of us headphones provide this opportunity when necessary. If a particular engineer is so sensitive to his environment that headphones do not help, or the environment is too cramped for it to be helped at all, this issue should be raised. If you think you'll be too distracted that headphones won't help, be an empiricist first and try it, I've known a minimum of engineers who didn't find this sufficient.

Collaborative environments mean open communication channels; they don't mean people sitting on top of eachother being cramped.

If you find music too distracting, I knew an engineer who would listen to rain all day http://www.rainymood.com/

All of this said, I've worked places that had secluded offices 2 engineers per, I found good engineers who are collaborative will communicate just fine in these environments and definitely don't need the bullpen style cube layouts, though these cube layouts are still preferable to the alternative cube layouts I've found, and are beneficial to teams which aren't all skilled collaborative folks. We don't all get nothing but the best on our teams.


Agile is releasing frequent iterations and shouldn't be correlated to where you develop. It sounds to me like your manager/management staff decided that the developers and QA should work more closely as to see changes and enhancements through. (Maybe because in their eyes projects are taking too long, or the developer's always saying "I'm waiting on QA" and, likewise, from QA it's "I'm waiting on the developer"). Sounds like they're trying to absolve a communication disconnect (at the cost of privacy).

I work on a staff of 4; one beside me and two others in another facility. We use the agile approach and synchronize efforts through email, google talk and sometimes check-in notes on TFS. But the fact that we're not beside [on top] of one another doesn't hinder our ability to roll out successive changes [be agile]. We;re still able to go back and forth, see through bug fixes and release new iterations daily, but we also have the privacy of our own working quarters, too.

I've posted before on avoiding distractions in the workplace. It's possible to be in sync without being next to each other. It's just about managing communications and getting to an even playing field that everyone respects and and the end result is successful.

  • 1
    Please don't propagate the confusion between Agile and Scrum (releasing in frequent iterations). Scrum is an Agile methodology, but it is not equal to Agile. XP is also an Agile methodology and has everything to do with your working environment. – pdr Apr 26 '13 at 16:39

I think they do. Joel thinks programming at some point is not a team sport and requires a programmer to solve the tough problems.

I don't know if coding in isolation, in pairs or in a room where everyone can hear what is going on is best. Agile doesn't always mean pair programming and open-concept rooms. A lone dev can deliver in an agile way. What is important is to have the environment consistent with what is expected.

If you want programmers to work alone, give them a private space. Not everyone can concentrate with headphones on for 8 hrs a day. There are probably a lot of other factors that a company/manager will fail at if they don't optimize things for their devs. It's tough to be productive when you don't think your company cares about you.

  • Frankly I am working in an environment, large organization, middle manager never did any programming, and I know they do not care. When I told them I was distracted by the noise, it was my own shortcoming. I was not communicative, I was not agile. It was one of the essential thing that made me loath agile. I totally hate agile for this exact reason. The noise, and the fact that if you complain about the noise, you are the apostate that is not agile. I hate my job, but I keep my mouth shut. – JaJa Oct 10 '17 at 7:25
  • They may call what they’re doing agile, but your management has problems with or without being agile. There are places that know what they’re doing and as a result make it easier to change software when needed. That’s what being agile is all about. How you accomplish that can vary. – JeffO Oct 10 '17 at 15:49
  • This is exactly what religious currents say: if something bad comes out of <religion I>, it is not really <religion I> because <religion I> is good. You are saying the same thing about agile. If you do not like agile, it is because it is not the real agile. Second this easier to change? What the heck? That is general OO, that existed long long before anyone every invented the agile cult. That is what agile is all about? No it is not. That is what just making software is about. All these 'agile' values existed without 'agile'. – JaJa Oct 14 '17 at 21:27
  • @Jala - I'm saying agile can be implemented properly. It's not an impossibility, but neither is it perfect. No one ever said that agile practices are exclusive and never existed before agile became popular. Some aspects involve doing things the same way as programmers always have even if no one explicitly acknowledges it or is willing to admit it. There are practitioners of agile before agile was cool. – JeffO Oct 20 '17 at 14:17
  • Agile is not cool, agile is an annoying management fad. I loathe agile, I do not even want to talk about this **** any more. – JaJa Nov 4 '17 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.