There is a LOT of effort being spent by the United States government to increase transparency to the taxpayers. In general, there are some great efforts (such as data.gov and usa.gov), and I think we should continue pushing the edge of the envelope in citizen participation with government. However, I believe we have a MUCH bigger problem to solve to get us to 'Government 2.0' - encouraging/cajoling government agencies into collaborating amongst themselves first. Impossible you say? Maybe so, but without effort focused on this goal, no amount of external transparency will have lasting success. Is there a magic formula or tool to accomplish this?

Short answer: No. More detailed answer: No, but proper application of tools such as wikis, discussion forums, centralized document management, application lifecycle methodology, and social media features can provide a way forward. However, the key critical aspect at the end of the day is community (yes, why should this be a surprise, coming from the community management consultant? :)). Without an approach that factors in how the internal cultures and communities operate within the government, any hope of meaningful citizen participation is pretty much non-existent.

The recently announced Open Government Directive is the 'stick' being used to drive intra-agency collaborative efforts (as well as external transparency). However, most of the time, applying only the stick results in a 'checkbox' approach to any task - doing the bare minimum. Lena Trudeau hits the nail on the head in her recent blog post at Federal Computer Week when she writes:

"Collaboration is a path to achieving results. Rather than focusing on simply achieving compliance with the Open Government Directive by checking the box on collaboration, agencies have a great opportunity to identify a real problem and use collaboration to solve it."

Given that humans are not naturally altruistic, my oft-stated commentary on WIIFM also applies here - do agencies who agree to share data/technology and cooperate get bigger budgets, bonuses, or some other form of prestige by doing the right thing by the new Open Government Directive? It would be great if they did these things because it was better for the average citizen, but that's unlikely to happen. Identifying a tangible problem to solve, as well as what's in it for the respective agencies, can help provide the 'carrot' to help mitigate the sometimes detrimental effects of the 'stick'.

Without fostering 'communication' (read: community) among the various agencies, any chance of producing coherent and reasonable transparency to the taxpayers on the outside of the system is doomed to failure. I've often wondered if we are close to a tipping point in terms of government employees who grew up in a more 'collaborative' time, with the internet, open source, social media, and the ease of working with each other. Will the rigidity sometimes foisted upon (or required of) new 'govies' quash their innate desire to collaborate effectively?

One way to address this is to change the way problems are thought of and how people are incentivized to solve them. We need more people like Vivek Kundra (USA CIO) and General Jeffrey Sorenson (US Army CIO) (both fellow Fed 100 award winners for 2010) to sponsor projects like Apps for Democracy and Apps for Army, which, through small changes, start to tear chinks out of the traditional way that 'app development' and collaboration are thought of, both inside and outside of the government. They also start to encourage a level of cross-collaboration that fundamentally changes the way people within government talk to each other.

Focusing on cultural changes is something Andrea DeMaio commented on in a recent blog post on the Gartner Blog Network about how technology has become too much of the focus in Government 2.0:

"...it has always been easier to say 'let’s buy a new tool' than to reflect about deeper process and cultural changes. Finally, on a topic that is new to most people, with boundaries that are quite unclear, it is easier and somewhat more comfortable to be able to point to a new tool or a new functionality, something distinct from what one has been doing so far, as a way to tick a box in a compliance exercise."

Can we all see a theme here on the 'compliance exercise' bit? I agree with all of his points (even grudgingly realizing that there needs to be some strategic direction change not coming from the technologists). Honestly, I think we need to look to successful open source projects and their use of community, meritocracy, and cultural models that are largely tool agnostic (though some would argue that distributed vs. centralized version control is a holy war!) Successful open source and/or Agile development communities exhibit characteristics that generally encourage and reward internal collaboration and involvement of all stakeholders in the process (outside users are represented by requests for enhancements and community leaders)

All of this causes me to wonder - given the rise of the 'social media/collaborative' generation, how long do you think it will be before this 'new breed' starts to influence the way government interacts with itself? More importantly, will the government culture remain long after the current generation of govvies is gone, and will that get in the way of the new generation, or flat out discourage them from entering public service in the first place? If we hope to achieve even half of what we are being promised in a 'Gov2.0 Nirvana', we are going to have to solve the 'internal government 2.0' puzzle first. I'm very curious as to what you, the readers, think is necessary to spur the move to 'Government 2.0' within federal agencies. Please feel free to leave me your thoughts here...

By now, I'm sure most readers of this blog have seen the announcement of CollabNet's acquisition of Danube Technologies, Inc. Our CEO, Bill Portelli, posted a blog entry here yesterday addressing the strategic reasons behind the acquisition, but I wanted to write a note to welcome Danube into the CollabNet team, and talk a little bit about how I think they will make our services offerings stronger.

In its coverage of the announcement, Forrester Research penned a great blog post with a lot of details of why they think this is a key acquisition in the Agile ALM space. While there will be forthcoming discussions of how the CollabNet TeamForge and ScrumWorks products will be integrated, I'd like to focus on another area that Forrester called out in their blog:

"One of Collabnet’s largest implementations is the Forge.mil site which provides a community oriented development space for defense projects to share development assets. Increasingly these projects are looking to adopt Agile methods, but in a controlled and distributed way. The result of Collabnet’s acquisition of Danube is a large amount of Scrum best practice [which] will slowly percolate into this community."

This is a key and fundamental strength this acquisition brings to the CollabNet services portfolio. Danube has an awesome array of talented Scrum Trainers and consultants that will be able to bring solid experience in explaining the details of how to take advantage of all that Agile development has to offer. Where I'm most excited is in how that combination of 'how to do Agile' intersects with CollabNet's own community management consulting practice. A lot of what we do in the community consulting area is about explaining the 'why' of new methodologies such as Agile. Having our new Danube colleagues on board to help us deep dive into the 'how' of Agile will undoubtedly help us as we start to engage additional teams both within and outside of the DoD.

Forrester is absolutely correct that in the DoD space, the move to Agile is all about doing this in a controlled manner that makes sense. There is a long established culture in the department that doesn't exactly embrace this 'new-fangled' way of doing things. Thankfully, the experience of building out Forge.mil has proven that amazing things can happen (180 days to launch initial revision of software.forge.mil) if you apply Agile principles to new projects in the DoD space. With that being said, we've had to build out a 'hybrid-Agile' approach in this space, to account for certain 'back-end' processes like Change Control Boards (CCBs), but we are still moving the department forward and saving taxpayer money in the form of reduced redundant efforts.

I look forward to working with my new colleagues in the services space, and would love to hear from any readers on what kinds of things you'd like to see the combined talents of the community consultants and Scrum Trainers take on. Hopefully, we'll be able to integrate the Danube blogs into this space soon so that we can continue to drive these discussions forward...

Change is hard.

That statement should not come as a shock to anyone who has ever worked anywhere in the business world, or even just lived on planet earth for that matter. However, change is a critical element to moving the collective knowledge of our species forward. Without change, we wouldn't be walking upright, let alone using a netbook to write blog posts from 35,000 feet in the air (yes, I'm composing this missive from seat 8F on Virgin America flight 84 to Washington, DC).

One of the ways many organizations try to deal with change is by bringing in new 'tools'. I work for a company whose primary 'product' is just such a tool (CollabNet TeamForge), but we also offer consulting services around Community Management, Agile development, and process change.

I may be biased here (since I'm in the services group), but I'd argue that the services offerings are the most critical component to the successful deployment of our product. One of the main reasons for this is that it's often easier for an 'outsider' to help companies, or, in my case, government agencies, shift their processes from slow, antiquated, heavyweight affairs to streamlined, agile, community-based approaches that take maximum advantage of the tools. We also provide a critical eye toward making sure that the change-phobic people involved in the transition don't try the 'new wine in old wineskins' trick.

Any historical or biblical scholar can recount the parable of putting new wine into old wineskins, but the short version is that putting new wine (tools) into old wineskins (processes) is a recipe for disaster/bursting, because the old processes are inflexible, brittle, and unstretchy (kudos to CollabNet CTO Jack Repenning for this correction of my original thought process). This is especially true if the transition effort is driven by a top-down edict that ignores the needs of the community. My community management colleague on the Forge.mil project, retired Army Lt. Colonel Susan Grosenheider, calls this the 'mandatory fun' approach, and she has first-hand knowledge of how well that goes over in the Army (hint: not well). At the end of the day, if you've deployed a new tool, but still have your broken processes wrapped in a shiny new package, you have a situation that my CollabNet colleague Drew Showers calls 'A fool with a tool is just a fast fool.'

One of the most rewarding, yet challenging jobs that Community Managers face is walking the fine line between the needs and desires of the business community, and the needs of the developers and/or users. There are times when you have to say no to one group or the other, but having someone who can step into the breach between different members of the community is extremely important to the success of any tools deployment, and pays off in the long run.

While businesses should strive to build up their own community 'champions', having a consultant who isn't tainted by the existing process makes it easier to find a way forward that isn't just 'change for the sake of change'. A good consultant also helps you avoid a culture of 'mandatory fun' which helps prevent the process 'bursting' problem, and ultimately leads to a better return on investment for the tool set you're deploying to help streamline your business or development process.

It's amazing how restricting the amount of space you have to express a concept crystalizes what is truly important about that idea. Recently, in my 'community' Twitter list, Holly Seddon asked a very good question which helped give me one of those 'A-ha' moments:

'In one word, what should using an online community feel like or give you?'

I loved the challenge of coming up with a single word to describe a key benefit to participating in community. After some reflection, the word that popped into my head was 'perspective'. When communities are functioning at their peak (and I think this is true even of 'development' communities), one of the most powerful things you can glean from your participation is the perspective of one or more of the other community members.

Being able to look at business problems, source code issues, or any other medium within a community from a different angle is incredibly powerful. As an engineer, I used to get some of my most inspired ideas from listening and reading what others in discussion forums were posting. If you have a specific problem, a direct approach to soliciting help from your community gives you (sometimes) multiple different ideas & perspectives on your issue. Throwing these thoughts into the mix as you work toward a solution can be an invaluable step in the problem solving process.

There are a lot of reasons why people or companies start communities, but I believe a large portion of those reasons can be traced back to the need to get additional different perspectives - developers looking for ideas, companies looking for consumer input, social groups looking to connect with other like-minded individuals. I'll admit that not everyone in the corporate world always understands this - mainly because asking for and reflecting on a different perspective requires the kind of humility that some companies (and even some governments) don't always possess.

We've all participated in groups where we've felt our opinions didn't matter, and I'm willing to bet you probably disengaged pretty quickly if that's the experience you encountered. I urge companies and their individual employees to strongly consider this when setting up your own internal or external communities. Ask yourself the question: 'Is this a place where I'd want to participate - is my perspective going to be welcomed and celebrated?'. If the answer is 'no', it's time to go back to the drawing board in the plans for building out that community. If you are already participating in a well-oiled community, remember to appreciate the different perspectives you get - even the ones you might not necessarily agree with. :)

It has been quite a while since I've blogged specifically about Forge.mil and what we've been up to as a team. My silence here in the blog has nothing to do with a lack of things to talk about - it's actually quite the opposite. There's been a ton of work going on, and some interesting achievements/recognition given to the project team. I'll summarize below & share some pictorial highlights as well.

Achievements

• Information Week 500 - 'Government Innovators Award'
• Government Computer News Honorable Mention for 'Great dot-gov Web Sites 2009'
• Featured Article in 'Whose Who in DISA'

Progress

• Multiple outreach presentation efforts, including Potomac Gov 2.0 Summit and GOSCON
• Software.forge.mil migrated to DoD production data center
• Project.forge.mil system operational in production data center (still sorting out costing models)
• Initial integration planning/prototyping for certification.forge.mil

While these four bullets may not look like much, they've monopolized the majority of the team's time in terms of paperwork, accreditations, and working with the many other teams involved to get us to this point. A lot of good and hard work went on, and we are excited to see some of the additional capabilities starting to take shape.

Future Directions/What's Next

One of the things I want to reiterate (after hearing some comments at GOSCON that indicated a lack of understanding) is that unlike a lot of other systems in DoD, Forge.mil is not static - what it is today is not what it will be in the future. I heard several people say they couldn't see how forge.mil could be used because it doesn't have 'feature x'. My response: "Put in a request for feature X - the requirements aren't locked down in cement". This resulted in a confused look: "You mean the requirements weren't set months ago?" No, and that is an important piece of what we are trying to accomplish with ALL of the Forge.mil capabilities - an agility of development, test, certification, and deployment that let's the DoD field systems in a much more efficient fashion.

If you ask the Forge.mil project director what our executive sponsor (General Cartwright, Vice Chairman, Joint Chiefs of Staff) thinks is the most important aspect of Forge.mil, he'll tell you that it isn't delivering new tools just for the sake of wrapping up bad processes in new skins. General Cartwright wants to see Forge.mil push the edge of the comfort zone with regard to how software and systems development is currently done in the DoD. Our team at CollabNet is working hard to assist in making this a reality.

There are some exciting things the entire team is going to be working on here in Reston, VA for the next 2 1/2 days as we plan for Release 5 - tentatively scheduled for full rollout at the 2010 DISA partner conference in May 2010 - our overall theme is most likely going to be 'DoD Agile', and it will have to encompass both new features and cultural changes.

It should be an exciting and rewarding ride for the next few months - stay tuned for more details...

Chris Brogan once described a community manager as 'part party host, part fine restaurant host.' Part of what that role entails is understanding how to best form your community for success. The other part of that role is understanding how to be the perfect 'party mixer.'

In general, there are two primary camps in your successful software development community - developers and everyone else. Yes, I know, I'm simplifying this quite a bit as "everyone else" includes important folks like testers, project managers, business analysts, and other decision makers. The problems usually come because, in general, both communities have different definitions of what 'success' should be, and also how that goal should be achieved. This situation gets even more interesting if the software being developed is being used as a lever for cultural change (i.e. - moving from traditional waterfall software development approaches to something like Agile).

Being a party mixer in this kind of environment requires some unique skillsets, some of which I talked about in a previous post. You are playing the role of referee, but also coach/counselor, trying to make sure that each contingent's needs are met. A big part of the problem also arises out of the fact that sometimes the non-dev side of this community decides that what they say goes, and then the developers start to feel like they are the people at the party wearing the unfashionable clothes. Your goal as a community leader should be to reinforce the notion of meritocracy, and get everyone to come to the table.

So, what weapon in your community management arsenal is the best bet in this situation? The biggest single thing you can and should use in this situation is your WIIFM sense. These groups each have competing agendas - you need to know what these are, and find a way to bring something to the mix each group can claim as its own. Brent McConnell (Community Manager for Kablink) wrote a blog post recently titled 'What They Don't Teach Community Managers.' He had a great comment about listening:

"So how do you craft a message that resonates with your community? You listen. Listening is the key that unlocks not only the problems of your users but also their perspective."

There are several ways to do this, but I really like how Agile development can be used to satisfy the desire for both types of development personnel to be involved. As a former developer, I can tell you that clarity of requirements, look & feel, etc. is absolutely huge. It helps you deliver code that you can be proud of, and that you know will be used (because it meets the users' expectations). Having business owners/users involved in user story definition and refining small pieces of functionality during short iterations also gives them a feeling of empowerment, which lets them guide the direction of the project at a much more granular level. Most importantly, though, this constant interaction between the developers and non-developers provides a mechanism to allow a lot of listening (if guided properly).

As the community 'party host,' always remember that it is your job to provide the conduit for communication. It is not an accident that the words 'Community' and 'Communication' share the same root. True two-way interaction is the key to a successful community, project, or any collaborative effort. If you do a good job of 'hosting,' you and your constituents will have fun, and be fulfilled, which lead to more productivity all around.

There's a lot of work going on by various companies to build better 'listening posts' for the huge stream of social media that is flooding into companies and communities. There are a plethora of listening tools available, such as Radian6, Buzzlogic Insight, Sentiment Metrics, etc. More recently, Microsoft has gotten into the game with a project they call 'Looking Glass'.

While details are still sketchy, Looking Glass appears to hook into (and lock into) other Microsoft products, and even do some analysis of trends & stats to automate certain actions. At this point, I diverge from the popular opinion that social media stats, ROI, etc. are the end-all and be-all of the social media world. I've argued this point before, but I'd like to reiterate that all of the metrics gathered as part of social media/community really do require a person (be it a community manager or social media sherpa) who can perform the 'Information Synthesis' necessary to build an actionable plan in response to the flood of social media input. We even have a section in our recently released Community Management Cookbook related to this thought. To wit:

"Community health can NOT be determined by simple numbers. It takes a community manager, or several, to read through conversations."

For example, a community could have only a few members (relative to some 'mega-community'), but the conversation/engagement/work produced might dwarf the mega-community. Raw membership numbers might present a skewed picture in this case which could lead to a decision maker thinking they need to shut down a productive community. With the stats, plus analysis by a human, a more educated decision could be made in this case. By the way, there is always the risk of over analyzing the data, and I agree with Jack Repenning, CollabNet CTO, on this point. Providing both the raw metrics, and a reasoned analysis, is the best we can hope to do, but clearly, one without the other doesn't benefit anyone.

Once the analysis is combined with the numbers, the responsibility for a response to something in the social media stream can be farmed out to the necessary department or individual to deal with appropriately. However, the action item may be to adjust an internal process or business decision in reaction to the stimuli received from the social media feed.

There is enough inherent 'squishiness' in social media/community management that you really have to rely on the best social media analysis engine (the one between a talented person's ears) to make sense of what the metrics are saying. Trying to automate thinking in an attempt to scale the social media listening/response function is doomed to failure if your goal as a company/community is to actually do something useful with what the crowd is telling you, and to be perceived as an organization that understands how social media benefits you.

Bottom line - statistics are but one tool in the arsenal of an effective community/social media strategy.

We've recently published our CollabNet Community Management cookbook, and have had some good discussions already in the forums surrounding our attempt to give something back to the community (and yes, to showcase some thought leadership around community leading to consulting gigs). :)

One of the discussions that was happening was around 'next steps', or 'rollout plans' and the topic of community champions was raised. Fortunately, there is plenty of commentary/data out there around this subject. In fact, I recently read a great post by Rachel Happe (of the group Community Roundtable) on her version of champions, specifically 'Cheeseheads'. Now, for those readers not familiar with the National Football League, that name refers to the passionate (some might argue overly so) fans of the Green Bay Packers. These folks are some of the most loyal people you'll ever meet, and Rachel's point is it's crucial that you cultivate, nuture, and reward these 'cheeseheads' in your community. These are the kind of people that will make your life as a community leader either very hard or very easy.

As an example, when I was helping run a small skunkworks team at Sun Microsystems, we literally had to rely on the notion of 'Tom Sawyerism' (i.e. - getting folks to come alongside us as we attempted to do great things). Rachel's cheeseheads are people cut from the same cloth as those we found to turn projects from a small 3 person team into some of the largest successes in the company - projects like the JavaCar.

Now that I help companies try to run the same kinds of communities within and outside their organizations, the lessons of the past keep coming to the forefront - one of your primary jobs as a community manager/leader is to find these 'cheeseheads in the rough'. Easier said than done you say? Let me offer a few suggestions:

• Look for people not afraid to bend rules to get things done
• Find people with pain points that your community effort can solve
• Get people who want to make a name for themselves

While two out of these three qualities may seem incongruent with leadership, generally, people with those traits will be your staunchest allies if you are providing them an outlet or capability to solve their pain. Once you've found them, explain to them how the community you are building benefits them (WIIFM principle). Yes, you may have to 'sell' it a bit, but if you can find two or three people like this in a small community, who turn around, advocate your efforts *and* recruit new leaders, you'll be on your way to a healthy community ecosystem.

Always remember that your job as the community manager is partially like that of Tom Sawyer - find other people to come along and help paint your fence. Unlike Tom though, you aren't completely abdicating responsibility - you're there to help guide/coach/mentor your cheesheads. :)

With 'Government 2.0' receiving a disproportionate amount of coverage in the press lately (due in part to the new administration's focus on transparency - a good thing in my opinion), there have been a number of pundits who have asked, 'When will we know that we've reached Government 2.0, and how long is that going to take?'

I think that begs the question of exactly what constitutes Government 2.0, as well as sets an unrealistic expectation of a finite process that has a clear beginning and end. Clearly, any effort designed to fundamentally change within the Government such things as technology acquisition, transparency, or collaboration will not be a 'forklift revolution,' but an ongoing and constantly reviewed process. I think most intelligent and knowledgeable folks within government realize that successive approximations are the only realistic way to make this happen.

There has been good progress on some of these fronts (both for internal government & public collaboration) - notably data.gov, Intellipedia, A-Space, whitehouse.gov, and even Forge.mil. However, one of the recent approximations that I believe is critical to this effort has happened within the Department of Defense - a call to streamline the acquisition process for Information Technology. Currently, the IT acquisition process is the same one used for things like tanks and missiles, systems that require a large up-front investment in requirements analysis and a strict process to ensure they can perform the necessary mission before the 'crank is turned' and thousands of items are produced and delivered.

Software, as most of us know, doesn't operate that way, and in fact, needs to be able to adapt to changing technologies and requirements throughout the life cycle of deployed systems. The DoD will be fielding 10 systems in fiscal 2010 to be acquired under the new, more streamlined process, and if these are successful, there is a strong chance that the program could be expanded to add more systems in the future.

I should also note that there need to be approximations within approximations. I know this sounds silly, but the best example I can think of is cultural change in how IT and other software support systems are developed and fielded. A large change in the culture that we are attempting to engender with the Forge.mil effort is shared (and in many cases, 'open' within the DoD) collaboration. There are approximations within this cultural change effort aimed at getting people used to not developing in silos, looking for, and building reusable components, and accepting contributions from qualified members of the department outside of their immediate project team.

Once I fully realized the need for these approximations in my efforts as one of the Forge.mil community managers, it was easier to relax and treat this entire effort as a continuous process, not as a finite deliverable. I believe it is critical that the larger government community adopt this same approach as well - attempting to build out all parts of what Government 2.0 could or should be right away would be expensive, and doomed to a lackluster reception by those in the community who need it most. The new DoD acquisition plan seems to correctly recognize a need for 'course corrections' or 'approximations' as we move forward toward building a more participative technology infrastructure for government. I'm hopeful that it will become the model for other government agencies going forward - quite honestly, doing it any other way probably portends failure from both the technology and fiscal perspective.

Most people know the definition of a chameleon - but, true to my engineering roots, I'll take no chances and quote Wikipedia on the subject:

"Chameleons are people who can change their personality and appearance with ease, morphing into a seemingly different person..."

I think that is a great definition of what community management is all about. By the way, credit for planting the seed for this missive goes to my colleague Carey O'Brien - we were having a great discussion on the skill sets/personas needed to be an effective community manager, and we came up with the list below. Feel free to comment and suggest your own additions, since we might have missed your favorite. Community managers should be equal parts:

• Psychologist
• Coach
• Information Synthesizer
• Matchmaker
• Referee
• Customer Support Person
• Business Development Professional
• Karmic Leader
• Public Relations Guru
• UPDATE: Rabble-Rouser - credit to Jim Storer - see his comment below...

Amber Naslund recently wrote a great blog post entitled: 'Five Myths of Community Management,' which I think crystalizes the varying roles mentioned above in this statement:

Community Management is '...a different and evolving discipline that needs to adapt based on the needs of the business. And it does every community person a disservice to park them in the communications basket and leave them there.'

The fact is, you really DO have to be a community chameleon, playing one or more of these roles on a day-by-day, minute-by-minute basis. Yes, you can and should recruit community leaders to help, but ultimately, the buck stops with you as a community manager. Learning how and when to play each of these roles is not something that you can easily teach or write down - this is a skill you pick up by experience, mentoring, and by having a natural ability. There are plenty of people who are great managers of people that report to them, but those kinds of skills are not always as helpful when you are trying to influence and mold a community with choices as to who they'll follow.

What I also find interesting is that though there are common skill sets all community professionals seem to possess, there is a vast difference between running a developer community (my area of expertise), versus a primarily social community. For example, I'd be a horrible community manager for a site catering to fly fishermen. :) However, don't let a perceived requirement for deep domain expertise put you off to a potential community manager within or outside your ranks. Amber hits the nail on the head when she mentions evolution and adaptation - those traits are usually present in folks with the right 'curiosity bit' turned on. These kinds of individuals can quickly get up to speed and bring their own unique skills from the list above to bear on the community they are tasked to manage.

The variety in community management is one of the main things that makes it appealing (and challenging) for passionate people, and why determining success is sometimes very 'squishy'. You can have great metrics (# of members, # of forum posts, # of source code checkins (for dev communities)), but still have a horrible community. Conversely, you can have what would seem to be sub-standard metrics, but have a thriving ecosystem, because people are getting their needs met, which, in the end, is the ultimate definition of a successful community. Learning to accept a certain amount of uncertainty and being willing to 'change your spots' when necessary is critical for both people charged with building community, and the senior leadership asking them to do so.