Sunday, February 15, 2009

Building On-line Development Communities

I've been thinking about how I could use social networking to strengthen the sense of community on my product development team. As is the case with most things, this is not a new idea. Open Source Software development has practiced this and embraced community development for years. In fact, one often hears references to the "open Source Community".

My team already has a strong sense of identity and community. But there was (at least) one area I wanted to improve. We didn't really have a repository of our history. Like most software shops, our "history" resides in our e-mail and file systems. That's nice, but it is not easy to find or share. As long as you know the right person to ask for a copy of an e-mail thread, you are fine. Even then, you get whatever thread fragment that person deemed important to save.

There are two distinct technologies I have deployed that have impacted our ability to record history. The first is Discussion Forums; the second is wiki pages. Again, there is nothing new here. However, very few teams I talk to use these technologies. I'm assuming you can figure out how to get these technologies installed and available. I will focus on what might help your
team adopt these technologies.

Start with yourself and your management team
Before rolling out to your entire team, start with your leadership team. Create private discussions and Wiki pages for the leadership team. Seed the topics and encourage your leaders to provide their input using discussion forums and wiki pages. Redirect normal conversations to the new technologies. For example, if someone sends an e-mail to the leadership team, copy it into a discussion forum and reply to that.

Begin to post key information in discussion forums and wiki pages. Make your leadership team accountable for knowing the content by giving them no alternative to find out what you are asking of them. Once you've done this for a few weeks, deploy to the next level.

Deploy to functional teams
Next, require each of your managers to deploy to their teams. Here I assume you have functional managers, such as development, quality assurance, writers, etc. Resist the urge to post into the functional areas. However - and I consider this critical - monitor activity for a few months.

Your goal in "eavesdropping" is to ensure the teams are using the technologies to build communities within the functional areas. If you don't see much activity, discuss it with the functional manager - not with the team. If you do see a community building, by all means praise it publicly. Make it clear you are aware of what is going on. That is perhaps the single best way to make it obvious that this is important to you.

Deploy to project teams
Once folks have gotten used to on-line functional communities, drive adopt to project teams. These are cross-functional teams working on the same release or feature. These are smaller communities that are transient, just for the life of the release or feature.

The key here is to build a community around people trying to solve the same problem. This is also where you build a lot of product history. The discussion forums record the conversation among the team (for example, alternatives for technical design strategies); the wiki pages record the actual decision (final design decision and rationale).

This is not easy, but if your team trusts you and you show leadership, you can be on your way to building deeper on-line communities in a matter of months. I'd love to hear your experiences.

No comments: