Two people that meet regularly are already a community. The first thing to know if you want to start a community is that it is much simpler than you think. You just need another person that is keen to meet regularly and a public space like a coffee shop or a quiet pub. That's it. You already have your community going. Everything else that follows in this blog post are just things that helped us to grow the London Software Craftsmanship Community (LSCC) from two people to the largest software craftsmanship community in the world, but they are not essential to have a great and healthy community.
This is an important thing. Don't try to run your community from a mailing list; make sure you have a proper website. One of the points of being part of a community is to know who else is in the community. As a member, I want to go to the website and see when the next events are. I want to be notified in advance about the events, and be reminded about the events one or two days before they happen. I want to know who else is going to the event. I want to place myself on a waiting list in case the event is full. I want to tell others that I'm going to the event. I want to see the profile of the people attending the event so I can have more focused conversations during or after the event. I want to have a mailing list where I can ask questions and engage in discussions.
The good news is that there are a few websites out there that, for an annual subscription, you can have all that. We decided to use Meetup.com (used by the majority of the Software Craftsmanship communities around the world) and I highly recommend it. Don't waste your time trying to create your own website, at least not in the first year or so. Focus only on the quality and content of your meetings. Don't waste your time doing things that are already done for you. Websites like Meetup.com will take care of all the admin work for you: controlling registrations, email, waiting list, reminders, etc. (In case you are wondering, I don't get any commission from Meetup.com, however, now that I thought about it, I probably should.:))
Some communities started with a big first meeting. Others started quite small and without much noise. As you probably guessed, there is no right or wrong. In London, we decided to give a talk on Software Craftsmanship. The London Java Community (LJC) announced our talk to their members. SkillsMatter, the training centre where the talk happened, also announced on their website and for our huge surprise, 120 people showed up. The Paris Software Craftsmanship Community (PSCC) invited me to give a talk for their kick off meeting and they had more than 50 people.
It helps if you can have a big first meeting; potentially inviting someone that you know that can give a good talk on Software Craftsmanship but that is not really necessary. Many other communities started really small and now they are doing really well. It's important that we understand that a Software Craftsmanship community is not about numbers or well-known people. A Software Craftsmanship community is about passionate software developers sharing and learning from each other, regardless if there are 5 or 1000 of them.
The simpler the meetings are, the better. When starting a Software Craftsmanship community, chances are that you won't have much help. We are all busy people, with families, work, and many other activities. If we make the job of organising a community a burden, we will end up giving up. To minimise the chances for that to happen, make sure that, at least in the beginning, your meetings are extremely simple to organise.
For almost one year, we just had one meeting a month: The Software Craftsmanship Roundtable. This meeting was limited to 30 people. Back then, I was working for [Valtech](http://www.valtech.co.uk/) and they were kind enough to let me use their office space from 6:30pm to 9pm. They also paid for pizzas and soft drinks.
The Software Craftsmanship Roundtable is a very easy meeting to organise. At the start of the meeting, we ask all attendees if they want to give a lightning talk (five minutes for the presentation, two minutes for questions) or/and propose a topic for a group discussion. Attendees write their lighting talks or topics for discussion in a Post-It and stick them in a white board. While we are eating some pizza, people present their lighting talks. The facilitator, normally the community organiser, keeps track of time. Once all the lightning talks are finished (if any), we ask each person that proposed a topic, in turn, to give a 30 seconds explanation of what they want to discuss. Once all topics are explained, we take a vote. Every one raises their hands for the topics that they want to discuss (they can vote for more than one topic) and the most voted topic gets discussed. Sometimes we discuss a single topic in one night; sometimes we discuss three or four. Depending of how people vote, we some times split in two groups and then have a retrospective at the end. Every 30/45 minutes (use your gut feeling) you ask the group if they want to keep discussing the same topic or pick another one.
The great thing about the round table is that whichever topic is chosen, we know we are going to have a good discussion since the majority of the people voted for it. Topics can vary immensely, from tools and good practices to continuous deployment, from design and architecture to interview techniques, from how to convince teammates to adopt TDD to functional languages.
The overhead of organising a roundtable is very small. You just need to make sure you have a venue. If you don't have an office space, do it in a coffee shop or pub. Food is totally optional. If you have it, great, if you don't have it, it's OK. Don't let food sponsorship be the reason for not having a meeting. I'm sure people wouldn't mind to eat before or after the meeting and pay for it themselves. :)
Hands-on sessions tend to be slightly more difficult to organise. This is the second type of meeting we introduced. Arguably, it should have been the first type of meeting to have but that was what we did. Hands-on sessions require a venue where people can not only sit down but also have a place to put their laptops. That means that not always a pub or another public place can be a good choice. A proper office space is always a better option.
Over the years we had many different types of hands-on session. Some of them required a lot of preparation; some of them were dead simple to organise. We also had a mix of very experienced and not so experienced people running the sessions. They were all great.
For the first few hands-on sessions, keep it simple. Choose a kata, do it yourself a few times, and don't tell anyone which kata you've chosen. All attendees need to bring their own laptops with their favourite languages and testing frameworks installed. Have all attendees in a room and ask them to pair up with someone; preferably someone that they don't know or they never paired before. At least one person in the pair needs to have a laptop configured with their favourite language and testing framework. For people starting with TDD, it helps if they pair with people a bit more experienced. Give them time, between one and two hours, with a few breaks (5 minutes) for sharing, and towards the end, run a retrospective. While the pairs are working on the kata, walk around, observe what the pairs are doing, and help the pairs that are stuck. In the final retrospective, ask the pairs which approach they used, what they've learn, which technologies they used, etc. As you know what the majority of the pairs have done, you can poke people to share what they've done. :)
There are many different types of things you can do in a hands-on session but I'll leave them to another post.
A community needs to have a rhythm. A heartbeat. For example, our Software Craftsmanship Roundtable meetings are always on the second Tuesday of the month, at the same time, in the same place. Our hands-on sessions are always on the last Wednesday of the month. Code & Coffees are always every other Tuesday in the same coffee shop.
It's important that members of the community know when and where the meetings are going to happen so they can organise themselves to be there. A good rhythm keeps the community alive. When choosing a venue, make sure you can run meetings there every month. Once you run the first meeting in a new venue, it is much easier to run subsequent ones. Finding venues is not always easy, so make sure you don't need to do it every month.
In case you can't be in the meeting, make sure someone else can facilitate the meeting. Try never to break the rhythm. Having long gaps between the meetings will make people loose interest.
Make sure that you never have an empty calendar, that means, as soon as the a meeting is finished, you should have the date for the next meeting. People tend not to join a group if there are no meetings scheduled.
There are quite a few Software Craftsmanship communities that have many technology specific meetings. By that, I mean, they have a hands-on session to learn Erlang, or to try a JavaScript framework, or a specific NoSQL database. From what I know, that is working well for them.
In LSCC, we made a commitment from day one that all our meetings would be technology agnostic, and for the past three years we never had a single meeting that was related to a specific technology. There are a few reasons for that:
There is no right or wrong here and you need to use your gut feeling. Listen to the people coming to the meetings and try to provide what they want. However, at the very beginning, they probably won't know what they want, so you will need to make the call. Technology agnostic has better chances to attract more developers, from all sorts of backgrounds, which in turn will make the community more diverse. And that is exactly what we always wanted.
Learning, sharing, and having fun with like-minded people are the most important things in any technical community. As an organiser, make sure that this is your main focus. Growth is not important. Number of people attending the meetings is not important. Whoever comes is the right people. If everyone enjoys the meetings, they will invite their friends, they will tell other developers, so don't focus on growing your community. That will happen as a side effect.
In LSCC we have the LSCC Associates. Associates are some of the LSCC core members that I invited to help me with the organisation of the community. They are people that come to the vast majority of our meetings, are extremely passionate, talented, and fully understand the Software Craftsmanship ideology. The difference between them and the organiser and the associates is the level of commitment. Associates help whenever they can while the organiser doesn’t really have this option. Some associates will quickly step up and can easily become co-organisers.
As the community grows, you, as an organiser, will need help. Also, there is a limit for what you can do; the community needs variety. The community should never be about the organiser. The community should be about the community. Having a good group of people sharing the organisation should be one of your priorities as an organiser.
We have a separate Google group for the Associates where we discuss everything that is related to the community: ideas for a session, who is going to run it, new companies interested in sponsoring (venue, food, etc), new types of meeting, and many other things. At the beginning you may want to have one or two people to help you. As the community grows, you will need quite a few more.
Associates bring variety and enthusiasm. They keep the community alive and healthy. LSCC would never be so awesome without all the LSCC Associates.
If there is any other user groups or technical communities in your city, go and speak to them. One of the reasons for the LSCC success is our proximity to other communities. The idea for starting LSCC happened during a conversation I had in one of the London Java Community meetings, and from day one we had the support from the LJC organisers. LJC, back then, already had more than 1000 members and they announced many of our events to the LJC members. We also have a good relationship with other local user groups. In the early days, we made sure that none of our meetings would clash with meetings from other user groups so we all could go to each other meetings.
It's your responsibility, as an organiser, to protect your community. As the number of developers grows, you will see many recruiters and marketeers approaching your community. They will try to use the community's mailing list to advertise their conferences, products, companies, etc. Protect your members and the community mailing list. At LSCC we don't allow any recruiters or people that are not directly involved with a software project to join. For that, membership is by approval only, and I do my best make sure that just people that can contribute to the community will join. We ask every member to write a brief description about who they are. We don't accept memberships where people don't write anything about themselves. A community is not a community if every person in the community doesn't have a profile. Currently I decline between 5 to 10 memberships a month. They are normally recruiters and people trying to advertise their stuff. Sometimes I even Google people and search them on LinkedIn to make sure they are really developers.
There is nothing that the community will gain with people spamming our mailing list. The only thing that will happen is that members will leave the community because of spam.
I know that there is a lot in this post and maybe I made it sound far more complicated than it really is. Organising a community is a lot of fun and has many benefits. You will learn more than you can ever imagine and you will also be helping many other developers to learn as well. That, on its own, is more than enough reason to start a community.
Keep it simple and get more people involved. If you follow that, you will have a successful community.
If you start a Software Craftsmanship community, let us know. All of us from LSCC will be more than happy to help. I wish you all the best with your new community and, above all, I hope you have a loads of fun.
You can email me at sandromancuso at gmail dot com or find me on Twitter @sandromancuso
Community website
This is an important thing. Don't try to run your community from a mailing list; make sure you have a proper website. One of the points of being part of a community is to know who else is in the community. As a member, I want to go to the website and see when the next events are. I want to be notified in advance about the events, and be reminded about the events one or two days before they happen. I want to know who else is going to the event. I want to place myself on a waiting list in case the event is full. I want to tell others that I'm going to the event. I want to see the profile of the people attending the event so I can have more focused conversations during or after the event. I want to have a mailing list where I can ask questions and engage in discussions.
The good news is that there are a few websites out there that, for an annual subscription, you can have all that. We decided to use Meetup.com (used by the majority of the Software Craftsmanship communities around the world) and I highly recommend it. Don't waste your time trying to create your own website, at least not in the first year or so. Focus only on the quality and content of your meetings. Don't waste your time doing things that are already done for you. Websites like Meetup.com will take care of all the admin work for you: controlling registrations, email, waiting list, reminders, etc. (In case you are wondering, I don't get any commission from Meetup.com, however, now that I thought about it, I probably should.:))
Your first meeting
Some communities started with a big first meeting. Others started quite small and without much noise. As you probably guessed, there is no right or wrong. In London, we decided to give a talk on Software Craftsmanship. The London Java Community (LJC) announced our talk to their members. SkillsMatter, the training centre where the talk happened, also announced on their website and for our huge surprise, 120 people showed up. The Paris Software Craftsmanship Community (PSCC) invited me to give a talk for their kick off meeting and they had more than 50 people.
It helps if you can have a big first meeting; potentially inviting someone that you know that can give a good talk on Software Craftsmanship but that is not really necessary. Many other communities started really small and now they are doing really well. It's important that we understand that a Software Craftsmanship community is not about numbers or well-known people. A Software Craftsmanship community is about passionate software developers sharing and learning from each other, regardless if there are 5 or 1000 of them.
Start with simple meetings
The simpler the meetings are, the better. When starting a Software Craftsmanship community, chances are that you won't have much help. We are all busy people, with families, work, and many other activities. If we make the job of organising a community a burden, we will end up giving up. To minimise the chances for that to happen, make sure that, at least in the beginning, your meetings are extremely simple to organise.
For almost one year, we just had one meeting a month: The Software Craftsmanship Roundtable. This meeting was limited to 30 people. Back then, I was working for [Valtech](http://www.valtech.co.uk/) and they were kind enough to let me use their office space from 6:30pm to 9pm. They also paid for pizzas and soft drinks.
The Software Craftsmanship Roundtable
The Software Craftsmanship Roundtable is a very easy meeting to organise. At the start of the meeting, we ask all attendees if they want to give a lightning talk (five minutes for the presentation, two minutes for questions) or/and propose a topic for a group discussion. Attendees write their lighting talks or topics for discussion in a Post-It and stick them in a white board. While we are eating some pizza, people present their lighting talks. The facilitator, normally the community organiser, keeps track of time. Once all the lightning talks are finished (if any), we ask each person that proposed a topic, in turn, to give a 30 seconds explanation of what they want to discuss. Once all topics are explained, we take a vote. Every one raises their hands for the topics that they want to discuss (they can vote for more than one topic) and the most voted topic gets discussed. Sometimes we discuss a single topic in one night; sometimes we discuss three or four. Depending of how people vote, we some times split in two groups and then have a retrospective at the end. Every 30/45 minutes (use your gut feeling) you ask the group if they want to keep discussing the same topic or pick another one.
The great thing about the round table is that whichever topic is chosen, we know we are going to have a good discussion since the majority of the people voted for it. Topics can vary immensely, from tools and good practices to continuous deployment, from design and architecture to interview techniques, from how to convince teammates to adopt TDD to functional languages.
The overhead of organising a roundtable is very small. You just need to make sure you have a venue. If you don't have an office space, do it in a coffee shop or pub. Food is totally optional. If you have it, great, if you don't have it, it's OK. Don't let food sponsorship be the reason for not having a meeting. I'm sure people wouldn't mind to eat before or after the meeting and pay for it themselves. :)
Hands-on session
Hands-on sessions tend to be slightly more difficult to organise. This is the second type of meeting we introduced. Arguably, it should have been the first type of meeting to have but that was what we did. Hands-on sessions require a venue where people can not only sit down but also have a place to put their laptops. That means that not always a pub or another public place can be a good choice. A proper office space is always a better option.
Over the years we had many different types of hands-on session. Some of them required a lot of preparation; some of them were dead simple to organise. We also had a mix of very experienced and not so experienced people running the sessions. They were all great.
For the first few hands-on sessions, keep it simple. Choose a kata, do it yourself a few times, and don't tell anyone which kata you've chosen. All attendees need to bring their own laptops with their favourite languages and testing frameworks installed. Have all attendees in a room and ask them to pair up with someone; preferably someone that they don't know or they never paired before. At least one person in the pair needs to have a laptop configured with their favourite language and testing framework. For people starting with TDD, it helps if they pair with people a bit more experienced. Give them time, between one and two hours, with a few breaks (5 minutes) for sharing, and towards the end, run a retrospective. While the pairs are working on the kata, walk around, observe what the pairs are doing, and help the pairs that are stuck. In the final retrospective, ask the pairs which approach they used, what they've learn, which technologies they used, etc. As you know what the majority of the pairs have done, you can poke people to share what they've done. :)
There are many different types of things you can do in a hands-on session but I'll leave them to another post.
Rhythm
A community needs to have a rhythm. A heartbeat. For example, our Software Craftsmanship Roundtable meetings are always on the second Tuesday of the month, at the same time, in the same place. Our hands-on sessions are always on the last Wednesday of the month. Code & Coffees are always every other Tuesday in the same coffee shop.
It's important that members of the community know when and where the meetings are going to happen so they can organise themselves to be there. A good rhythm keeps the community alive. When choosing a venue, make sure you can run meetings there every month. Once you run the first meeting in a new venue, it is much easier to run subsequent ones. Finding venues is not always easy, so make sure you don't need to do it every month.
In case you can't be in the meeting, make sure someone else can facilitate the meeting. Try never to break the rhythm. Having long gaps between the meetings will make people loose interest.
Make sure that you never have an empty calendar, that means, as soon as the a meeting is finished, you should have the date for the next meeting. People tend not to join a group if there are no meetings scheduled.
Technology Specific vs. Technology Agnostic
There are quite a few Software Craftsmanship communities that have many technology specific meetings. By that, I mean, they have a hands-on session to learn Erlang, or to try a JavaScript framework, or a specific NoSQL database. From what I know, that is working well for them.
In LSCC, we made a commitment from day one that all our meetings would be technology agnostic, and for the past three years we never had a single meeting that was related to a specific technology. There are a few reasons for that:
- We didn't want to alienate a single member of our community
- We wanted to focus on the foundations of software development and not in specifics of a language or framework.
- each developer can choose the language they want to use and who they want to pair with.
- If the community has monthly meetings and you (as a member) are not interested in the technologies chosen for the meetings, you may not attend the meetings for many months; you may even leave the community.
- We are fortunate to be in London, a city that has user groups and technical communities for all the main technologies out there. No point in doing what they already do well.
There is no right or wrong here and you need to use your gut feeling. Listen to the people coming to the meetings and try to provide what they want. However, at the very beginning, they probably won't know what they want, so you will need to make the call. Technology agnostic has better chances to attract more developers, from all sorts of backgrounds, which in turn will make the community more diverse. And that is exactly what we always wanted.
Focus on learning, sharing, and having fun
Learning, sharing, and having fun with like-minded people are the most important things in any technical community. As an organiser, make sure that this is your main focus. Growth is not important. Number of people attending the meetings is not important. Whoever comes is the right people. If everyone enjoys the meetings, they will invite their friends, they will tell other developers, so don't focus on growing your community. That will happen as a side effect.
Associates
In LSCC we have the LSCC Associates. Associates are some of the LSCC core members that I invited to help me with the organisation of the community. They are people that come to the vast majority of our meetings, are extremely passionate, talented, and fully understand the Software Craftsmanship ideology. The difference between them and the organiser and the associates is the level of commitment. Associates help whenever they can while the organiser doesn’t really have this option. Some associates will quickly step up and can easily become co-organisers.
As the community grows, you, as an organiser, will need help. Also, there is a limit for what you can do; the community needs variety. The community should never be about the organiser. The community should be about the community. Having a good group of people sharing the organisation should be one of your priorities as an organiser.
We have a separate Google group for the Associates where we discuss everything that is related to the community: ideas for a session, who is going to run it, new companies interested in sponsoring (venue, food, etc), new types of meeting, and many other things. At the beginning you may want to have one or two people to help you. As the community grows, you will need quite a few more.
Associates bring variety and enthusiasm. They keep the community alive and healthy. LSCC would never be so awesome without all the LSCC Associates.
Good neighbours
If there is any other user groups or technical communities in your city, go and speak to them. One of the reasons for the LSCC success is our proximity to other communities. The idea for starting LSCC happened during a conversation I had in one of the London Java Community meetings, and from day one we had the support from the LJC organisers. LJC, back then, already had more than 1000 members and they announced many of our events to the LJC members. We also have a good relationship with other local user groups. In the early days, we made sure that none of our meetings would clash with meetings from other user groups so we all could go to each other meetings.
Protect your community
It's your responsibility, as an organiser, to protect your community. As the number of developers grows, you will see many recruiters and marketeers approaching your community. They will try to use the community's mailing list to advertise their conferences, products, companies, etc. Protect your members and the community mailing list. At LSCC we don't allow any recruiters or people that are not directly involved with a software project to join. For that, membership is by approval only, and I do my best make sure that just people that can contribute to the community will join. We ask every member to write a brief description about who they are. We don't accept memberships where people don't write anything about themselves. A community is not a community if every person in the community doesn't have a profile. Currently I decline between 5 to 10 memberships a month. They are normally recruiters and people trying to advertise their stuff. Sometimes I even Google people and search them on LinkedIn to make sure they are really developers.
There is nothing that the community will gain with people spamming our mailing list. The only thing that will happen is that members will leave the community because of spam.
Have fun
I know that there is a lot in this post and maybe I made it sound far more complicated than it really is. Organising a community is a lot of fun and has many benefits. You will learn more than you can ever imagine and you will also be helping many other developers to learn as well. That, on its own, is more than enough reason to start a community.
Keep it simple and get more people involved. If you follow that, you will have a successful community.
If you start a Software Craftsmanship community, let us know. All of us from LSCC will be more than happy to help. I wish you all the best with your new community and, above all, I hope you have a loads of fun.
You can email me at sandromancuso at gmail dot com or find me on Twitter @sandromancuso
