Here’s why collaboration software frustrates product development teams

By Tony Bibbs, President, GForge Group

Let’s face it: The collaboration and project management space offers a wide range of options and choices.

Today, solutions come in different flavors of SaaS, on-premises, or hybrid, all promising you that with just a few mouse clicks, they will have you collaborating better. The one attribute that most of them have in common is that they don’t offer the product development capabilities and features that you really need!

In fact, many of these solutions actually make collaboration worse. To help you navigate your options, let’s lift up the hood and explore many of the common problems with today’s collaboration solutions.

Too small or too big, won’t scale
Not all projects are created equal. Say that again: Not all projects are created equal.

You know that prototype you were so proud of? Let’s say that proof-of-concept you built, which only required a Git repo to store your work, now has your customer excited, and they want to turn that into a more polished product.

A more finished product requires a real team: project managers, engineers, and quality assurance. A more finished product also guarantees that you will need more than a Git repo like a wiki, back-office documents, and a ticketing system to plan, distribute, and track everyone’s work. Scaling up a project’s features should be just a few clicks of a mouse. Instead, many of today’s collaboration and project management platforms leave you with the headache of negotiating with a vendor to buy more seats and additional features.

This is where the tools start to run the team. What started out as only a ticketing solution soon includes a wiki, chat, and help desk, and the next thing you know, you are looking at a bunch of tools held together with duct tape and web hooks, none being the authoritative source of your precious project data.

Who’s working for whom
That question may sound absurd, but yes, we are asking that question with a straight face. Are your tools working for you or are you having to bend to their will? To illustrate, let’s start with something as basic as ticketing.

Tickets are the atomic unit of work by which things get done. All your planning, distribution, and tracking of work happens through tickets. In fact, most of your collaboration will be centered on the best ways to deliver the work outlined in a ticket. So why do so many systems get the most important, fundamental needs all wrong? Let’s answer that by identifying common shortcomings of many collaboration tools:

• Duplicate tickets  — When creating a ticket, should the system let you know that you may be submitting a duplicate? Furthermore, shouldn’t the system give you hints that maybe the problem or goal in a ticket has been addressed already on sites like StackOverflow?
• Batch updates  — Updating multiple tickets in a batch should be easy to do. Yet many systems either don’t allow for this or make this far more difficult than it should be.
• Imposing workflo w — Workflow can help teams stay on track and handle tasks in a consistent way. But your ticketing solution shouldn’t force a specific workflow on your team.
• Dependencies  — Dependencies between tickets is common. Solutions should make establishing blocking/non-blocking or parent-child dependencies easy and obvious.
• Spam  — Getting notifications that a ticket, sprint, epic, or milestone has been changed is great, but do you really have to get a separate email for each update? Solutions should provide the option of receiving daily digests.

Collaboration’s antipattern
Believe it or not, many collaboration solutions actually work against collaboration. To illustrate this point, let’s discuss two problems:

• Traditional model of pull requests (PRs) is broken.
• There’s more to collaboration than comments.

As for the subject of pull requests, what nobody seems to be discussing is the fact that most organizations have outgrown the traditional PR model. See, open-source projects are a unique animal and their needs can differ from the needs of businesses. How is that?

Today’s PR models create tickets for tickets. Let’s say you have a ticket instructing you to “Implement feature X.” Once you are done, you create a PR, a completely separate ticket, that says, “Review my code and merge if it is ready.” So now your team has to close out two tickets to complete “Feature X” and, worse yet, the code review comments live in the PR, not in the ticket. This proliferation of tickets for tickets creates unnecessary noise in your projects and flies in the face of traceability. So what’s the fix? To put it simply, less is more.

You already have a ticket to “Implement Feature X.” Your collaboration solution even allows you to associate your commits to the ticket. So why not rid yourself of the need to process a traditional PR and, instead, perform the code review and merge cycle in the ticket ? If a ticket, the most atomic unit of work, is how work gets done, then doesn’t it make sense to do all  of the work in the ticket? Performing PRs this way ensures that everything is in the ticket: the audit trail of changes, comments on the ticket, relevant documents, and now even the code and associated code reviews. The value of streamlining PRs in this way would immediately improve efficiency and traceability.

Now repeat after me: “Comments aren’t collaboration.” Don’t get me wrong, commenting on a ticket, wiki page, or document aids in collaboration, but it isn’t true collaboration. That’s why we’re seeing all sorts of chat solutions rushed to market. Chat conversations give concise context and often include references to key project artifacts (tasks, support tickets, documents). For those exact reasons, chat should be a foundational and well-connected component of any real collaboration solution, not an upsell.

They’re expensive
A common problem with many collaboration solutions is that their base functionality has a high price tag. And despite that high initial cost, they have a limited scope, implementing only a few well-thought-out features. Make no mistake, this is on purpose — vendors use this approach to get you to spend more money. They accomplish this in one of two ways:

• The vendor upsell  — In this scenario, every time you want a new feature, you have to buy a new product that requires you to negotiate a new contract while leaving you responsible for keeping them integrated.
• Marketplace ecosystem  — Some collaboration solutions get around their lack of features by offering a marketplace where you can purchase third-party solutions. This has the same problems as the vendor upsell, but now you also have to worry about fragile integrations between both vendors.

Finally, regardless of how you acquire the features that you need, the questions that you have to ask are: How do you move away from a collaboration system? Does your vendor(s) make project exports/imports easy? The short answer is no. Essentially, this is nothing short of good old vendor lock-in.

What’s irking you
It isn’t all doom and gloom when it comes to collaboration software, but a solution that is right for you now  may not be able to grow with you in the future. To that end, it’s important to understand where many of today’s systems fall short and make choices that balance where you are today and where you want to go. Do you have a collaboration solution driving you crazy? We’d love to hear the reason why your collaboration solution sucks.

This article was originally published on sister publication EEWeb.