Are You in a Claustrophobic Team?
Are You in a Claustrophobic Team?
Join the DZone community and get the full member experience.Join For Free
Something that never ceases to humor me is how managers still believe that scaling people on a project will increase the productivity by an equal proportion. We all know the old saying, “You can’t make a baby in a month by getting nine women pregnant”, but the question is why do we still practice this bad habit? Is it because we do not recognize the the law of diminishing returns when it occurs?
I have talked about Brook’s Law before and that adding people to a late project makes it later, so as not to repeat myself I want to look at this from a different perspective and instead of telling how to avoid it, ask the question why this phenomenon slows efficiency and creates a Claustrophobic Team.
Claustrophobic people show anxiety and panic when they fell they are being locked in or their personal space is encroached; however, this encroachment can happen at many different levels on an overly staffed team:
Intellectual Space Encroachment
The DBA doesn’t want anyone else to touch the database without 7 written forms of consent because that is his job and space. The project manager who wants you to call every time you need to use the restroom. The client who does not want to be told a more productive process work flow.
We have all been on a team where people like to protect their intellectual sandbox. We fence these spaces primarily out of:
- Fear of not being needed or under utilized
- Ego and the need to be important
- Self esteem and the need to be appreciated
Everyone wants to stay busy and when people stack up on each other intellectual boundaries tend to be less respected and therefore encroached. As long as the work is getting completed in any one sphere attempt to respect the roles of individuals even if they do create a slight inefficiency as the inefficiency of having them work against you is greater.
Virtual Work Space Encroachment
For the software developer, you can read – code.
I have always had the belief that collective code ownership is just as a dangerous extreme as team silos. There is always some level of expertise in particular areas of the application and thus pseudo ownership, buy anyways I digress…
To many people working in the same area of the application can create a huge amount of churn. This overhead can be as simple as extra communication or complex as continuous code merging. Two people working in the same class file is a headache, three people working in the same file is just mayhem.
Especially in environments where intellectual thought is being transcribed, people need a few degrees of freedom in which to explore and modify. Unless you are pair programming, having more than one person work at a time on the same section of an application may start to become disastrous.
Physical Space Encroachment
Whether you realize it or not physical space encroachment happens a lot in claustrophobic teams. Just because you still have your desk and the office hasn’t become “standing room only”, does not mean that you aren’t feeling the pressures of encroached personal space:
- Increased communication means more people interrupting you whether through email or a face-to-face chat
- Kanban boards (and online issue trackers alike) become overloaded, hard to navigate, and harder to interrupt visibility
- Offices can become more densely populated when consultants or other workers come in to aid.
So what is the answer to all of this? Well, I am going to be very cliche and say – it depends.
Different businesses, teams, and people all have different thresholds of team claustrophobia and need to be dealt with accordingly. However, it is the responsibility of the team lead to recognize the symptoms of an overly staffed team and realign project expectations while not moving more people.
Published at DZone with permission of Maxfield Pool , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.