2014-04-07

Enterprise collaboration tools (e.g. Jabber and Sharepoint) are being increasingly implemented in companies, helping employees communicate and collaborate in new ways. However, experts report low adoption rates of these tools and delayed improvements to collaboration, which is creating a new set of challenges for project managers.

Uneven adoption leads to mixed environments in which team members come to the table using a variety of communication tools and practices—quite a different reality from the streamlined collaboration environments these tools were intended to create.

In light of these challenges, we set out to identify three unexpected hacks on collaboration tools that project managers can use to improve adoption and facilitate greater collaboration among team members. While these hacks include both technical solutions and low-tech disruptions, they’re all easily replicable ways to improve your team’s workflow while saving time and money in the process.

Jabber: Open-Source Scripts Pull External Data Into Chat

Web strategy and technology company Phase2 has staff teams distributed in San Francisco, New York and many other cities, and they all use the open source instant messaging tool Jabber to communicate. To improve collaboration between teams, Phase2 wanted to customize Jabber to allow team members to pull client issues and tasks directly from their project tracking platform, JIRA, to include in chats.

Phase2 maintains a company wiki that contains information relevant to project teams and clients, which it also wanted users to be able to easily pull information from into chat rooms. At the same time, the company wanted to avoid exposing users to irrelevant parts of the wiki or JIRA that would be confusing or overwhelming.

To do this, Phase2’s in-house developers created a customized installation by joining Jabber to a bot called Hubot from Github. An open source “robot,” Hubot contains a series of automated scripts that can be modified to perform certain actions. These actions include pulling information from other programs when a user types certain commands into a chat box.

An illustration of Github’s Hubot

Phase2 named their Hubot customization Treehousebot. In the beginning, they programmed it to make simple improvements in Jabber, such as accessing the company’s karma system, where users can reward points to each other when they engage in group chats in Jabber.

Karen Borchert is Phase2’s executive vice president of strategy, and has written on hacking tools for collaboration. With Treehousebot, she says, the karma system is programmed to respond with a user’s karma stats when certain commands are typed into the chat bar field.

“If you type someone’s name and then type ‘++,’ the bot will respond with, ‘Karen’s karma is on the rise…karma 39.’ It’s a really fun, nice way to deliver positive feedback that’s not weird and artificial,” she explains.

In the next stage of Treehousebot, based on feature requests from project managers and team members, developers expanded the bot so that Phase2’s team members could request project information from JIRA and the wiki simply by entering certain commands in the Jabber chat box addressed to Treehousebot.

In the screenshot below, for example, users can enter: “treehousebot: wiki me vacation policy,” and the bot will retrieve the appropriate information from the company wiki pertaining to Phase2’s vacation policy. This information is displayed in the chat as one or more URLs.

With Treehousebot, users can request information from external sources directly in Jabber chat rooms

Treehousebot has thus helped transform Jabber into a robust tool that can be used to facilitate communication both internally and between clients and project teams—Phase2 has specific chat rooms it shares with clients to keep them informed on projects.

For other companies looking to customize their collaboration tools, Borchert recommends using existing technologies (whether open source or proprietary) to save time and expense. “Sometimes organizations will try to build something that will work for their organization, when actually an existing tool will do 90 percent of what you need,” she says.

In terms of efficiency, it’s also key to recognize your developers as a key resource for in-house hacks. McMurray estimates that the total time spent by developers to create Treehousebot was 50 hours or less—an amazingly small time investment for such a customized tool.

Sprintly: Treemap Visualization Provides View of User Stories

Now a front-end developer at OpenGov, Andrew Liebhen was working at a small startup in Boston when he created a new hack for the project management tool Sprintly. Liebhen and his fellow developers were frustrated with always having a huge backlog of business stakeholder “someday” user stories—the wish list clients create for features an application will “someday” have.

Because of how many “someday” user stories there were, the team had no way to view them all together. This made it difficult to determine which user stories were the most urgent, which were the most time-consuming and which could be accomplished within a reasonable time period.

The team needed this expansive project view (sometimes referred to as a 20,000 foot view) for their weekly retrospective meetings with business stakeholders, in which they needed to hash out which projects were highest priority.

“The combination of frustration in meetings plus thinking about what could be possible,” Liebhen says, is what led to the resulting hack.

In Sprintly, user stories are assigned a “size”—S, M, L, XL and ? (unknown)—according to their workload velocity, or how much time is needed to complete a programming sprint based on the estimated size of individual tasks within the user story.

To better illustrate user stories all at once, Liebhen realized he could use a treemap, a framework he had learned of while working as lead designer at GroupVisual.io, an agency focused on data visualization. The treemap framework can translate vast sets of items into mapped hierarchies while keeping each item visible, making it ideal for illustrating the sized user stories of Sprintly.

“Treemaps are a great way to see the overall size of how many things you have and the proportional sizes of those things,” Liebhen explains.

Liebhen copied the code from a previous Github integration of Sprintly called Scrumly, which was already built to work within Sprintly’s application. He then “hooked” the user stories to another application called Isotope, which used an algorithm to translate the sizes of the stories into pixels (e.g. small stories = 100px, medium stories = 200 px).

With the assistance of another developer on his team who helped clean up the code and write documentation, Liebhen was able to release his hack, called Grandstand. The Grandstand visualization allows you to view all user stories in Sprintly at once by collapsing and expanding tasks into relative sizes.

Having all stories on one screen also makes it much easier to discuss individual user stories that have added to the queue (e.g. from business stakeholders).

Liebhen’s team tested the tool in their retrospective meetings, and says it was met with much excitement by the project team. “People hadn’t ever really thought about their backlog, or their full slate of products, that way,” he says. “They’d always been stuck using the same size [user story] cards.”

Leibhen believes the benefits of Grandstand are greatest for smaller teams with a highly adaptable workflow, since the treemap view allows them to easily change course and decide whether to act on new stories in the queue.

Grandstand is also valuable for teams that have a close connection between business stakeholders and developers, he says, since it functions as a visual decision-making tool that can be used to decide what needs to get done first.

The Sprintly team was so excited about Liebhen’s work that they invited Liebhen to blog about the new visualization on its site, and Liebhen had the chance to speak on the phone with Joe Stumply, CEO about the future of Sprintly’s interface design.

Basecamp and Sharepoint: Email Rules Improve Communication

The first two hacks discussed here require a bit of technical know-how. But there are other, simpler hacks you can use to help people “get their feet wet” when it comes to using new tools.

Dennis McDonald, PhD, is a project manager and independent consultant who writes on collaboration and project management. Over the past decade, one of the biggest obstacles to adoption of collaboration tools that he’s witnessed is a continued reliance on email. “There are some people who just cannot, or who will not, let go of using email,” he says.

Rather than migrating to collaborative environments where multiple team members work on a shared deliverables in real-time (e.g. Google Docs) these holdouts often fail to access the most up-to-date technology, instead continuing to send their individual work via email, or in email file attachments.

McDonald once faced this issue when using Basecamp to work on a mixed team project. Team members were reluctant to communicate with one another directly in Basecamp using the platform’s message system, which meant he had to figure out a way around this.

McDonald realized that, instead of forcing team members to visit the Basecamp site, he could configure the way email notifications were sent in Basecamp’s administrative settings. This way, all messages sent in Basecamp were emailed to the team to keep members up-to-date on what was happening, even if they weren’t logged into the system. Users could reply directly to the email, and their response would be logged in Basecamp automatically.

Additionally, since each Basecamp email notification contains a “View this on Basecamp” link, users who received these notifications could immediately access the platform with a single click, which encouraged them to use the tool more.

While this hack only required McDonald to play around with the administrative features of Basecamp, rather than programming new code, it was a quick, simple way to reach users via their preferred communication tool and increase collaboration among team members.

A similar type of hack, McDonald says, can be used to encourage increased adoption of Microsoft Sharepoint. A platform similar to Basecamp, Sharepoint enables teams to collaborate by providing unique websites devoted to each project, where team members can access the relevant up-to-date version of any document or deliverable. These sites also contain social feeds and group discussions to enable team members to communicate about important project tasks in lieu of email.

For non (or reluctant) adopters of Sharepoint that prefer to use email, McDonald recommends using a hack that allows them to continue to use email for project communication, but with one key caveat: all documents and files must be uploaded and stored in Sharepoint—not included as email attachments.

With this hack, users would only be required access to the Sharepoint site of the project they’re currently working on (so they don’t have to navigate the entire interface), which they would use to store all necessary documents and files. If they needed to reference a document or file in an email, they would simply include the link to where it was housed on the Sharepoint site.

This approach, McDonald says, can be an effective way to slowly transition users who are balking at the idea of communicating solely within an online platform. “That may not sound like much, but if the organization is accustomed to using Sharepoint only to support intranet portals (and not collaboration), that can be a big step,” he explains.

McDonald stresses that groups often need an incremental change that taps into existing communication, such as email, to familiarize themselves before switching over entirely to a new tool. The benefit of this, he says, is that you don’t disrupt existing patterns of collaboration, and you build trust among team members by allowing them to continue using tools they’re comfortable with.

Rather than “forcing a unified strategy,” McDonald says project managers must evaluate which tools are most crucial to project completion, and focus on identifying ways that certain tools can work together—much like the conductor of an orchestra.

Show more