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]