Team Organization for Small Team

Question

Few friends (3) and I started a small company. But we weren't shure how to organize ourselves since everyone will work from their homes and in different hours of the day. How should we organize in terms of work to do, bugs, etc? Should we use an agile methodology like "adapted" for our small team?

Answer 1

My current employment is within an enterprise however the team size is small at 5 individuals. On top of that we are dispersed geographically, 2 in one state, 1 in another state, 1 in another state, and 1 in another country.

Our success thus far has hinged on using cloud based solutions within a Scrum methodology. We use tools such as ScrumWorks free offering (since it can be hosted within our domain however VersionOne has a free offering that can be up and running within their domain) as the base of the process. We then leverage Planning Poker which is also another free offering.

We follow the typical Scrum process complete with a daily stand-up meeting. The stand-up meeting has by far been the best approach in attempting to bring about cohesion throughout the team and attempt to remove the isolation that can exist in this type of atmosphere. The daily stand-up coupled with a live form of communication (we use Office Communicator in the enterprise however any IM client would suffice) are critical to insuring a sense of community.

With varying native tongues amongst the team the telephone is a prominent form of communication for in depth conversation however the benefit tends to vary as it can sometimes make the communication much more difficult; as a given accent can sometimes make it difficult however as with anything the more you do it the better you become.

On the flip side I have worked within a team that was located within the same building and no technology or methodology has provided the type of cohesion that close proximity can provide. There was a recent study that provided *empirical evidence to the fact that close proximity of team members is beneficial to the long term goal of the project.

Bottom line is that you will need to find out what tools work best for you. Make sure that the entire team speaks their mind on what is and is not working or isolation will surface very rapidly.

*I can not find the link at the moment but will post it once I do.

EDIT:

Based on comments...

Source control is via svn which is addressed by the enterprise via a custom solution leveraging CollabNet. This solution also takes care of defect management at a higher level as we then port those defects to ScrumWorks to get placed on the sprint backlog. In addition it also provides access to a build environment for CI and deployment.

Testing is attached to the stories from a unit/integration stance; ie...a stories point estimation should and will include testing. That is not a separate component; it is part of the development effort. The testing framework used is NUnit and tests are then ran within the IDE (Visual Studio) via a tie in into NUnit.

This allows the developer to constantly check in and run their tests as needed. Since we are a small team; ownership on problems within the code base rarely happen and we do not implement a strict only check-in when the code has passed all tests mentality as that is not the purpose of version control. Being dispersed it is critical that we check in frequently.

If you do not have access to an enterprise solution your next best bet would be to leverage a VPS hosting solution as they can be had for fairly cheap ($20.00 US/month) and it would allow you to centralize your source, provide version control, DR, deployment of ScrumWorks and other needs as they surfaced.

Answer 2

A few colleagues and I are doing the same thing. We are using Kanban (David Anderson has a GREAT book on it) via Agile Zen (a pretty good distributed Kanban board). Now you divide the work by prioritizing it. When someone is ready to work on something new, they pull from the queue.

For version control, we use Mercurial with a hosted central repo running under IIS. (Amazing tool, take a quick ten minute tour and you'll be hooked). I subscribe to Microsoft BPOS for collaboration (hosted exchange, sharepoint, live meeting, and communication server). What's great about office communicator is that discussions are automatically archived in Outlook so you can search through them easily.

Answer 3

I'd be tempted to call a meeting and see what kind of structure do people want and what would work for various people in the group. Some people may prefer having a designated leader while others may be more comfortable with the idea of a self-organizing team. The question is what kinds of backgrounds and preferences do you have within that team as that is what would determine for me what kinds of things I'd want to try initially and then refine as needed, which may sound rather Agile to some.

Answer 4

Main thing to remember: be down to Earth, be reasonable. See behind fancy buzzwords its real meaning and its real value.

As for specifics, and assuming that your team consists of three instances of me:

• Use git for version control system: http://whygitisbetterthanx.com/;
• Have a file with prioritized list of features to add to your app. Important: don't remove completed features from this file;
• Use whiteboard, sticky notes, marker, especially if you work pysically together;
• Use an open-source bug tracking system;
• DO have stand-ups/status meetings every working day. I don't think meeting notes are necessary for you;