Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Nobody Expects the Agile Imposition (Part II): The Office

by eyepopslikeamosquito (Archbishop)
on Feb 14, 2010 at 12:11 UTC ( #823108=perlmeditation: print w/replies, xml ) Need Help??

Alexander reminds us that people spend most of their time at home or at work; nevertheless, office environments are almost universally empty of real vitality. "They are missing a depth of feeling and richness of function that lets people reach into those parts of their everyday life and work that are really important". He goes on to criticize stereotyped office furniture as one of the prime contributors to an inhuman work environment. The environment produced by office furniture has realized the nightmare of Orwell's 1984 at a level so subtle that many managers are not even aware of it. This is the deathly world that 58 million people in the U.S. are forced to inhabit eight hours a day. Not only is the situation oppressive, but instead of making it better, our culture has invested considerable resources to teach people to accept it without question. Architecture schools and the professional media deliberately mislead the public by insisting that emotional well-being is not a requirement of interior design. As a result, few people imagine that a pleasant work environment is even possible today.

-- World-renowned architect Christopher Alexander

Well, there's good news and bad news. The bad news is that Neil will be taking over both branches, and some of you will lose your jobs. Those of you who are kept on will have to relocate to Swindon, if you wanna stay. I know, gutting. On a more positive note, the good news is, I've been promoted. So, every cloud... You're still thinking about the bad news, aren't you?

-- World-renowned manager David Brent

I've spent most of my life toiling in cubicles of the Alexander-reviled oppressive modern office variety, working for managers not unlike David Brent.

At least the unexpected arrival of the Agile Impositioners brought a change of scenery; a few smart blows from their hammers and my Dilbert-esque cubicle walls came tumbling down around me unveiling a new agile 'commons' ... though 'caves' for individuals to retreat into for quiet contemplation were nowhere to be seen.

Caves and Commons

The phrase Caves and Commons refers to the creation of two zones in the room. The Commons area is organized to maximize osmotic communication and information transfer. For this to make sense, the people in the room must be working on the same project.

The Caves portion of the room is organized to give people a private place to do e-mail, make phone calls, and take care of their need for separation.

-- Communicating, cooperating teams by Alistair Cockburn

An open workspace doesn't leave much room for privacy, and pair programming stations aren't very personal. This loss of individuality can make people uncomfortable. Be sure that everyone has a space they can call their own.

-- The Art of Agile Development by James Shore & Shane Warden (Chapter 6)

Though perhaps ideal as an agile working environment, it's neither trivial nor cheap to convert a typical open plan office into a caves and commons landscape.

It is all right to say that individuals and groups have control over their realms and their work environments, but it simply won't work unless the actual physical materials the building is made of, and the structural systems by which it is put together, actually invite and facilitate this adaptation.

-- Toward a Personal Workplace by Christopher Alexander et al

I'm sympathetic to the reasons given for simply knocking down the cubicle walls: there's no need to spend any money on fancy office furnishings, architects, tradesmen or larger premises. Besides, as Alexander points out, overcoming the horror that is the typical modern office building is problematic. Finally, how do you persuade the bean counters to give you money for extravagant office fitouts for pampered programmers?

While acknowledging the political difficulties of acquiring office fitout funding, it does seem risky to penny pinch in this area. After all, as noted in Peopleware (p.51), the total investment in each programmer is likely to be around twenty times the cost of his/her workspace. Moreover, providing excellent working conditions should lead to other important benefits, such as improved motivation, lower turnover, and making it easier to attract first-rate programmers. Certainly, Google and Joel Spolsky take this seriously.

I'm interested to hear of experiences from folks who've attempted more ambitious and expensive agile office fitouts or used innovative agile office furniture.


One day, while I was describing this peculiar notion of convection currents of information flow, one of the listeners suddenly exclaimed, "But you have to watch out for drafts!". He went on to explain that he had been working in a place where he and the other programmers had low-walled cubicles next to each other and so benefited from overhearing each other. On the other side of their bank of cubicles sat the call center people, who answered questions on the phone all day. They also benefited from overhearing each other. But, and here was the bad part, the conversation of the call center people would (in his words) "wash over the walls to the programmers' area". There was a "draft" of unwanted information coming from that area.

-- Communicating, cooperating teams by Alistair Cockburn

Your team will produce a buzz of conversation in its workspace. Because they'll be working together, this buzz won't be too distracting for team members. For people outside the team, however, it can be very distracting. Make sure there's good sound insulation between your team and the rest of the organization.

-- The Art of Agile Development by James Shore & Shane Warden (Chapter 6)

My new desk in the agile commons was situated next door to our internal systems team. And boy was it drafty! All day long, I listened to them responding to support calls and joking around while doing so. And they often built new PCs, so there was a constant whirring from new PCs under construction. Within a week I wound up with a nasty dose of tinnitis.

While the improved (osmotic) communication within our team was certainly welcome, the elevated noise level, drafts, and constant visual distractions were not. I felt like I was living in a fish bowl, which reduced my general level of psychological comfort and well-being.

People cannot work effectively if their workspace is too enclosed or too exposed. A good workspace strikes the balance ... You should not be able to hear noises very different from the kind you make, from your workplace. Your workplace should be sufficiently enclosed to cut out noises which are a different kind from the ones you make. There is some evidence that one can concentrate on a task better if people around you are doing the same thing, not something else.

-- Toward a Personal Workplace by Christopher Alexander et al

Another chronic difficulty we faced, due to the lack of 'caves', was efficiently solving demanding problems requiring large chunks of uninterruptible time.


Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity... It is a single-minded immersion and represents perhaps the ultimate in harnessing the emotions in the service of performing and learning.

-- Flow (wikipedia)

You hear evidence that this is true in such frequently repeated statements as these: "I get my best work done in the early morning, before anybody else arrives"; "In one late evening, I can do two or three days' worth of work"; "The office is a zoo all day, but by about 6 pm things have quieted down and you can really accomplish something". To be productive, people may come in early or stay late or even try to escape entirely, by staying home for a day to get a critical piece of work done.

-- Peopleware (p.42)

The average employee is interrupted approximately every six minutes. The fall out is that we rarely get the chance to complete tasks and the solutions are that we have to come in early, stay late or take work home. Other fall-outs are that we are losing our ability to focus and concentrate on single tasks. Scientists are now talking about a condition called ADT or Attention Deficit Trait. This is where adult's brains during the day are mimicking a child's brain with ADD. They don't actually have ADD but their brain acts like it does at work, where they can't focus and they start a lot of things but complete very few of them. Also new research tells us that around 28% of the average person's day is lost due to distractions. Almost a third of a person's day is spent going "Now what was I just doing.....".

-- Dr Adam Fraser from Are You Being Bullied by Your Environment?

I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I'd sleep till about 11 am, and come in and work until dinner on what I called "business stuff". I never thought of it in these terms, but in effect I had two workdays each day, one on the manager's schedule and one on the maker's.

-- Paul Graham from maker's schedule, manager's schedule

Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration.

-- Donald Knuth on email

I am a loner; I like to retreat to the mountains or an isolated seacoast, or even just into an attic, and think. New ideas come slowly and require large blocks of quiet, undisturbed time to gestate; and most worthwhile calculations require days or weeks of intense, steady concentration. A phone call at the wrong moment can knock my concentration off balance, setting me back by hours. So I hide from the world.

-- Kip Thorne in Black Holes and Time Warps (p.499)

There is a well-documented psychological state called Flow, aka "being in the zone".

What I found puzzling is that the agile zealots at work seemed to dismiss, or at least downplay, the overwhelming scientific and anecdotal evidence demonstrating how valuable "flow" can be. Instead, they'd become obsessed with boosting "team communication" no matter what the cost.

The reality, of course, is that there's a delicate balance between the need for the team to communicate and the need for the individual and sub-group to concentrate and focus. And this balance varies considerably, depending on the project, the individual, and the team. It makes no sense to attempt a blanket rule on this. Each team must be allowed to organise their own "team communication times" and "individual flow times" in ways that suit them.

I might add that, without caves, it's much harder to get in the zone: some folks donned headphones, others came in early or left late, worked from home, or disappeared with their laptop to a quiet and secluded office location.

Some of our new agile coaches persistently berated our team for being "too quiet" and exhorted us to "communicate more". After a while, this became so ridiculous that we began to feel like the unfortunate Belcerebons of Kakrafoon Kappa.

The Belcerebons of Kakrafoon Kappa had an unhappy time. Once a serene and quiet civilization, a Galactic Tribunal sentenced them to telepathy because the rest of the galaxy found peaceful contemplation contemptuous. Ford Prefect compared them to Humans because the only way Belcerebons could stop transmitting their every thought was to mask their brain activity (or its readability) by talking endlessly about utter trivia.

-- Hitchhiker's Guide to the Galaxy

Other Articles in This Series


  • Comment on Nobody Expects the Agile Imposition (Part II): The Office

Replies are listed 'Best First'.
Re: Nobody Expects the Agile Imposition (Part II): The Office
by BrowserUk (Patriarch) on Feb 14, 2010 at 13:40 UTC

    I think that all 'new' methodologies only work for those who haven't already established their own methodology.

    If you impose an always drive on the left (or right) rule, where there was previously no such rule, you'll see a considerable improvement in traffic flow. But take away an experienced carpenter's Yankee screwdriver, and force him to use an electric one and his productivity will fall sharply.

    The problem with new methodologies is that they become self-serving. Someone strings together half a dozen simple--and often common sense--ideas that work for them and their group and utilise it successfully on one or two projects. Inevitably, someone (usually someone else) sees the possibility to make money from them.

    So they take those half-dozen ideas and formalise them. In the process they throw in a few buzz words de jour, some self-evident good practices wrapped over in marketing speak, and generally baulk up the whole thing with a few tortured analogies. They then set about the task of selling you (or more likely, your boss), on their "solution", with nary a care for whether it actually solves your problems.

    A couple of questions to ask yourself (or your boss) when considering any new methodology:

    • Does the seller have anything to lose if your project fails? Or fails to gain from its introduction?
    • If you take the products main "How to..." or "Guidelines..." or "Instruction manual" document, and remove all the hyperbole; excessive adjectives, adverbs and superlatives; marketing speak; cutesy and/or tortured analogies; similes and metaphors; unverifiable statistics, bar charts and graphs; and customer testimonials.

      Ie. Reduce it to plain language that simply tells you what they are suggesting you do at each step.

      Does what's left a) still make sense; b) constitute anything more than just common practice and common sense?

    • If you are considering imposing this methodology upon an existing team, does it advocate or require that team to discard all their existing, hard won, proven practices?

    Snake-oil salesmen have been around for hundreds, if not thousands, of years. The products and pitches may change, but the underlying scam hasn't. It still relies upon taking something of low real cost (and usually little real value), and pitching it as the Golden Hammer, Silver bullet or Zauberkugel for a wide-spread, intractable and costly problem.

    And there is still one born every minute!

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Nobody Expects the Agile Imposition (Part II): The Office
by talexb (Chancellor) on Feb 15, 2010 at 15:47 UTC

    Having been a developer of software for .. quite a while, I know from personal experience that 'flow' is a real thing -- I'm very productive when I'm lucky enough to have gotten into the 'flow', and I'm very frustrated when someone or something interrupts that 'flow'.

    Interestingly, my team lead, who's a great guy and a terrific developer, started using this 'pomodoro' technique to get stuff done. I tried that for a while, but stopping work after 25 minutes to take a breather wasn't working for me -- I'd rather go until I needed coffee, the men's room, or until I'd gotten to a good breaking off point.

    I'm sure the pomodoro's good for something -- but it doesn't help me any doing software development.

    Excellent quotes, BTW. :)

    Alex / talexb / Toronto

    Team website: Forex Chart Monkey, Forex Technical Analysis and Pickpocket Prevention

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Nobody Expects the Agile Imposition (Part II): The Office
by Jenda (Abbot) on Feb 15, 2010 at 15:18 UTC
    cubicle walls came crashing down around me unveiling a new agile 'commons' ... though 'caves' for individuals to retreat into for quiet contemplation were nowhere to be seen.

    How come this doesn't surprise me the least bit? I'd actually bet this is what happens most of the time. Every other thing suggested by whatever the selected methodology must be followed to the fullest (especially if it requires some work for the developers), but when it comes to allowing the workers to actually work ...

    'cause, you know, when you're communicating, the manager may look and see you're all there, you're babbling in techspeak, maybe you even draw some diagrams on the whiteboard, ... everything's apparently working. But then you would disappear somewhere he/she can't see you and God only knows what you'd be doing there. Nope dude, I've got to see you. Great that we found this methodology that allowed us to bring down the cubicle walls ...

    Enoch was right!
    Enjoy the last years of Rome.

Re: Nobody Expects the Agile Imposition (Part II): The Office
by zentara (Archbishop) on Feb 14, 2010 at 15:55 UTC
    here is a well-documented psychological state called Flow, aka "being in the zone".

    I believe this state is induced by the flow coffee and sugar. :-)

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku
      I believe the list of substances /(ab)?used/ to reach this state is a little bit longer than your optimistic example.


      You can lead your users to water, but alas, you cannot drown them.
Re: Nobody Expects the Agile Imposition (Part II): The Office
by davies (Prior) on Feb 15, 2010 at 18:26 UTC

    If your office is anything like my current job, space is at a premium. If you are looking to apply pressure, you might try booking whatever meeting room will just accommodate you and any like-minded colleagues from, say, 10 to 12 and 2 to 4 every day. Call it "cave meeting". When challenged, explain that you are embracing Agility, but that until your caves are built, you have to do this instead. "Do you have any timetable for building the caves, because we've been told nothing. Some people still seem to have a problem with Information Transfer. And having just a little bit of the system means we're missing so many of the benefits that productivity is actually falling, so there's a great danger that the whole project might fail". Of course, if anyone knows your ID here, that might not be credible...


    John Davies

    Update 2019-03-16: Confirmation of something I've long suspected:

Re: Nobody Expects the Agile Imposition (Part II): The Office
by Herkum (Parson) on Feb 16, 2010 at 22:24 UTC

    It surprises me that so many managers don't really understand operations, mainly how things get put together. But then again, considering how many managers I have had don't understand programming, maybe I should not be.

    If you have someone who has never done the task that they are asking someone else to do, is it any surprise that they don't know how to solve issues that crop up?

    Too often I find that managers not only need the problem explained to them but the solution as well. The only role they seemed to be playing is intermediary between their department and another departments manager.

      A good manager need never have done the job she or he is supervising. Her or his role is that of facilitator.

      A manager does his or her job well by:

      • Clearly defining what work must be done when.
      • Clearly defining priorities. What work takes precendence over other work?
      • Remove impediments that prevent his or her workers from completing their tasks.

      The only way to achieve these three things is to respect and listen to your staff. If you think of them "human resources" or dolts and not people, you can never manage effectively.

      As a programmer, I shouldn't need to think about inter-office power squabbles or pissing-matches between account management and operations. These things don't concern me. To the extent that I am distracted by these issues, and my productivity suffers, my manager is not upholding his or her responsibility. All I need are the specs and a schedule.

      Mutual respect is worth 1000 times any level of 'in field' experience a manager has to offer. This applies whether you are dealing with cannery workers sorting out rotten fruit, car salesmen or engineers.

      eyepops manager should ask for feedback on the new agile approach. S/he should be able to accept negative feedback - "I hate it". S/he should be willing to ask "Why?" and accept an honest answer. Finally, s/he needs to ask "How can we make things better?". Once s/he has this info from eyepops and his coworkers, s/he can determine how best to advocate for her/his staff to maximize productivity.

      None of the above steps are possible without mutual respect.

      TGI says moo

        I completely agree, though I do appreciate a technically competent manager because it makes things go quicker in discussions. The problem is that mutual respect is like a dog that speaks Norwegian. That and it's only the foundation that is needed to support all the competencies involved. I've had... 5, maybe 10, managers out of 30 who were competent at anything in particular, let alone management.

        Something else occurs to me about respect. The employee is much freer to give it properly when it's earned. The manager is constrained by the machinations of the company and its hierarchy and is more often regulated to "chief apologist" than to "team advocate" no matter her skills or intentions.

        This whole thread makes me :(

        Like Your Mother, I appreciate a technically competent manager. While general management skills trump technical competence for high level managers, lower level managers of programmers at the coalface do require technical skills IMHO. At least, that's been my experience.

        Let me give an example to clarify. I remember one particular "delivery focused" programmer with a "strong sense of urgency". Rather than taking the time to properly abstract the design, he crudely cut n pasted thirty new classes from an existing one. Now these thirty classes were identical, except for one line of code!! Of course his code never contained any useful comments because these take time. This fellow consistently left behind huge swathes of unmaintainable code, yet his non-technical manager -- who never looked at the code -- praised him and even gave him bonuses and little plaques for his "strong sense of urgency" and "can do" attitude. You might argue that a better non-technical manager, one who understood technical debt, would not do this (and I agree), yet non-technical managers must rely on others to judge the technical merit of the work produced by their staff. And in a political, non-trusting organisational culture, that results in people playing silly games (e.g. if you tell my non-technical manager that my work is of high quality, I'll return the favour to you).

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://823108]
Approved by BrowserUk
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2023-09-23 11:43 GMT
Find Nodes?
    Voting Booth?

    No recent polls found