Open Plan Alternatives: Ask Your People

I’ve heard from several people who have the power to make decisions about office space, but feel frustrated that they can’t find practical suggestions on what to do instead of an open plan.

Well, if you’re already open to the idea that open plan offices are not a panacea, but you don’t know what to do instead, here’s a surprisingly straight-forward suggestion: ask the people who work there.

If there’s one thing I’ve learned throughout my writings on office design, it’s that people who work in offices have strong opinions about how they’re designed. The only thing that holds them back from expressing their opinions is a sense of learned helplessness that comes from years and years of working in crappy offices and seeing that no one cares about improving the situation.

This point was buried in another post I wrote regarding open plans, but here it is again: No size fits all. I’m sorry, but you’re going to have to consider the people who work for you as individuals with different wants and needs, because, well, they are.

I’ll end on a quote from Peopleware, as I often do…

A common element that runs through all the patterns (both ours and Alexander’s) is reliance upon non-replicable formulas. No two people have to have exactly the same work space. … The texture and shape and organization of space are fascinating issues to the people who occupy that space. The space needs to be isomorphic to the work that goes on there. And people at all levels need to leave their mark on the workplace.

Backlog Prioritization Affects Developer Morale

If you read Scrum literature, you may get the idea that the Product Owner is a kind of dictator of the product backlog, in that he or she unilaterally decides the priority of work remaining on a product and passes this order down to the development team.

Author of All About Agile, Kelly Waters, has this to say:

Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive.

But… very importantly – only the Product Owner can prioritize the Product Backlog.

As I mentioned in my last post, there is a ton of writing out there about Scrum and Agile methodologies, and it is definitely possible for someone to come to Scrum with preconceived ideas about how software should be made, and then find justifications in the writing.

I want to make the point here about the importance of development team input into backlog priority.

In particular it’s very easy for a Product Owner to dismiss technical debt or other concerns that typically only the developers grumble about as less “sexy” than delivering another feature to end users.

When the decision comes down to fitting one more new feature into a sprint or paying off some debt on code quality, the decision usually goes to the former. But as the authors of Peopleware discuss, managers need to keep in mind the importance of quality to makers, above and beyond just immediate market concerns:

We all tend to tie our self-esteem strongly to the quality of the product we produce—not the quantity of product, but the quality. (For some reason, there is little satisfaction in turning out huge amounts of mediocre stuff, although that may be just what’s required for a given situation.) Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

The hard-nosed, real-world manager part of you has an answer to all this: “Some of my folks would tinker forever with a task, all in the name of ‘Quality.’ But the market doesn’t give a damn about that much quality—it’s screaming for the product to be delivered yesterday and will accept it even in a quick-and-dirty state.” In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.

Scrum expert, Mike Cohn, also discusses times when developers should be given leeway to decide their own priorities, including when they just need a break from the same old same old:

On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.

Product owners, please remember to incorporate the feedback of your development team into prioritization, as it has real effects on their morale. And unhappy developers will tend to leave your project for greener pastures.

Select Quotes from Peopleware, Part 4

In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group.  She was a walking example of much of what I now think of as enlightened management.  One snowy day, I dragged myself out of a sickbed to pull together our shaky system for a user demo.  Sharon came in and found me propped up at the console.  She disappeared and came back a few minutes later with a container of soup.  After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do.  She gave me her patented grin and said, "Tom, this is management."

Sharon knew what all good instinctive managers know: The manager's function is not to make people work, but to make it possible for people to work.

Peopleware, pg. 34, This Is Management

Select Quotes from Peopleware, Part 3

Projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all.  Of course, none of this proves that Parkinson's Law doesn't apply to development workers.  But doesn't it make you wonder?

The decision to apply schedule pressure to a project needs to be made in much the same way you decide whether or not to punish your child: If your timing is impeccable so the justification is easily apparent, then it can help.  If you do it all the time, it's just a sign that you've got troubles of your own.

Peopleware, pg. 29, Some Data from the University of New South Wales

Select Quotes from Peopleware, Part 2

Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence.  A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.

In the long run, market-based quality costs more.  The lesson here is,

Quality, far beyond that required by the end user, is a means to higher productivity.

If you doubt that notion, imagine the following gedanken experiment: Ask one hundred people on the street what organization or culture or nation is famous for high quality.  We predict that more than half the people today would answer, "Japan."  Now ask a different hundred people what organization or culture or nation is famous for high productivity.  Again, the majority can be expected to mention, "Japan."  The nation that is an acknowledged quality leader is also known for its high productivity.

Wait a minute.  How is it possible that higher quality coexists with higher productivity?  That flies in the face of the common wisdom that adding quality to a product means you pay more to build it.  For a clue, read the words of Tajima and Matsubara, two of the most respected commentators on the Japanese phenomenon:

The trade-off between price and quality does not exist in Japan.  Rather, the idea that high quality brings on cost reduction is widely accepted.

Peopleware, pg. 21, The Flight from Excellence

Select Quotes from Peopleware, Part 1

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.  Getting the new disk drive installed is positively trivial compared to figuring out why Horace is in a blue funk or why Susan is dissatisfied with the company after only a few months.  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."

Peopleware, pg. 5, The High-Tech Illusion