What I really like about this tool is the ease of use and the lack of unneeded options and clicks to get your job done.

I use Jing whenever I want to create a new case using FogBugz. For example whenever I want to report a bug or ask for an enhancement, I may capture the part of the screen of the application, annotate and save it to attach it then to a new case in FogBugz or send it directly using Skype to the remote programmer.

Sometimes, I even capture a video showing how to reproduce a bug. Capturing a video with Jing is very easy because it does exactly what you need, nothing more and nothing less.

Here is an example FogBugz case with a Jing screen capture with annotations for one of our internal projects. We develop this application using DevExpress XAF which is a very good framework for developing intranet applications.

FogBugz Case

This way, I can write fewer words than if I hadn’t prepared the screen capture. I will also try to post a video capture example in the future.

One of the problems working remotely can bring is the feeling of separation from the rest of the company. Although this is not obvious at the beginning, I am sure it can happen and it can lead to unwanted results. When you start working remotely, you appreciate the fact that you can be isolated. This is true because you are already frustrated by the working conditions in the office and being isolated is a gift. As time passes, people in the office may start bothering you less and less. Face to face communication is almost non-existent. Quiet working environment is nice, but some noisy breaks are essential to appreciate the quiet. After a while, you start feeling unneeded, isolated, separated and not included in the office day to day happenings. This can lead to sadness and even melancholy or depression if the separation continues to a great extend.

I decided to deal with this from day one. Our work week goes like this: 4 days remote, 1 day in the office. This helps eliminate most of the problems I mentioned above. We chose Friday as the day we come into the office. Friday is usually a slower day because most of us have already burned a lot of gray cells during the week. This means that most of the people prefer face to face communication for a change. I also hope that this will make everyone wait to use Friday as the “communication” day. We also want to start using Friday as the day to present the results of our weekly iterations, and other technical findings we would like to share with the rest of the team.

We also have two rules: 1) We come into the office whenever we realize that being remote may slow us down when dealing with urgent situations. 2) We come into the office whenever there is a major release that is going to be deployed to the customer. These rules increase our “office time” and help us keep in touch with the rest of the company.

I have to say, however, that all the programmers — including me — have already been working closely in the office a long time before we started working remotely. This means that we already know each other pretty well and we have a very good relationship. The fact that we are all 30-40 minutes away from the office helps maintain this relationship. It is not a problem for us to visit the office whenever we need to.

Our visits to the office at least once a week, help to keep us connected to the rest of the company, but what happens during the rest of the week? How does my team communicate?

We use Skype as the main tool for communicating, either by using IM or voice/video calls. I will come back to this with more details in a future post. What I want to tell you though is that we work “closely” during the week, using technology. So far, we don’t feel disconnected at all. Time will tell if we keep on feeling this way.

I also have some ideas that we haven’t tried out yet:

• Team going out for coffee once a week or once every two weeks
• Same as above, but instead of going out for coffee change that to tavern
• Extend the weekly presentation or bi-weekly ones to the whole company or other departments we cooperate closely
• Engage to sports with the participation of the whole company (although we tried that in the past and it doesn’t seem to be able to get established permanently)

What do you think? What else could help us stay connected? Do you have similar experience you can share?

I identified the following factors:

1. A lot of noise outside our office
2. A lot of interruptions either by fellow employees, by the management or even by members of our team.
3. Not enough facilities to relax or make small breaks without thinking about the job
4. Lost time for commuting
5. 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.

Related articles:

• How to avoid alienation while working remotely
• Using Jing while working remotely