I‘m not an expert in setting up and running user groups. But these are my experiences starting a few agile user groups in India and Philly.

Following are important ingredients for any user group:

1. Vision or Goal
2. Facilitator
3. Body of knowledge
4. Discuss topics or content
5. Individuals
6. Venue
7. Offline discussion forum

Vision: The primary vision/purpose/goal of any user group is to provide a platform for the members to share and learn from each other’s experience. Its a peer-to-peer learning and exploration platform. I like to call this SCube = Speak, Share and Seek.

Facilitator: Running a user group needs one or more facilitators who understand this vision/goal backed with a lot of passion, motivation and energy. Their primary purpose is to build a self organized group without trying to be gatekeepers. The facilitator need not be an expert on the topic. What I have seen happen in most of the cases is:
“A person is interested to learn more about a subject and is looking for ways to learn from other people’s experience. S/he is unable to find an existing platform to exchange ideas with other people. So they go the extra mile to set up a platform for people to meet”.

Starting a group is relatively easy. The real fun is in sustaining the group. As the group starts growing, one has to make sure the right topics are been discussed. They also need to keep people’s egos under check as the group grows bigger.

Body of knowledge: Every user group needs some source of information for the following

• to drive the topics
• to get external speakers and
• to help with the logistics.

The internet can be a very good source of this knowledge. It can also be very helpful to have a body that supports such initiatives. For examples in India, ASCI can help you and support you if you want to set up Agile User Group in your city. Right from financial support to logistics and contacts, all of this information/knowledge can be provided by these bodies. They can also help the group to be focused.Discussion topics or content: This is the real meat for which people would be interested in the user group. The group needs to have a good mix of the following:

• Presentations: Good for introductory sessions and for presenting experience reports. Helps to bring people on the same page in terms of terminologies, vocabulary etc.
• Discussions: There are different formats of discussion which can be helpful:
  • Bird of Feather
  • Open spaces
  • Fishbowl
• Activities/Games: This is one of the best ways for people to experience the topic. Folks have found innovative ways of explaining both technical and methodology related topics. For Ex. Agile related topics XP Game or Waterfall to Agile Demo
• Hands on sessions or workshops: While the participants can benefit the most out of these sessions, it‘s also a lot of work to set this up. In the agile space the most common workshops are:
  • TDD workshop
  • Refactoring fest
  • Coding dojo
  • Coding Kata
  • Testing workshop: Any one testing tool is selected. The participants are given with an application to test using this tool.

One should try to involve experience people to present/facilitate some of these discussions. In fact I have seen most innovative ideas come out when someone from the particpants come forward to facilitate the meeting.

Individuals: Having a small group of motivated individual willing to self organize. Most importantly they should be eager to learn and open to share knowledge. Having a diverse group of people from different companies/backgrounds can maximize the learning for everyone. When starting a new user group I have always found it to be helpful to not focus on numbers. A small set of motivated individuals is more important than a hall full of “I don’t care” individuals.

Venue: Any decent place convenient for majority of the group to meet. Ideally a conference room at someone‘s office or a classroom in some university or just any place can work. If you are using office space for meeting, be sure to rotate the venue between different similar companies to avoid one company‘s monopoly.

Offline discussion forum: A wiki and/or a user group on Yahoo or Google can provide the platform for offline discussion and collaboration. Any logistics related info should be radiated thru this forum. Great discussion happens on mailing list, but one needs to be aware of their limitations due to deterioration in communication bandwidth.

How to get started?
I believe in starting small. Trying to get a small, focused group of motivated individuals meet regularly and discuss interesting topic. Topics than can help them right away at work or else where. One should be able to find few people in their city or near by, who have experience on the topic. They can share their experience.

Once you have a small group in place, you should form a mailing list and start the initial discussion. Hopefully someone from this group should be able to get a venue for the meetings. Coffee shops, bars, office spaces, university class rooms are all good to begin with.

One should try and find people in the group who can volunteer to present/facilitate a topic/discussion. To start, it would be good to have a few nice topics on hand and then let the group decide what direction they want to take after that. Just discussions can get boring; organizing some activities can really help break the ice. In addition to these activities it would be good to find someone who can facilitate a workshop or some hands on sessions.

Asking people for suggestions about books, sites, articles, blogs, etc can help to get started.

Abstract: Introduce the participants to real world refactoring by taking an open source project and refactoring it. This session will help people understand
1. How to identify code smells?
2. How to eliminate the code smells by applying refactoring techniques explained in Martin Fowler‘s book?
3. How to refactor in absence of unit and functional tests [Working effectively with legacy code base]?
4. How to refactor to patterns?
5. Internals of the open source project chosen to refactor

Type of session: Hands on session.

Prerequisites:
1. Good Object Orient programming skills
2. Experience with Unit testing using the xUnit framework. Experience with mock objects can be helpful.
3. Pair programming. The participants should be willing to pair program. They will need to pair and do the real thing
4. The group decides any one open source project in the language of their choice.
5. Laptops or machines should be setup with a decent IDE and the source code. Each pair should have at least one functional laptop/machine. Make sure the code compiles and works on each machine.
6. Projector to which all the machines can be connected one after other.

Nice to have:
1. Network connectivity
2. A server with version control and continuous integration server setup.

If this approach is chosen, you need to make sure that each pair checks out the source code from this version control repository.

Selection criteria for the open source project:
1. Functionality of the project is pretty simple and straight forward to understand. Ex. Log4j, simple wiki, etc
2. The project is being used extensively on the team. Will help them understand it better.
3. Has an average sized code base. Too huge or too small code base will not be effective.
4. Should be easy to setup and test on any machine.

Execution:
1. Plan for at least five, 2 hours sessions.
2. In the first session,
2.a. First 60 mins: the coach explains/shows different code smells and briefly explains the associated refactoring techniques.
2.b. Next 30 mins: the coach gives a high level over view of the open source project‘s design
2.c. Last 30 mins, the team breaks into pairs and each pair picks up a module/package of the open source project. The rest of the time is spent in understanding the functionality of the module/package in individual pairs.
3. From the second sessions onwards:
3.a. The team splits into pairs, picks one or more classes from the module/package, understand what it does, writes unit tests around it. Once they have sufficient passing unit tests, they start identifying code smells and refactoring them. In some cases, sufficient unit tests might not be required to do simple refactoring like extract method, rename variable, etc. Sometimes internally restructuring the code, can help us understand it better. Hence you need to constantly wear the understanding, unit testing and refactoring hat.
3.b. At the end of 30 mins, the team stops refactoring. Sequentially every team connects to a central project and demonstrates their accomplishment to the rest of the group. The next 30 mins are spent discussing each team‘s refactorings.
3.c. The pairs swap partners so that each team gets a new member and one old member continues on the selected module/package. And they continue refactoring.
3.d. At the end of 30 mins we have another demo and then end of session.
3.e. If we have the version control and continuous server setup then people check in their source code and make sure the build passes.

These sessions can continue as long as the team is interested and they think they are learning something new. At the end of these sessions, the team would have made several improvements to the open source project. These improvements can then be submitted back to the open source community. Having a version control and continuous integration server can really simplify this.

I ran these sessions at ThoughtWorks and will be running them at the Agile Philly user group shortly.