Is Agile Stifling Introverts?
infoq.com
infoq.com
I've worked in cubicle farms, private rooms, shared rooms, and clustered team cubicle rooms. Cubicle farms are equally abhorred to open plan. I think the best mixture is shared rooms with private meeting rooms on a reservation basis, preferably with the private rooms along the windows and meeting rooms in the middle of the building.
It's the worst of both worlds: we're paying for both cubicles that nobody uses and big conference rooms being used as single offices, and people are even more isolated than if they'd just been given normal offices to begin with.
It reminds me of situations like Prohibition (and I'm sure you can think of others): we don't like X, therefore we'll legislate against X, and ignore the fact that people are going to do X anyway, and so our legislation actually makes things worse.
I mean, "how can we know you're actually working. You're at home, we can't see you producing."
They moved us from cubes to a 'collaborative workspace' at a company where working from home is fine, almost encouraged. It wasn't the managers that choose this, it was higher up who believe collaborative is nothing but a buzz word.
In both the work from home (which happened before and will probably increase) and the collaborative workspace, the measure of getting your work done is 'did you get your work doneon time' not 'do you look busy.'
"It wasn't the managers that choose this, it was higher up who believe collaborative is nothing but a buzz word."
always worries me, because it's that kind of higher level management that, 3 months later, stops by the awesome collaborative workspace he told you to use, finds it mostly empty because everybody is at home, and shuts down the work-from-home policy in spite of the fact that people are getting work done.
Sure, you can point out that people are getting their work done, but (again, I know I'm stereotyping here) that seems to be the kind of management that doesn't let facts get in their way.
I have not achieved a state of mental flow in over a year. If a place I'm
interviewing at has adopted the open floor plan, it's a deal breaker.
I hear you. As an aside, does anyone know of any dev shops in Sydney (Australia) that don't use open-plan setups? I've been going for nine years, and I've only ever seen one (Campaign Monitor); the rest have been benches, or benches separated by low walls.(I'm not saying it isn't true, just that I assume by the way you've stated this you're a developer that's rarely left alone to get anything done, and I can't see how that's beneficial to your employer.)
During the day I may solve up to a dozen small problems, which might be a small customization of the font-end for a big client, debugging a random bug or two on the spot, querying the database for some new sales stat, and so on. If something comes in to our bug-tracker that I think I can resolve within 30 minutes, I do it immediately. The rest of the time I work on the long term (no deadline) projects to improve the system as a whole. Sure those projects suffer a bit but our clients are always very impressed when we can fix his bug, make his customisation change or implement his new report, literally just minutes after he requested it.
your manager can either stop it by charging your time back to the requestor ( I would suggest you track the requests -send emails sayi g Bob you wanted a new sales report, it's third on list and expect it 9am)
or he can explicitly Market you to the business - what I previously did. And it is a powerful weapon for your manager. The higher ups feel well treated and the department gets all it's interrupts funnelled thru one person, who in your case seems good at it and happy to do it
but I strongly suggest you track the work, and push the marketing value of what you do.
I work in an unusually noisy operation, right next to ecommerce field ops and my Ultimate Ears are a godsend.
At the VP/CTO level, it wont help because you will be talking to people all day anyway.
At VP/CTO level, you're not coding most of the time, you're coordinating. That's a completely different story.
That's great for you. But I find headphones uncomfortable to some degree. I find music distracting much of the time. I've tried, believe me. I think I'm not alone in this, so expensive headphones are not a total answer. But the larger issue remains: why should individual employees have to find ways around a productivity-killing environment created by the employer? It's absurd.
Note: some time ago on another HN thread I wrote a similar comment. I feel it's worth repeating my sentiments here. On that thread, amusingly, people responded to me with suggestions for nicer headphones and types of music. Don't bother for two reasons: 1) I've explored the options already, and 2) you're missing my point entirely.
Edit: This has nothing to do with Agile though, we're about as Waterfall as can be.
Employers need to understand different people work differently. Want a truly efficient knowledge worker staff? Do try to cookie-cutter their environment. Give people the environment they need to succeed, which for some may be open collaboration and others quiet reserve. When the brain is really the only limiter on productivity, optimize for that.
Open source projects find an fix bugs quickly, if there's enough developers, because people are different, work different and think different. I would argue that individuality saves time, money and work.
That being said, businesses could just cookie-cut smaller offices and more people would get more work done.
The thing is, the cost isn't what really matters, the cost/benefit ratio is. You want to put your people in an environment that optimises the productivity of your organisation as whole, by getting the balance right between supporting both individual performance and effective collaboration. If detailed customisation of the environment for every single member of your staff to hit that balance will increase your costs by 100%, but doing so increases productivity of your overall organisation by 200%, then it's a very beneficial action.
Hey, if filtering on something like open floorplan workspaces also filters out employers with that attitude, that's awesome in my book. The sooner I can know they want cookie-cutter work, the farther away from them I can get.
Being an introvert isn't the same as needing to work alone.
Introverts gain energy from focusing on the "internal world" of thoughts and ideas. Extroverts gain energy from focusing on the "external world" of socializing and interactions.
So, as an introvert, I can do just fine as a public speaker, consultant, and yes, pair programmer and Agile team member, because those activities are focused on thoughts and ideas. (I don't do so well at parties or conference ice-breakers, and that's fine.)
The other error I see in the InfoQ essay is that it conflates "Agile" with "decision by committee." It's true that Agile teams work in, well, teams, but that's not the same as everybody being involved in every decision. Team members on a high-functioning team know who on the team is best at what, and they automatically delegate everyday decisions to the people most qualified to make those decisions.
It does take a while for a team to reach this level of capability, and the early stages of team growth can be uncomfortable and difficult, often with too many meetings, but that doesn't mean that "Agile" == "decision by committee." It just means that smooth-running work takes time and practice. No surprise there.
Semi-related: I'm starting to be a bit ticked of about the whole introvert/extrovert. Some forums, HN, include seems to be celebrating the whole introvert thing, like it's somehow "better". Much in the same way as some thinks that NoSQL is just better than RDBMS, regardless of the application. People are just different, but we're still struggling to deal with it, businesses even more so.
I have no idea if I'm an introvert or not, nor do I care to know, I'm just me.
I'm sure that there are some people who want the pendulum to swing their way. That can serve a purpose of raising awareness, but should never come at the expense of stifling extroverts.
See Alistair Cockburn's "Convection Currents of Information" for the theory (in his book "Agile Software Development") or my own "Sit Together" for the how-to (in my book "Art of Agile Development" and online at http://jamesshore.com/Agile-Book/sit_together.html ).
Personally, I think cubicles are just about as bad as open-plan offices. I want an office and a door I can close to keep people out when I need quiet.
Prior to this reorganizations however, it was miserable. My cube was between a sales guy and a customer support manager who would take support calls on speaker phone, in his cube, with members of his team all crammed in.
I'd love that.
I've worked in places with 30+ programmers - what building exists that a company could afford to have 30 private offices??
Things are relatively cheap when you don't try to locate them right in the middle of an overcrowded city.
Now that I think about it, everywhere I've worked there was enough space so that everybody working there at the time could have had an office.
As to where I'm going to find them: I'm probably going to filter out employers that can't make enough money with programmers to afford an office for each of them. I know this removes a non-trivial number of employers from my potential field of employment options.
http://www.executiveinteriors.com/fit.php is just one company.
I think it's possible to simulate that, even if you aren't naturally oblivious so your surroundings, by putting on a comfy pair of over-the-ear noise cancelling headphones and listening to some ambient music. In addition to providing insulation from audible distractions, it's also a good cue to your co-workers that if they try to attract your attention, they will be interrupting you. If you are distracted easily in your peripheral vision by people walking by, then this won't help you much, but otherwise it's a pretty good approximation of being alone.
My point is that as a programmer there are things you can do even in an open-air environment to provide creative isolation, without losing the benefits of having easy access to the people around you when you want to talk.
Cubes never did work well for me because they rarely get any natural light. I'm a sun driven person and try my best to insist on a window in my office.
No! Offices with doors! http://www.joelonsoftware.com/items/2008/12/29.html
I'm not a fan of open plan, but I can deal with it. It works fine when people have the sense to take meetings into, you know, the meeting rooms.
[1] http://thinkrelevance.com/blog/2012/03/28/thinkrelevance-the...
[2] http://blog.fogus.me/2012/03/29/fogus-on-think-relevance-pod...
But of course, in practice, buzzwords tend to get abused by extraverts to describe whatever they want.
As others have pointed out, no agile process that I am aware of recommends open plan offices. Open plan offices suck. What many in the agile community do recommend is having team rooms - where everybody working on a particular sits together.
In fact the only agile process I'm aware of that makes any explicit statement on working environment is XP - which has having per-project team rooms as one of it's practices (the primary practice of "Sit together" In XP2E)
And there's a lot of actual evidence that the team-room way of working is very, very effective. See this quora answer of mine for some references http://www.quora.com/Is-having-all-the-startup-engineers-wor..., and the agile alliance guide has some references too http://guide.agilealliance.org/guide/teamroom.html. Especially the "Offices That Work" paper that has some nice info on the relative trade-offs.
I find it curious that so many folk focus on individual performance - when most development is a team sport. I don't care if I'm a little less productive as an individual by a few project-related interruptions if the overall productivity of the team I'm working on improves.
a) Open office plans -- for a lot of reasons I'd agree that these suck, but
b) Brainstorming -- Recent studies suggesting that it's ineffective are intruiging, but I wonder to what extent group cohesion matters? Cohesive groups where we're less worried about looking bad might be more effective.
c) Pair programming -- even though I'd definitely consider myself an introvert, pair programming doesn't rise to the level of social invasiveness that I would find problematic. In other words, most introverts dislike being around large groups, strangers, trying to chit-chat/schmooze, etc... but are often find around smaller groups of people they know and get along with. So I'd be hesitant to group pair programming with the others. OTOH, I've never had to do it all day long, so I'm not sure how that feels. Can anyone speak to that?
My biggest problem with Agile is that it touts itself as THE way you should work. When you're constantly working with all different kinds of minds, it's hard to say conclusively that ONE SYSTEM will work for EVERYONE.
I will say that as a pseudo-introvert (can function in large groups but prefers small, intimate conversations most of the time), I do enjoy pair programming because I learn so much. It's best to pair an unexperienced but knowledgable dev up with a veteran to either the current project or the current problem. The combination of naive creativity with tried-and-true procedure is the best of both worlds, and truly impossible with a single person, in my opinion.
The passing reference in the OP didn't really put the original "Brainstorming Doesn't Really Work" article (http://www.newyorker.com/reporting/2012/01/30/120130fa_fact_...) in context. Brainstorming, as in the "let's put all the ideas out there without critiquing/debating them", was disproved in the late 50s.
In the article, a study found that adding the debating or critiquing back to the process improved creativity. You would also think that introverts would feel even more stifled in such a situation, wouldn't you?
With respect to brainstorming I had session that worked fantastically and others that don't, and in my opinion in session that don't work there is someone that has power over the majority of the group and is simply dictating what happens in the brainstorming session.
In our startup, we deal with this tradeoff with two spatial configurations. We spend part of our time together in an open space where interruptions are common and expected. We spend the rest of our time miles apart, occasionally coordinating over email and IM whenever needed.
Perhaps one way to achieve this in larger teams is to block off large chunks of the week during which it is understood no one interrupts anyone else. Weekends already play this role for many people I know. They often work for a good chunk of the weekend, but are not expected to take calls or return emails. It's when they do some of their deepest thinking and best writing.
I really like the idea of two spatial configurations. Personally, I work remote for a small company that is mostly local - I visit the office a couple times a year and love the personal time for face-to-face discussion, etc. If I could have that a couple times a week, or a hour a day, I would love it.
I'm available throughout the week, if you can't provide and environment for me where I can be productive because of for example an open floor plan then I am not going to spend my time for you.
I have been very fortunate though in that I have a very understanding boss that lets me work whatever hours I please (I generally get to the office by around 1000/1030 and leave at around 1800/1900) and that has helped my productivity quite a bit as well because I am sleeping on my own sleep schedule that works for me, and at the tail end of the day when I am most productive the office is empty and quiet and I can get my work done.
Perhaps Agile with a capital A does hold something in common with the formal technique of brainstorming. The key point of the Lehrer piece is that in order for group creativity to flourish you need to foster debate and disagreement, not just uncritical free association in a conference room. And even then, it's good not to put too much formal process in place, because the best interactions are unscripted. But this in turn solidifies the need for work spaces that maximize the chance for these encounters.
If an individual needs private time, I think a generous work-from-home policy can do wonders. Give a person 2 days of the week to work from home and let the team self manage time in/out of the office. Letting the team work out scheduling helps them maximize productivity with both group-think and individual contributions.
Agile is also dev practices: refactoring, TDD, unit testing, continuous build, etc. Agile = faster development and accelerated deliverability. Sure, cooperation and breaking down silos is part of it but introverts can unit test. (Learn more: http://j.mp/Hex2Uy)
My current compromise is to enjoy the natural light on the floor and use earplugs when I really need to concentrate.
Let's create a new buzzword: POPS People over process, stupid.
Any project that gets bigger than a few thousand lines of code can't be maintained by a lone developer. It also requires some sort of socialization. Every placed I've ever worked required me to talk to other developers because my code would most likely be touching theirs to some degree or I would need to get info on something I would be working on.
Sitting around and talking about an idea is useless?
The entire point of the article is not to discount these things because they are useless, but to discount them because a small percentage of the population find them uncomfortable.
Introversion is a personality trait, with advantages and disadvantages. To say that introverts "should think about getting some kind of therapy" simply for being introverts is simply irrational prejudice.
(1) http://www.capt.org/mbti-assessment/estimated-frequencies.ht...
Funny, that's not what it said when I read it.
Those things can be useful but, since other (opposite) things can be useful and even necessary as well, practicing them to the exclusion of all else like you're suggesting is stupid and counter-productive.
My creative output happens mostly when I'm working in a solitary, focused manner. When we adopted mandatory pair programming it destroyed my productivity and my enjoyment of work to the point that I had to quit.
Lone wolves don't belong in packs.
Most work environments today are open, regardless of industry. Strong personalities and herd thinking exist outside of the tech world too.
Pointing the finger at agile might get eyeballs, but you have to keep in mind that open office plans have been popular long before Agile became a mainstream buzzword, probably because they're cheaper than putting up walls. I tend to think the Japanese management fad of the 80s probably had a little to do with it too.
And not every group practising agile is pair programming.
I am no fan of Agile, and as a former introvert, I can say that the only thing that stifled me in my introverted days was my own introversion.
I think that it is quite possible that Agile doesn't serve the best interests of introverted programmers, but I disagree that this is a bad thing for programming as a whole.
There are plenty of introverted programmers. If the dominant office/workflow structure of the day makes them less productive than they would be on their own, that creates a huge opportunity for an office/workflow structure that makes introverted programmers more productive than they would be on their own.
On the other hand, I think that some percentage of introverted programmers who don't take a shine to Agile could search forever for an office/workflow structure that they like and never find one, because their issue is mainly with collaboration and exposing their work to criticism while it is still in mid-process.
This group of malcontents can be subdivided still further into those who can make it on their own and those who really would benefit from the sort of collaboration and criticism that they resist. It is this last group that aren't merely introverted, they are also faint of heart. I spend about 40-50% of my time in this category and it's real bad. I take solace in my relative youth and inexperience, I need to know that I won't be this sort of introvert for long.
The reality is much more complex especially when it comes to people with different needs. This makes it probably more difficult for companies, but when they produce software they have to invest in finding the best "solutions".