Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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 ?
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.
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.
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.
