While the purpose of the off-site for other teams was to determine strategy, our off-site was a working off-site. We brought our workstations and intended to make serious right at the beginning of the project. Consequently the agenda was light:

Agenda

Wednesday EOD - pack up computer equipment

Thursday
8:30 am
- Those who are driving, pick up mini-vans
- Others should arrive at the office

9:20 am
- Pack up the mini-vans

10:00 am - should be on the road

12:30 pm
- Lunch at the inn
- Meeting on format and agenda for the rest of the week

1:30 pm
- Set up equipment

Thursday, Friday, Saturday
- Work
- Meals and snacks will be provided

Sunday
9 am
- breakfast
- Off-site thoughts. What worked, what didn't? Was this valuable? What could make it better?

Tuesday following off-site, 2/13
- Recap meeting and demos

It's commonly thought that the most important time for a new development project is the first month. This is where the overall architecture for the project will be conceived and important patterns for collaboration and integration will be set (either officially or implicitly).

Benefits of a Developer Offsite

Quiet Time

There is a lot of noise in our office. Joel Spolsky discusses this problem here: Do programmers have quiet working conditions?. The offsite was a good way to get away from it. Of course, there are simpler solutions that can be done in the office. I expect that we will solve this problem this summer.

Focus: Software developers like to develop software!

No distractions. Email, IM and cell phone use were at a minimum. No meetings. No random walk-up interruptions during the day. In short, the team was able to spend significant, continuous time writing software. 37Signals addresses this need in their book Getting Real: Alone Time.

And because we were in another state, there was little reason to go home, so we ended up working till midnight on two of the three nights. Don't expect them to work that way all the time, but remember: "Software developers like to develop software!" A smart company will look for ways to leverage this and create an environment where software development is fun.

Collaboration

Having product, development and DBA in the same room was a huge benefit. First, it allowed for bonding right at the start of the project, as only a shared experience can do. They formed a team and now feel jointly responsible for the outcome of the project. I.e. team work. Second, being early in the development stage, there were still questions and ambiguities that needed to be addressed. The physical proximity allowed for quick, barrier-free discussion and resolution. We had the datamodel for the core functionality completed, discussed and agreed upon by the end of the second day.

Innovation

The change of setting and proximity allowed for open discussion of new ideas. Possible future enhancements for the project and ideas for new features and products altogther. I find that developers and product managers like to move between the practical ("how do we get this done") and the theoretical ("what else can we do") throughout the day. The variety keeps them energized and engaged.

The Outcome

Summary: They loved it. A great way to focus and make serious progress. "This would have taken us a week and a half in the office [instead of 3 days]" --One Developer. Great way to communicate and coordinate, especially for refactoring tasks. Long drive, though, and they would prefer not to give up a weekend.

Swapping weekdays for weekends was suggested as a way to make progress without the overhead and coordination needs of a full off-site.

More feedback in Q&A form follows:

Q1. Noise level?
a. 6 said fine or good
b. 2 needed ipod to drown out the noise
c. 1 better than office

Q2. Right people involved?
a. Product: Should have had someone from the UI team
b. Developers: yes.

Q3. Was the length of time right?
a. Larry: More time away would be nice, but not offsite (doesn't want to be away from home longer)
b. Product: Would have wanted more time if they were in the initial spec writing phases. But this length was good for this stage.
c. Most of them were exhausted by the end (fri and Saturday worked until 11 or 12 at night.
d. Dmitri: Good time frame for datamodel completion.

Q4. Overhead for traveling to off-site? Should it be local?
a. Still do a stay-over, but it should be closer. Maybe 45 minutes to an hour away. Outside the city to avoid distractions. Should be isolated.
b. Larry: good distance.

Q5. Do you resent giving up a Saturday?
a. Mona: No. Would have had to work anyway
b. Others: Yes. Would be ok if they had Monday (or some other day) off instead. They were exhausted in the office the next day, and not at peak performance.

Q6. Should there have been a more rigid agenda or schedule?
a. Dmitri: should have set deadlines
b. Others: No.

Q7. What did you think of the facilities? The food?
a. Facilities: good.
b. Especially liked the horseshoe conference room set up.
c. Food: nice try, but too oily. Minimal selection. Recommend going into town for dinners to mix it up.
d. Should take an extra box of spare parts (video cable, power, mouse, etc)
e. Josh: Someone should have moved and set up equipment for us.

Q8. Do we think off-sites are best for innovation or for progress?
a. Both. Great to have focus.
b. Innovation: One day in-city offsites might be more appropriate
c. Progress: As an alternative, work in the office and swap weekdays for weekends. Not quite as good, as the change of surroundings can be a catalyst and a focal point.

Q9. Should we strive for 100% separation from the office? I.e. no interruptions. No email, etc.
a. Dmitri: Yes. That is the purpose of the off-site
b. Product: Needed email, b/c they were in the late phase of the project. They also want to have access to the rest of the team for input and suggestions.
c. Keep email access, but check it only occasionally.
d. Rest of the company should be instructed to respect this separation and keep contact to a minimum.