6

Update: (a PM-specific concern) Having developers working close together is valuable to my team - people tend to naturally ask more questions, get involved in code-related conversations they overhear, do more pair programming sessions etc. With the new setup, we will lose some of these benefits. Should I find ways to formalize these practices now - weekly knowledge sharing sessions, designated Scrum areas etc? How do you recapture the lost intangibles of changing a productive working arrangement for developers?

Original question:

My boss recently became head of both the BA and Developer teams, and wants to reorganize the office space and relocate everyone's cubicles so that the teams are more interspersed.

As the Dev manager, I see this as a bad idea because:

  • It's a threat to productivity as you can't ask peers a quick question without walking down the hall
  • It's a hit to morale as both teams lose their individual cultures and the sense of camaraderie that comes with sitting close to people you work with

What is the right thing to do here? I appreciate the boss' vision of a closer-knit team but am not sure if he's on the right track.

Improve this question
3
  • 2
    Vee Bee, welcome to PM.SE! Think your question would fare better at Workplace SE since it raises questions beyond Project Management. Alternatively, you could edit the question to pull it closer to the scope of Project Management... – Deer Hunter Jan 25 '13 at 17:44
  • @DeerHunter Thanks for the tip - didn't know about the existence of Workplace SE! – Vishal Bardoloi Jan 25 '13 at 22:20
  • Hi @VeeBee. I'm guessing from your mention of 'scrum areas' that you are using Scrum as your primary methodology. Is this the case across the whole org? If so, 'mixed' teams might well make sense. – Willl Jan 28 '13 at 13:47
9

The downsides that you mention could just as easily be applied to project teams if you continue to have different groups siloed.

  • It's a threat to productivity and to project success as you can't ask peers from other functional units that you have to interact with a quick question without walking down the hall
  • It's a hit to project team morale as both teams retain their individual cultures, promoting an us vs them attitude within the project team, in particular when problems arise and is also a hit to the sense of camaraderie that comes with sitting close to people you work with

One key parameter would be to ask "What level of cross-functional communication do our teams need to be successful and are we achieving that in the current system?" I infer from your question that your boss' answer is NO you are not getting the level of cross-functional communication that you need, and is trying to address this by breaking down the silos the functional units have created. And a great way to do this is to co-locate your project teams.

My personal experience is that co-locating members of different functional groups together when they are working on the same project makes those projects easier to manage and more likely to deliver on time/quality/budget by about an order of magnitude.

Improve this answer
2
  • +1 generally and on the co-location of different functional groups particularly. I'm working on a project where we lack this at the moment and it regularly leads to miscommunication and misunderstanding. – Willl Jan 28 '13 at 13:50
  • I'd have to say that, while initially the idea might sound scary, it actually can work out to be quite effective, and there's a level of camaraderie that can be formed even among people who have differing skill sets. It also helps suppress the us-vs-them mentality that can sometimes form in functional units. – jmort253 Jan 29 '13 at 5:53
3

Purpose of "Sitting Together" as a Practice

The purpose of sitting together is an agile practice that's predicated on the idea that colocation increases communication bandwidth within the team. There is widespread acceptance of this premise, but there are also thoughtful objections to the practice, including the observation that open-plan seating and colocation can increase interruptions, reduce signal-to-noise, and create additional task-switching overhead.

In other words, the practice is widely considered beneficial, but is not essential. You certainly have alternatives, should you actually need them.

Keep Your Perspective

While "down the hall" might be inconvenient for osmotic information-sharing, it is hardly a problem in the same way that coordination with geographically-dispersed teams or off-shore development models would be. Honestly, if a problem isn't big enough to warrant walking 20 or 100 feet, it probably isn't a real or urgent problem.

There are also benefits to integration within the larger organization. If your development team needs to coordinate with anyone outside the project (e.g. the business analysts), then any benefits of colocation would apply to them, too. Why wouldn't you want your developers to have easier access to DBAs, BAs, or other roles within the organization that they may need to work with to do their jobs well?

Communications Culture

Teams that don't sit together can still work well together. It's all about communication. If you have a team that's dispersed, whether it's down the hall or across the ocean, the 21st century is awash in productive communications methods.

Instant messaging, email, telephones, video chat, mailing lists, wikis, and screen sharing are just some of the ways that teams can work together without sitting together. Each mechanism has its own pros and cons, and teams must find the work-flows and formulae that work best for them.

Encourage your team to build whatever communication channels and teaming practices they need. You'd be surprised at how well teams can do when the organizational culture encourages innovative communications.

Improve this answer
2

What is the right thing to do here?

ask your employees.

If you really care about their productivity - ask them, which way they would be more productive. And when you ask - make sure you do listen to what they are saying (I've seen a boss "asking" like this "we are going to have such and such changes, ok?" )

Improve this answer
1

I agree with Steve and Doug in that it depends on a couple of things. The first depends on how your organization has functioned in the past and can your team(s) adjust to change easily. To go from a traditional functional team environment to a more abstract project maxtrix team environment takes a great deal of effort to come off smoothly. Much of it has to do with training and preparing the new "teams" for the eventualities of team development (forming, storming, etc.). Our office works completely in a matrix environment, where team members are on more than 6 - 10 projects each. It takes some getting used to, but if your corporate culture facilitates the ease of communication, it can be a very effective methodology.

Improve this answer
0

It seems that you are facing a less pleasant top to bottom transition. In cases like this, there is a good chance that your actions are going to fail without proper support from the top. Brining back the old habits is important, but I think you should find a way to keep them instead of bringing them back.

There must be other colleagues who are worried as yourself. Have an informal chat with them and see who could you talk to your new boss about the current situation, and convince him to stop with his current plan. In order to do it, you'll need help, support and alternatives. This must be a team work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.