First, here’s the short version for those poor souls suffering from tl;dr (too lazy, don’t read much) syndrome, that peculiar malaise that characterizes our times:
Can working from home be effective
compared with collocated teams?
Opponents are quick with invective
and full of opinions, it seems.
But what if we increased, in some way,
the ratio of signal to noise?
Could we discover a good way to
routinely deliver with poise?
And now to business.
One of the ongoing debates in the IT world over the past few years has been about the relative merits of team collocation, including intense collaboration, paired work, and continuous osmotic communication, versus solo work, including work from home and other forms of remote work as well as office spaces fitted with individual cubicles.
In my own experience, both forms of work have been effective for delivering product and both have provided significant personal and professional satisfaction. On the other hand, I have seen both forms of work result in frustration, stress, anger, waste, and poor outcomes.
If both forms of work have been proven effective, and at the same time both forms of work have been proven problematic, then it seems logical to conclude neither approach guarantees positive outcomes. There must be factors that enable one approach or the other to be effective under certain conditions.
Rather than asking whether team collocation is universally superior to solo work or vice versa, we might do well to ask which conditions call for one or the other approach. If we can understand that, we stand a chance of organizing teams in ways that maximize the strengths of each approach in context.
Why collocated teams?
People who have not worked in this way before have many strong opinions about team collocation. Rather than address every point they raise, I will suggest that a person who has not done something before may not be the best source of information about the thing they have not done before.
You will also meet people who have worked in collocated teams and achieved poor results. As I mentioned earlier, collocation alone does not guarantee positive outcomes. Be aware that some people who have experienced negative outcomes just blame the “process” without investigating root causes.
You can make your own choices about where to find relevant information, and ultimately you will have to make your own professional judgments. I simply suggest that you find out a bit about where a person’s opinions came from before accepting them on faith.
Human nature. Team collocation takes advantage of the natural tendency for humans to function in small groups known as bands (see Morton Fried, The Notion of Tribe). A band is smaller than a tribe and comprises one or a few families. A band has no formal leadership or permanent institutions, and few standard ceremonies. Members operate as peers, and the function of leadership shifts among members according to need.
This is the most natural way for humans to function, and has been the key to species survival for millions of years. Even within larger, formal organizations, most everything that gets done is done by informal groups of individuals who trust one another. Such groups normally cross formal administrative boundaries and official levels of authority without much regard for the defined organizational structure. They work around rules and procedures to get things done. They are the reason dysfunctional organizations do not fail immediately, massively, theatrically, and in large numbers.
A collocated team is a formally-organized work group that explicitly takes advantage of this aspect of human nature. In the business world this sort of structure is sometimes called a self-organizing team. Self-organizing teams have many characteristics in common with pre-agricultural human bands. Strangely, this simple concept seems to be poorly understood in management circles.
Human nature goes back at least 2 million years (depending on which anthropologist you ask), while larger and more formalized human organizations came about as a result of the Agricultural Revolution, some 6,000 to 9,000 years ago (depending on which historian you ask). Characteristics of human groups that result from evolution are deeper and more natural than those that result from formal organizations such as tribes, kingdoms, and nation-states (not to mention corporations), simply because these characteristics have defined the sort of creatures we are for more than 99.9% of the time we have existed. Artificial forms of organization have not existed long enough to change our nature at a biological level. It only seems sensible to pay attention to our natural characteristics and make use of them in our work.
The collocated team structure taps into human nature while artificial forms of organization tend to rub against the grain of human nature: Any group larger or more formalized than a band is, in this narrow sense, unnatural. I don’t mean to imply “unnatural” necessarily means “bad.” I only mean to point out that anything “unnatural” will require special effort to sustain. When we organize our work in a way that aligns with our nature, it will be sustainable without special effort because it will be consistent with the way things “want” to happen.
All necessary skills on board. Collocated teams are generally based on the idea of cross-functional teams. A cross-functional team includes members who have, among them, all the skills necessary to achieve their common goals. This is in contrast to a matrix team model in which workers are organized around skill sets, and work groups provide services to one another when a particular skill set is needed. (See the post “Pros and cons of dedicated teams” on this blog for more about the matrix team model.)
Having all necessary skills in the team work area eliminates communication delay and wait states when the team requires the services of someone who has a particular skill. It also enables each team member to have a clear view of the “big picture.” In contrast, with the matrix team model, few (if any) individuals understand the context of the initiatives in flight. From their individual perspective, day-to-day work appears to comprise an endless series of disconnected, context-free, one-off tasks, requested by people they do not know and never see, and whose priorities are not shared, in support of unknown goals about which they will never receive any feedback. This tends to lead to a problem that has been dubbed the “eighth waste” of Lean Thinking: Squandered human potential. (Of course, it doesn’t help very much with the other seven wastes, either.)
Osmotic communication. As far as I know, the term osmotic communication was coined by Alistair Cockburn, who describes it on his website and in his book on the Crystal Clear methodology. He describes it better than I: “Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work. […] When osmotic communication is in place, questions and answers flow naturally and with surprisingly little disturbance among the team.”
People who have not worked in this way before often expect a team work space to be noisy and distracting. I have not found this to be the case. Alistair mentions people “tune in or tune out.” I have found this to be quite natural and easy. A well-functioning team room has a “buzz” that one can recognize, in much the same way as a mechanic can judge the health of a car by the sound of its engine. When you are in the flow of work, the buzz of the team room is not distracting. You tend to pick up comments that interest you and ignore everything else without any special effort or practice. It feels very natural.
The practical advantage is that we can eliminate nearly all wait states when we need information. In addition, when a team member becomes stuck on a problem, others in the room can offer assistance with no delay and in a very seamless manner. This also results in a reduction in wasted time, as team members need not spin their wheels trying to overcome minor obstacles when all they need is a “fresh pair of eyes” for a moment.
Personal commitment. Taking advantage of another aspect of human nature, collocated team members tend to develop a sense of belonging and come to care deeply about how their team mates regard them. This cannot occur in a cubicle farm because in that environment interactions among team members are indirect and impersonal.
This natural sense of belonging translates, on a practical level, into personal commitment to the team’s goals. Team members develop a sense of responsibility (generated from within) as opposed to accountability (imposed from without). The difference is immense, but difficult to quantify. Internally-generated responsibility results in countless small acts that are not individually called out for praise or reward to avoid problems that do not occur and so are never noticed. (Try quantifying that, and let me know how it goes.) The natural sense of responsibility leads people to do the right thing when no one is watching, even though they will never receive personal recognition for doing so. (Try commanding people to do that, and let me know how it goes.)
Delivery methods that exploit collocated teams usually include mechanisms to facilitate the creation of a sense of belonging and mutual responsibility. For example, a common mechanism is the so-called daily stand-up. The stand-up is a brief ritual in which team members state which work items they completed since the last stand-up, which work items they intend to complete next, and whether they have any impediments for which they need help. It is not a status report. Team members have other ways to check on the status of the work, should they wish to do so.
The stand-up is a ritual that requires team members to stand, so that they are visually disconnected from their work for a few minutes, and make eye contact and speak directly to their colleagues rather than inputting their status into an electronic tool (indirect and impersonal). This creates a natural sense of commitment among team members; commitment to each other as human beings, rather than to an abstraction such as “the project” or “the customer.” Powerful stuff, indeed.
When you work separately, a problem with some aspect of the work not directly assigned to you is simply an SEP (Someone Else’s Problem). It does not produce an emotional response in you at all. It has no effect on your work, your reputation, your compensation, your annual performance review, or your day. You cannot be blamed or punished, as the issue is not your assignment. By the same token, there is no mechanism in place to acknowledge or reward any assistance you might render. You are not accountable for delivery of a solution; you are only assigned to carry out an endless series of disconnected, context-free, one-off tasks. You have no reason to care.
Why not collocated teams?
Okay, if team collocation offers so many obvious advantages then why doesn’t it always result in positive outcomes? One answer is that collaborative work just isn’t everyone’s cup of tea. Some people thrive in a collaborative work environment and others have difficulty maintaining focus or feel uncomfortable spending so much time in a shared space with several or many other people.
I’ve heard people say that radical collocation, intense collaboration, and paired work favor extroverts. My own experience differs from that. I’m an introvert myself, and I know some of the best-known proponents and practitioners of pair programming are introverts, including some whose names might surprise you if you have seen their “stage personas” in action at conferences and user group meetings. We, and countless others, enjoy and benefit from pair programming and other forms of intense collaboration. If introversion were a stumbling block, how could this be so?
I think it is because of the nature of the interaction with others. Collaborative work is very unlike general social interaction. I feel uncomfortable having to strike up a random conversation with a stranger in a social setting. I have no problem at all diving into a pair programming session with a stranger. We have a common goal and well-defined boundaries for interaction. I know from the start that the topic of our conversation will never include personal issues, so those little fears we introverts have about that just don’t materialize.
That sort of thing presents no problems for introverts. When people dislike close collaboration, the reason must be something other than introversion or extroversion.
I don’t know the scientific explanation. I might surmise it has to do with personal preferences, personality types, or cognitive styles. Some people do well when they bounce ideas off a partner. Others do well when they can sit down in a quiet place and think through a problem on their own. Some people like both forms of work, depending on just what they are trying to accomplish at the moment.
I would observe, too, that some activities tend to flow better with close collaboration while others are a less natural fit for that style of work. Paired work originated with pair programming, which means two programmers develop the same piece of software together. Programming is an activity that benefits greatly from paired work. That doesn’t mean all activities benefit from it, though.
In the context of software development, activities like short-term planning and estimation, creating executable specifications, writing application code, and performing manual testing of user interface behavior usually flow better and produce superior outcomes when done collaboratively, sometimes with whole team participation and sometimes working in pairs. On the other hand, activities like user experience design, physical database design, producing graphics, designing solution architecture, and writing user documentation usually flow better and produce superior outcomes when an individual works alone, even if others will review the work later.
For purposes of learning new skills, sometimes a collaborative approach works well and sometimes it’s best for the individual to explore the new topic independently. Generally speaking, paired work is an excellent vehicle for knowledge sharing and direct mentoring. There are cases, however, when a person learns more effectively by stumbling through a series of experiments or follows a self-directed tutorial. There are even rare cases when a formal training class is helpful, especially to get someone started with a completely unfamiliar topic. The choice must be made on a case-by-case basis.
Why remote work?
It’s a commonplace that software development is, by nature, a creative endeavor that benefits from collective effort. Yet, quite a lot of software has been developed by individuals working alone. This suggests that the nature of software development as such does not necessarily call for collaborative or individual work. It may be that the working environment created by either collaborative or individual work enables people to apply their intelligence and creativity more (or less) effectively. Different people might respond differently to each mode of work.
The particular activities involved might also tend to favor either collaborative or individual work. Generalists who are applying a range of skills to produce an application will probably do a better job working collaboratively most of the time. Specialists who provide narrow-and-deep expertise to multiple solution teams, and whose presence in the collaborative work space is only necessary on occasion, will probably do a better job working individually most of the time.
Employee engagement. In an article in Lifehacker for 5 September 2012 entitled “Why Remote Workers Are More (Yes, More) Engaged”, Scott Edinger pondered the reasons why a 360-degree feedback process at an investment firm revealed people who worked from home were more engaged and committed than their colleagues who worked in the office. It’s a worthwhile read. In a nutshell, Scott suggests the following causes:
- Proximity breeds complacency
- Absence makes people try harder to connect
- Leaders of virtual teams make better use of tools
- Leaders of far-flung teams maximize the time spent together
The investors were performing very different work from software development teams. It’s easy to see that they would not benefit from sitting in the same room together. But there still may be lessons for us in this report. It does seem logical to think that people who work remotely will pay close attention to the effective use of communication tools and will try to get the most from each interaction they have with colleagues. They know they will not run into a colleague in the break room by chance. They have to think about and actively plan their interactions with colleagues. To me, this suggests that individuals who have certain personality traits can maximize their contribution when they work alone in a work space crafted to suit their individual needs and preferences. Others might do better when they are surrounded by colleagues in a vibrant, collaborative environment.
Flexible time management. People who thrive working alone and remotely tend to be very good at managing their own time. If they were in the office, their work day would be structured by someone else, and possibly in a way that did not align very well with their individual working style. This is especially true when the office environment is a collaborative team work space.
These may be people who need to get up and walk around frequently, or who like to shift focus from one task to another from time to time, in a way that others might find detrimental (excessive context-switching). To an extent, they have the freedom to do this when they are in a cubicle at the office, but they have even more freedom when they are working at home. They need not even keep standard work hours, if they happen to be able to work better late at night or early in the morning.
Sustained focus. In a collaborative team work space, people generally work in pairs during specified time-boxes. When the time-box expires, work stops for some period of time. Team members check email, answer questions from stakeholders, or do other activities until the next scheduled time-box for paired work begins. Whether you feel like working at the moment a time-box starts, you have to begin. Whether you feel like stopping when the time-box ends, you have to stop.
That sort of time structure helps some people stay on task and get things done. But others find it very challenging to maintain focus on a task when working in this mode. The challenge is increased when the task is lengthy or requires a lot of analysis or creative thinking.
An advantage of working solo and remotely is that you can remain engaged with a task for as long as you wish, with no interruptions. When you need to stop, for whatever reason (fatigue, boredom, impasse), you can stop. This can be more effective than collaborative work, depending on exactly what you’re doing and how you tend to work best.
Less wasted time. There are two ways (at least) that remote work saves time. Probably the more obvious one is that there is no time lost to commuting between home and office. Many people in our line of work live in suburbs and work in the center of large metropolitan areas. Traffic going into New York City, SaƵ Paulo and other major urban centers during morning and afternoon rush hours can back up for many miles. Commuters spend 2 hours or more each way. Of course, employers do not consider commuting time to be part of the work day. Yet, some of the commuting time inevitably eats into work time. You can’t spend 12 hours of the day “at work.” There aren’t enough hours remaining for you to live your life. So sometimes those 4 hours of commuting time will “borrow” a few minutes from your employer. It’s unavoidable.
The less obvious effect is on people’s frame of mind and energy. After 2 hours sitting in a car that is barely moving, will you be at your best when you finally arrive at the office? It seems likely you will be, in a word, “frazzled.” You will feel tired and irritatable. In effect, you are losing at least 30 minutes to an hour of “productive” time each morning. There is an effect in the afternoon as well, as you will devote some portion of your mind to planning your escape route from the city, and you will lose some emotional energy as you anticipate the hassle of sitting in traffic for another 2 hours.
Business risk mitigation. Seattle, Naples, and Mexico City lie near active volcanoes. Miami, Boston, Houston and others are at risk from hurricanes. Tokyo, Sydney, San Francisco and others are built on fault lines. Tornado Alley spans Dallas, Oklahoma City, Kansas City and others. All coastal cities are susceptible to tsunamis. Shanghai, Calcutta, and Marseille are especially vulnerable to flooding. Transportation strikes are common in Paris and are such a normal part of life in Italy that they are scheduled in advance and publicized online. London, New York City, and Washington DC are high-profile targets for terrorism.
Capetown, Caracas, Chicago and others suffer from high levels of violent street crime. Lagos, Bengaluru, and others have unreliable electrical power. Any city that has a nuclear power generation facility nearby, is built below a large dam, or is protected from a river or the sea by levees or sea gates is at risk from accidents. Aging or overstressed infrastructure is susceptible to accidents; for example, New York City has 4,300 miles of gas lines, of which 637 miles are cast iron pipes more than 100 years old. I don’t have to be a certified engineer to see the risk in that. The truth is that most large cities are at risk from more than one of these potential problems. The question is not if, but when.
You tell me whether it’s a good idea to cram 20,000 of your 25,000 employees into a couple of downtown high-rises.
If you think this is excessive, I can only say I would have agreed with you a few years ago. These scenarios only seem excessive until one of them occurs. Every one of them has occurred.
But business risk is not limited to extreme scenarios. Every time an employee leaves home and walks, cycles, drives, or rides a bus or train to work there is a non-zero probability that something bad will happen. People die every day in traffic accidents, train wrecks, and street crimes. If employees can work at a satellite facility, then their travel distance is reduced as is their need to travel through dangerous sections of the city, and business risk is reduced proportionally. If they can work from home, business risk due to commuting incidents is all but eliminated.
Before you protest that it’s impractical to have 25,000 people working from home, consider the type of employee who will thrive doing remote work. Look at the Lifehacker piece cited above. Not every employee will be able to handle working from home. It will be the more-senior and more-capable people who can do so. For purposes of business continuation in the event of a disaster, those are the very people you will want to be up and running. They are the ones who understand how everything really works, and they are self-directing by nature. We’re talking about a few hundred out of 25,000, and that is certainly feasible.
Why not remote work?
The answer to “why not remote” is, for all practical purposes, the list of advantages of collocated teams. The advantages of each mode of work tend to offset one another. Working separately and remotely, there will be more misunderstandings. More misunderstandings will lead to more defects. More defects mean more re-work. There will be delays when people who are not collocated need to ask and answer questions of one another.
In discussions in meatspace and cyberspace with people who enjoy working from home, I consistently hear arguments to the effect that any benefit of collocation can be achieved in a remote work situation by using appropriate technology. I understand that people don’t want to believe they are choosing a second-best way of working, but in my experience any remote set-up can, at best, approximate the benefits of working face-to-face with others. The good news for home workers is that maximizing the mechanical efficiency of the work is not the highest priority goal; maximizing worker satisfaction and happiness is a higher priority, as those workers will produce good results using whatever methods they please.
If we intentionally trade away a little bit of mechanical efficiency in order to assure high worker satisfaction, it will be a favorable trade. Don’t be embarrassed to admit that you work from home because you prefer it and not because you think you can make people believe it’s “just as effective” as collocation. Your preferences matter.
The question is whether the cost of all those disadvantages is balanced by the benefits of remote work. The answer to that question is not so simple. It depends on the nature of the work and the nature of the people doing it. It depends on the quality of the communication facilities the company establishes to enable people to collaborate remotely. It depends on how expectations are set during the transitional times when the company introduces a different mode of work.
When things haven’t worked smoothly
In my experience, things haven’t worked smoothly when people assumed one mode of work or another was The Single Best Way. When the dominant cultural assumption in the organization was that collocated teams were The Single Best Way, then those who had been working from home before were treated as if there was something wrong with working from home, and something wrong with even wanting to work from home. When the dominant cultural assumption in the organization was that individual work (whether remote or in the office) was The Single Best Way, then those who wanted to experiment with team collocation were treated as if there was something wrong with team collocation, and something wrong with even showing interest in it.
Sometimes the problems pertained to execution, and not to assumptions or expectations. I’ve seen cases when companies tried to set up team work spaces, and did it so badly that they destroyed employee morale. According to DeMarco and Lister in Peopleware, a team work space requires private, semi-private, and collaboration areas. When companies set up a work space that has only the collaboration area, and also eliminate the employees’ former private cubicles, they break the model. They also break the team.
I’ve seen execution problems with setting up remote work facilities. Management may authorize telecommuting only with great reluctance, and only on a limited part-time basis. Whether by chance or by plan, they fail to provide the necessary communication facilities and remote collaboration tools to make it feasible for people to work remotely. They may even forbid frequent telecommuting or treat remote workers with suspicion because they are out of sight. For work-from-home to work well, working from home has to be the norm and not the exception for those workers who do it.
Seeking the best of both worlds
If we can determine what the critical success factors are for both collocated teams and remote workers, we can structure teams in a way that exploits the advantages of both. I see no reason why a team can’t comprise collocated groups, possibly more than one in multiple locales, as well as individuals who work remotely. I don’t claim to know exactly how to do this, but I can suggest a few success factors that seem appropriate:
- Sufficient trust in professional staff to allow the collocated teams to self-organize and the remote workers to self-direct.
- Opportunities for individuals to change their minds about which mode of work they prefer without any negative consequences.
- Performance assessment and rewards that do not stigmatize any set of workers based on whether they are members of collocated teams or they prefer to work from home.
- Adequate communication technologies and support so that workers in each location can interact and collaborate at will without technical problems.
- Requirements decomposition and release planning designed to minimize dependencies between groups and individuals working separately from one another.
- Integration, deployment, and release procedures that deal with the logistics of merging the products of different work streams.
- Properly-organized work spaces for the collocated teams.
- Facilities at remote worker locations (satellite offices or their homes) that make it just as easy to access the corporate network and to communciate with colleagues as if they were in the office.
- Clear guidelines about when remote workers must appear in the office in person, and for what reasons.
- Clear guidelines about times of day when remote workers must be accessible to their colleagues.
- Training and coaching to help staff members make the most of the two working arrangements.
I hope to receive feedback about these ideas.
Dave,
This is a very thoughtful treatment of a very difficult topic for some teams. I’ve always been on the fence about the “single best way” answer to the collocation/distributed question. I like the approach you take of highlighting the distinction between preferences and costs/benefits. I also REALLY like the list of recommendations at the end. Those are awesome! It reminds me of that principle in the manifesto, “Build projects around motivated individuals. Give them the environment and support that they need, and trust them to get the job done.”
Thanks for helping to clarify some of my thinking about this topic.
Tom,
Thanks for your comment. I’m glad you found some of the ideas relevant.
Cheers,
Dave
Really great post! Thanks for taking the time to share your thought and experience on this.
I personally have lived a some of dissonant situations you cite at the end of your article and confirm their painfulness: When everybody in the team is colocated, working remotely makes you subordinate, which has a deep impact on responsibility and engagement.
And I recently had a long chat with a friend of mine who leads an open-source project and works with people all across the planet, and with some experience myself of such mode of development, I am starting to think that agile’s emphasis on colocation may not be the ultimate truth. I sometimes found I was more engaged and felt more proximity chatting with a guy in San Francisco about a common task we were undertaking than with 99% of the people I come across everyday at work. Belonging is somewhat impervious to distance.
As a last word, I would take with a grain of salt such concept as “natural human behavior”. Naturalization is a common technique to prevent even the mere idea of change or criticism.
Regards,
Arnaud,
Thanks for the feedback. I can relate to your story about remote work with the guy in San Francisco. In the late 90s I was on a project to develop an app, and the client company did not want anyone in their offices. They wanted everyone to work from home. They set things up so that this approach could work well. I was in Dallas at the time, and mainly partnered with a team member in Salt Lake City. We had other team mates in 6 US states, Canada, and China. Interaction with Chinese colleagues via text-based instant messaging worked very well. Their written English was impeccable – better than most native speakers. At the end, we were all brought to New York for a celebration. When I met our Chinese colleagues I discovered their spoken English was unintelligible. Had we worked in a team room together, every day would have consisted of hours of “What?” “Huh?” “Eh?” “Say again?” Surely this would have offset some of the value of collocation. It might even have proven too frustrating to be sustainable throughout the project.
On the other hand, the most effective and most enjoyable projects I’ve worked on have been “agile” projects with a cross-functional team working in a collocated team room environment. The best of the best projects were those undertaken by a mobile team that went where the end users were located to carry out their projects. We did not work in a team room located in an IT office. We had an administrative manager who took care of HR issues, but no functional manager at all. I have never seen, heard of, or read about another arrangement that worked as well as that.
The emphasis on collocation may not be, as you say, “ultimate truth,” but don’t underestimate its value. In my experience collocation is the single most powerful aspect of “agile” methods. Even if a team doesn’t do any other practices very well, if they are collocated they will do better than if they aren’t. The reason I don’t evangelize collocation is it isn’t the Most Important Thing. When collocation is feasible then by all means do it. But context matters.
As I mentioned in the post, maximizing mechanical process efficiency is not necessarily the top priority. In an organization of humans, human factors must take precedence over mechanical factors (IMO). I’ve observed that development teams are rarely (if ever) the “weakest link” in the delivery chain. That means the teams are not the most critical piece of the puzzle to improve. That in turn means we have some leeway or margin to play with. It’s okay if the team doesn’t do everything in the most efficient way possible. As long as they are not the weakest link, choosing some second-best methods such as working from home will not harm the organization. If it maintains high morale and keeps valuable people on board for the long haul, it’s well worth it.
Regarding “nature,” I agree that we should take this with a grain of salt. But don’t discount the idea of “nature” altogether. Everything in the universe has a nature. Our own nature is difficult for us to understand because we can’t have an objective perspective about it. That doesn’t mean it isn’t worth trying.
Cheers,
Dave
My most recent experience doing development work remotely is a few years back. I was on a team where everybody was working from home. It worked well but things broke down once some members of the team got together in a physical location or people stopped sharing information proactively.
Any team is held together by a common goal, shared values and a we are in this together feeling. Once factions emerge it goes downhill. In the case of remote work chances to fix this are slimmer than when colocated with the ability to having a face-to-face conversation.
Stephen,
Thanks for sharing that experience. It goes to show that no model or framework or process will automatically produce good outcomes. Outcomes depend on exactly what the people do as they work together each day.
Cheers,
Dave
I don’t know if anyone bothers to go back and read comments on old blog posts, even if the post is just a day or two old, but it occurred to me after the fact that some of what I wrote is contradictory. In the post, I mention that a “proper” team space includes private and semi-private areas as well as a collaboration area. Later, in a reply to Arnaud, I mentioned that the best team I ever belonged to had no home base at all; it was a mobile team. We set up shop wherever our customers were. Sometimes we took over a conference room, sometimes a clump of cubicles. Sometimes we just pushed some desks together. Once we parked ourselves in a corridor. We used whatever space was available. We had no private spaces, and yet the team didn’t “break.” So, what’s the context?
This occurred before “agile” crossed the chasm. At the time, every agile team was an experimental team. I recall a value or principle (not stated in the Manifesto) that was widely cited at the time, but that I haven’t heard anyone mention in the past few years: Self-selection. We were volunteers. We knew what we were getting into, and we were okay with not having a cubicle or office anywhere. Our offices were our laptops.
Today, things are different. “Agile” is mainstream. I doubt we will ever see anything close to 100% of team members accepting a work environment where they have no place to call their own, however small.
Dave