Atlassian Confluence blogs atWikiConsulting.com

Atlassian is proud to announce the latest version of Confluence, the enterprise wiki. Confluence 2.6 offers user-friendly UI changes, including a new theme with a fresh look and feel. Additional new features include default content for spaces, template labels, official MySQL 5.0 support, PDF export of images and default bundling of the social bookmarking plugin.

Where to next?

• Complete release notes
• Download a fully functional evaluation
• Customers with active Maintenance agreements can upgrade free

• Comments Off

 
Want a view into how a global company uses a wiki as their intranet? Check out Jason Mawdsley's article Tools for Distributed Development, which reveals just that and more, including best practices.
 
Jason works at Macadamian Technologies, where Confluence has become a vital part of their everyday world. The wiki makes it easy and convenient for both team members and partners to interact with each other even though they're spread across the world. Here's a little excerpt of his article:

A wiki is a key tool for success with distributed resources. Not only will it answer your global partners' questions while you're asleep, it also shows your partners how you go about doing things. A wiki spreads your corporate values in open and subtle ways, showing your partners how you work. This helps your partners incorporate the values of your company into their decision-making process.

This inside look into Macadamian also details how important it is for each project to have its own homepage within the wiki, making information related to that project instantly visible and accessible to everyone. So visible, in fact, that a new employee only has to visit that page to learn all about the project.

• Comments Off

A commenter on a previous blog post asked how much use the Atlassian internal wiki gets. I have no idea if these statistics will be interesting to anyone, but somebody asked, right?

A bit of background first. Our internal Confluence instance has been running since late 2003, back when Atlassian had a staff count in the single digits. Since then we've pretty much doubled in size every year to our current total of around 125 staff. In that time we've amassed:

• 65 global spaces, 150 personal spaces.
• 106,600 revisions of 10,400 pages, by 176 unique authors, with 2300 comments.
• 3,000 blog posts by 130 unique authors with 5,700 comments.

In a totally meaningless comparison, that makes our wiki one tenth of one percent the size of Wikipedia. On the other hand, Wikipedia averages only slightly less than two pages for each registered user, so we're a lot busier per capita. :)

The average of ten edits per page seems a little low (Wikipedia averages 16). It might be more interesting to see a distribution graph, since many pages (timesheets and meeting minutes, for example) will 'settle' quickly and are unlikely to see much editing, while at the other end of the scale there are a couple of pages that are updated every day (or even every hour) by automated scripts.

The "busiest" space is our support space, which has 270 pages, but 20,000 edits. In contrast, most personal spaces average two or three edits per page, perhaps reflecting their less collaborative nature.

Most of the 3,000 blog posts have been made in the last year. Blogging only really took off inside Atlassian when we added personal spaces to Confluence mid-2006. By way of contrast, the top ten spaces by page count are all "global spaces", while nine of the top ten spaces by blog-post count are personal.

The most prolific blogger inside the company is me, with 200 posts (and 453 comments) in my personal space. Four spaces have more than 100 posts, 16 more than 50, and 78 have at least ten blog posts. Not a bad participation rate, given half the company wasn't even here a year ago.

(This data was gathered using the Global Statistics Plugin)

• Comments Off

I got asked this question during a presentation earlier this week. It’s a simple question with a complicated answer - here’s why: Historically, whenever any new enterprise tool has appeared on the landscape, its proponents have told everyone that it was the next big thing (think KM systems) and would obsolete everything else so they should get on board as quickly as possible. Every time, without fail, this has not been the case. KM has largely not lived up to the extremely high bar set in its heady early days.

So when I answered the question, here’s what I said: in some cases it will replace and obsolete other enterprise tools, but in other cases it will coexist and work alongside - even in complement with - those other tools. Think that was a politician’s answer? In some ways it was, because it I said the same thing that’s been said countless times before - that it would unilaterally obsolete other tools - I would have immediately discredited myself because people know that’s not true and get scared when there hear things about a wholesale switch from one way of doing things to another.

In another way, it wasn’t a politician’s answer, because multiple tools can coexist and letting people choose can help them be more productive and enjoy what they do. Furthermore, when you introduce the wiki to your organization, there’s no need to immediately shut down and remove all other tools - that just sends a jarring and bad signal when the real benefit of the wiki is it helps return other tools, like email, to their optimal uses. Here are two examples where the wiki can coexist with other tools for the better:

Wiki + Email:
If you’ve been emailing meeting agendas, put them on the wiki instead and you’ll reduce the volume of emails asking you to do time consuming things like fix or add to agenda items. Instead, put the agenda on the wiki so others on your team can directly make changes themselves, then send out an email with a link to the agenda-containing wiki page. You’ve just reduced the email associated with that meeting to just one outgoing message, and the reduced volume means less work for you and people will likely pay closer attention to it since their inboxes will be less crowded.

Wiki + Website content management system:
Many firms use a content management system to power their websites, and the system is usually managed by one person, or a small team of people. The rub: they’re constantly overloaded with requests to edit the content of pages and have a difficult time keeping up with them in a timely fashion. A great way to solve this is to put the website content in a wiki space, with a wiki page corresponding to each page on the website. Now, people can edit the content on the wiki as needed, and just let the web publishing people know when it’s ready to go on the website. This reduces the web publishers’ workload from making lots of changes (which often requires emails back and forth to get content, ask for clarifications, etc.) to just copying the updated content over to the content management system.

• Comments Off

Over on the FastForward Blog, Bill Ives writes about some excellent ways to introduce wikis in organizations. He focuses on events and meetings - specifically holding asynchronous meetings on the wiki: "You should also encourage participants to sign their contributions, In a live meeting this is obviously part of the give and take. People need to know the personal context of remarks and who they are responding to." That's a great reason for explaining the value of associating your identity with your contributions. In a real-life meeting you'd have a tough time offering an anonymous comment on something, and even if you did try something outregeous like putting a paper bag over your head to feign anonymity, people eould still know who's talking! People do need to know who they're talking with so they can offer responses that are in the right context to have the best impact.

Bill makes a great point regarding the need to follow what's happening when they're not on the wiki: "allow this to go somewhere besides the email inbox. I am not excited when a heated discussion on an email group suddenly drops twenty messages in my inbox. Take advantage of the common workspace here and do not drag in the sins of email spaghetti with its overlapping tangled mess." If we switch to the wiki on the premise that it's better, simpler, less tangled, and overwhelming than an inbox full of email, why would we want to take two steps back and fill our inbox with the same overload of messages, just generated by a different source? I'm a firm believer that to really build a tight-knit community on the wiki, you have to be on the wiki itself and regularly, frequently contribute. Contributing a few times and then stepping back and just following from a feed limits the impact of the wiki. That's not to say using a feed is bad and should be discouraged - just don't let it be the only way you see what's happening on the wiki. Being on the page itself lowers the barrier to contributing, since you can just click "edit" whenever you want to add or change something.

• Comments Off

Here's another one from my meetings this week: a couple of people asked me about how to contribute to a wiki without looking stupid. This is a question I get quite often when meeting with organizations to talk wiki adoption. Some people will say that the biggest obstacle keeping them from participating on the wiki is fear of breaking it, looking stupid, or doing something wrong.

My take: If you’re silent, you’re not interesting. When you talk, even if you say something controversial or seemingly "stupid", you’re much more interesting. Also, what you think sounds stupid might sound brilliant to someone else. Bear in mind that pop culture and the media tend to quickly pass judgment on things people say, whereas within an organization people are likely to take a different approach and pay closer attention to what people they work with have to say because it has value to them.

Regarding the notion of doing something wrong, Peter Himler recently blogged about IBM distinguished engineer Mike Moran’s new book Do It Wrong Quickly, and Himler says of the book, “He turns the old "plan then execute" mindset on its ear, favoring a non-stop cycle of refinement where failure (or "doing it wrong") is a necessary and accepted step on the road to marketing nirvana. I mean in the old marketing paradigm, one can spend beaucoup bucks and still see a campaign fall flat. Whereas on the Web, if the messages don't mesh, pull 'em down and try something else til you get it right. Makes sense.”

Himler happens to be applying this to marketing, but the idea applies to everything, including collaboration. Trying to massively plan something and then expect it to be successful is more risky in my opinion than applying a flexible, iterative approach and making smaller mistakes along the way. In fact, the even bigger risk is that with the old approach the people whose reputations are staked on its success will do whatever it takes to appear successful.

I once worked at a firm that invested $100K in a content management system and to justify the expense they had to demonstrate that a certain number of new groups were using it every six months. So the group in charge of getting teams to use the system signed teams up for spaces that they never used (in fact, they’d even tell the people that they were signing up that they didn’t have to use the spaces (no one in senior IT leadership ever actually looked at the content - they just wanted to see a higher number each time they checked!)

• Comments Off

I love Wikipedia. Not due to its contents, but due to the way it helps me explain my work. You see, whenever I tell people that I work for a company that makes a wiki, I only get a blank stare in return. But when I explain that it's like Wikipedia, their eyes light up and they instantly understand.
 
However, Wikipedia is not the real world.
 
I've learned this from my time working at Atlassian, where using our enterprise wiki is standard behaviour. We store our corporate knowledge on the wiki, host discussions on the wiki, share our personal joys and frustrations on the wiki. However, Wikipiedia is not the real world. Allow me to explain...
 
"It'll be vandalised!"
This is the first thing people say when they conceive of a wiki within the enterprise. However, it simply isn't the case, for several reasons:

• All edits are tracked by name and date — simply turn off anonymous access!
• The content is written by fellow staff members so it's less likely people will want to offend
• Politics, religion and sport are rarely the topic of enterprise wikis, so people aren't driven to vandalism due to emotional reasons

"I don't want people editing whatever they want!"
Our internal wiki at Atlassian can be edited by anyone in the company, with the only exception being the staff HR policy pages. Strangely enough, however, I have noticed that very few people update another person's pages even though they have the ability and social permission to do so. Instead, the practice has arisen to add comments to pages rather than edit.

I'm not sure why this is — perhaps people think that editing is tantamount to trespass. Perhaps it's because opinion is not fact, so they'd rather add their opinion as a comment or suggestion, and let the original author update the page as appropriate. Nonetheless, it suggests that Wikipedia is not the real world.

"A wiki is fine for reference material, but not for communication"
Not so. Communication is alive and well thanks to Confluence's News and Comments capabilities.

News is like posting your own blog — readers can even subscribe via an RSS feed. Within Atlassian, we use News to inform staff about upcoming events, discuss product features and swap interesting stories. Unlike e-mail, the News is kept on the wiki, available for future reference and commenting.

Comments are, indeed, the currency of the Internet. Amazon's product reviews are a perfect example. It's a way people can contribute to existing information. Our public documentation for Confluence is another example. People can not only read the documentation, they can comment on it.

The ability to comment on pages can also be found on Wikipedia, but it is hidden behind Wikipedia's Discussions tab. It's just one big page that people can edit, which makes it hard to follow the flow of conversation. Comments in Confluence, however, show who said what and when, and even includes a picture of the contributor.

"I don't want people wasting their time posting silly information"
Welcome to the world of Knowledge Management. It's only by encouraging staff to post information that knowledge is built and maintained. People aren't your most important asset — their knowledge is! Are you capturing your knowledge, or is it walking out the door each night?

"My staff would never use a wiki!"
You'll never know unless you try. People aren't paid to use Wikipdeia, but they still use it. Maybe you just need ways to encourage wiki adoption.
 
Just remember — Wikipedia is not the real world. But it is close. :)
 
References:

• Your wiki isn't Wikipedia (wikipatterns.com)
• Corporate Wiki Usage? on LiveJournal
  
  
  • Comments Off

At one of my visits this week, I was asked about what to do when your wiki has got too many contributions or comments from one group. How can you balance that by getting other groups to contribute as well? Email and invite them to comment. Explain the case - just say “Hey, most of the comments & edits are from others. Would you mind adding some of your thoughts too?" People respond well to invitations like this. If you’re asking a less tech-savvy group to contribute (which is more often the case; the early adopters are the ones dominating and others are not contributing as much because they're probably feeling like they might look stupid to their more tech-savvy colleagues), remind them that it’s ok to start simple and ignore things like including images or using wiki markup,and anything other than simply adding or editing text. Once they get comfortable with text, it’s easy to add skills, but the key is getting the comfort level in place first.

• Comments Off

The last one is technically true, as I’m part German by family heritage. But on to more serious things: I’m in London this week, Germany on Thursday, and France next week to meet with people deploying and working to grow enterprise wiki use in their organizations, see how they’re doing so, the issues they face, strategies they’re applying and help guide their wiki adoption. I’ll be posting throughout the next two weeks about the types of organizations I’m visiting, my observations on wiki adoption, and ideas & strategies that you can apply to your own wiki. I hope you find this useful - feel free to leave me comments about your own wiki adoption, what works & what doesn’t, and your ideas & strategies.

• Comments Off

Nathan Wallace of Janssen-Cilag has written an excellent case study on their wiki adoption, which Bill Ives picked up on the FastForward Blog. Janssen-Cilag is a pharmaceutical research company with employees in Australia and New Zealand, and is one of 250 operating companies of Johnson & Johnson, the New Jersey-based maker of pharmaceutical, medical, and personal hygiene products. The case study is very comprehensive — one of the best written and most information–rich case studies I've seen yet, and Bill's post is well worth a read as well as he pulls out some of the salient points.

Here's what I commented to Bill on his post: “They needed a system where editing is immediate and very simple. It was more important to let people add content rather than worrying about what they shouldn’t do.”

So true - it’s good to hear that an organization is concentrating on the positive and taking an optimistic approach instead of wringing its hands over thoughts of bad things happening.

“…”Knowledge management, previously a big concern, has moved off the agenda for the time being.” That is because knowledge management became a byproduct of using the wiki and not a separate activity.”

Great point - true knowledge management happens when people are able to do it without fighting with the technology and seeing it as a separate activity. It scares me to think of how many organizations have ended up treating it as an after-the-fact burden b/c the tools haven’t made it easy.

This is a great case study - Nathan deserves a lot of credit both for what he’s doing with wikis at Janssen-Cilag, and for sharing this really comprehensive, detailed case study with us all. Bill, thanks for your added input as well!

• Comments Off