It all started 6 months ago. I was pressed by management to improve our team’s productivity. We are a team of 4 programmers with me as a leader. I identified some factors that in my opinion influenced our productivity and I reckoned working remotely could eliminate them. As a result we could increase our productivity.
I identified the following factors:
- A lot of noise outside our office
- A lot of interruptions either by fellow employees, by the management or even by members of our team.
- Not enough facilities to relax or make small breaks without thinking about the job
- Lost time for commuting
- Not a viable way to exercise before, during or immediately after work.
I presented my proposal to the management. Although, the initial reaction was positive some skepticism creeped in later and we spent about 6 months thinking it over, until two weeks ago when we finally started working remotely.
Although we discussed a lot of issues with management, I identified three major concerns they had:
What if anyone in the company wants to communicate with us directly?
When I say directly, I mean someone opening our door barging in, and start “communicating” regardless of what the other person is doing or if they want to be interrupted.
I said that this should not be a concern. In fact, not being able to communicate directly would be a benefit. That led to the next concern.
What if people start spending more time preparing feedback for the development team?
In the company I work, there are three methods for giving feedback to the programmers: 1) Using FogBugz, 2) “Communicating” directly, and 3) A combination of the aforementioned methods.
Direct and informal communication is the least work for someone. It can be also viewed as a tool that helps us organize our thoughts. We think out loud, throw our thoughts to our listener and they help us polish our thoughts by occasionally expressing their opinion.
This is all good and fine, if it happens with the consent of the listener. Unfortunately most of the times this is not the case. Furthermore, the majority of people are kind and try to be polite by not making it clear to the interrupter that they didn’t want to be interrupted in the first place. However, the ultimate truth is that programmers don’t like being interrupted.
Consider for a minute a car production line. No one in their right mind would ever think interrupting the production flow, even if restarting it might take a few seconds. Why, then, is it natural for most people to interrupt a programmer? Their “restart” takes about 15 minutes and after a couple of these, the whole work day might go down the drain.
You can either be polite and ruin your flow, be harsh and ruin your relationship with your fellow coworkers or maybe choose an alternative that may eventually make people come to you as a last resort.
Nevertheless, interrupters complain that all other forms of communication make them lose time. Writing, taking screen shots, making videos, talking using Skype or similar IMs, or making mock-ups takes more time and needs more effort than barging in and talking directly.
I say that taking more time to create descent feedback brings better results, because the effort and the thinking one must do forces them to do a better job.
However, what happens when something urgent comes up and trying to communicate without direct contact is inefficient? Which brings us to the next concern.
What if something urgent happens that demands direct communication and cooperation?
Usually after a fresh software release (but not only) problems arise at the customer. These are the problems that couldn’t be caught by the programmers and the testers. Sometimes, these problems might be show stoppers and that is when the issue is marked as urgent. The pressure by the customer and the management is big and people that try to solve the problem are anxious and in a hurry.
This is a situation when direct communication is better. We chose to deal with such situations in a proactive way. Each time we know the chances are high for such urgent situations, the programmers involved should be in the office. For example, the day of release, the programmer in charge of the project comes in and is available to solve any urgent problems.
Of course, problems don’t always appear at the same day of the release. They might even appear months later. We created another rule for that. The programmers come at the office, if they feel they can’t solve a problem quickly because of the fact they are away. This is possible because every programmer is 20 to 40 minutes away from HQ.
The team works remotely two weeks now. The first feelings are positive. I get reports from my fellow team members about how wonderful it is to work without being directly interrupted. Also, how less they get tired during the day and how peaceful it is to be at home. They also say they feel their productivity improved, but I think we need more time to reach a safe conclusion.
Our fellow consultants and testers, look at this positively and I want to take the opportunity and thank them for their patience. Of course, they spend more time trying to prepare their feedback, but it is very early to say if the time they spend will remain at the same levels or whether it will drop. Also, we don’t know yet if the time they spend is compensated by the potential increase in the programmers’ productivity.
Finally, ITS S.A., the company I am cooperating very closely with, is I think among very few companies in Greece that would allow such an experiment. If I am wrong, please feel free to post a comment.
In my next posts I will try to describe how we try to avoid alienating the team and generally disconnecting them from the workplace. Also, I am going to write about more practical things we do and tools we use to help us work remotely.
I would be very pleased if you posted some comments with questions I could answer or with your experience in similar situations.