Tuesday, February 1, 2011

When Do You Weed Your Community Garden?

Anyone who has ever grown anything in their home garden knows that at some point or another, the onerous task of weeding will become a part of your reality. The question usually becomes when to take on the task that most of us don’t look forward to.


In recent discussions with colleagues and customers, I’ve revisited my list of traits that a good community manager should have – and I’d like to amend the list to include ‘community gardener.’ The gist of these discussions has been how much influence a community manager should exert and where in the process of the community workflow that needs to happen.

Let’s face it – to have an effective community (one that provides value for both the producers and consumers of content), there is a certain amount of ‘weeding’ that has to happen, whether by the community itself, or by the community manager. This task can either be relatively painless or a pain-filled experience, depending on where in the process it occurs.

In general, I see weeding happening in one of two places (and please excuse the engineering mentality here): on the front end or on the back end. On the front end, this means putting a lightweight governance model in place to prevent a raft of ‘test,’ ‘me too,’ or duplicate content (or in the case of communities I usually run, projects). While possibly stifling the producers, this allows for a better experience for consumers who come to your community looking for content that is valuable to them. The converse is to allow a Wild West mentality of ‘anything goes’ on the front end, and then attempt to weed out the unproductive content on the back end through community voting/affinity, or active pruning by the community itself or by their community manager.

My personal belief is that, for most productive development communities, you should perform this weeding activity on the front end of the process. While this can be seen as a bit too restrictive by people looking to produce good content quickly, I think it tends to work better for early-stage communities where you don’t have a critical mass of valuable content. Perception is huge in communities, especially newly formed ones where you’ll tend to have more consumers than producers. If you’ve chosen to do the weeding on the back end, you run the risk that your community will appear very chaotic and unorganized to those coming to it in an attempt to consume knowledge, code, etc. Given that, in my career, I’ve primarily run communities in enterprise & government settings, I realize the importance of first impressions for people who may not be as intimately involved or passionate about a particular piece of technology. If these people come to a site where the weeding is put off until the back end, the likelihood is they’ll go away with a bad taste in their mouth from this particular community effort, since they’ll primarily see duplicate or ‘I’m testing this’ kinds of content.

Additionally, weeding on the front end lets you identify the issues mentioned above with the content/projects while they are still small. If you wait until the back end of the process, you’re more than likely dealing with a greater quantity of larger weeds, and I don’t know about you, but I’ve always preferred to nip problems and weeds in the bud, as it at least makes the task manageable. Choosing an up-front approach also lets you create a fairly lightweight governance model where you can quickly vet new content and then let producers go on their way to helping you build a great community.

I’ve stated my personal preference here, but I’m curious as to what readers of this blog think. Does anyone out there have ‘war stories’ about how (and where in the process) you weeded your community garden?

Hey, Your Community Peanut Butter Is in My Agile Chocolate!

Ever since my first introduction to Agile software development (at the beginning of the Forge.mil project nearly two years ago), I've been noodling with the notion of how my primary role (Community Management) interfaces with and informs Agile. At first, it almost seemed like the beginning of the old Reese's ® Peanut Butter Cup commercial ('Hey, your community is in my Agile!'), but as I've had time to consider it, I think that community has a lot to do with the successful application of Agile methodologies.


The culmination of this came when I was asked to speak on a panel at the recent AFEI DoD Agile conference, and the panel moderator asked us in our pre-show meeting to consider a 'lead-in' question he could give each of us in case the audience didn't have ready-made questions. I chose to have him ask me, 'How does the notion of community inform Agile software development?' In preparing my answer, I thought of three specific areas where I think this occurs:

  • Meritocracy

  • Peer Review/Customer Involvement

  • 'Fast Failure'

Meritocracy, most evident in successful Open Source projects such as Linux, Apache, and Subversion is the notion that your standing in the project has everything to do with the quality of your contributions. This is the engine that keeps innovation happening in these kinds of projects, and its application to Agile is often a tough lesson that can have huge human resources implications. People used to having their ideas heard in a traditional project setting are sometimes upset by the notion that 'junior' members of the team are on the same footing in terms of their contributions. This is especially true in more conservative and 'command & control' cultures like government; however, if your project can get past the initial hurdles presented here (and you have good HR people to smooth over any rough spots), group productivity can increase dramatically.

A core tenet of good development communities is also the notion of customer involvement and peer review. This is really one of the most obvious fits between community and Agile, where the notion of a 'Product Owner' as an involved part of the Agile team is a key component of the methodology. In good Open Source development efforts (even ones that aren't Agile), peer review helps find problems before they become large issues - the same function as it serves in an Agile project. Concepts in Agile & Scrum such as the retrospective meeting at the end of a sprint mirror the more informal peer review that happens on open source projects' community mailing lists.

Open Source communities live by the adage, 'Release early, release often.' This leads to an ability for 'fast failure,' which is also present in the Agile model. Because of the continuous feedback loops built into both systems, there is less of a paralyzing fear of something going wrong. To be sure, due diligence has to occur during release cycles, but with the knowledge that a quickly forthcoming future release can fix any issue comes the freedom to think outside of the box and try innovative approaches.

So, what does all this mean in the long run for your business and development efforts? Quite simply, don't ignore the community component of Agile development when your organization starts down the Agile path. Do your project members think the transition to Agile is the latest fad, or do they feel empowered to help improve the development process (meritocracy)? Have you gotten buy-in from your customer (internal or external) to support making this a community-focused effort (customer involvement)? Have you truly communicated to your teams that 'failure' in one release cycle is ok as long as future releases address the issue?

If you think about incorporating true community aspects into your transition to Agile, then, like peanut butter and chocolate in a peanut butter cup, your efforts will come together to provide a unique whole that is greater than the sum of the parts.

[Photo credit: Candycritic.org]