4 Reasons Why Collaboration Software Fails

For machine designers and developers, there is no shortage of different methods and approaches to collaboration. Today’s collaboration options all seem to focus on supporting the next great start-up or Fortune 500 company. For many of us working in the trenches of engineering and mechanical design and manufacturing, there is a huge gap between what we really need and what most collaboration solutions actually provide.

Worse yet, today’s options come in different flavors of software-as-a-service (SaaS), all promising that a few mouse clicks will have you collaborating better. The one attribute most of them share is that in helping us get things done, they fail us. In fact, some actually make collaboration worse. To help you navigate your options, let’s explore the four major reasons why collaboration is failing engineering professionals: 1. Ticketing: The Fundamental Problem 2. Pull Requests: Collaboration’s Antipattern 3. Chat Solutions: Do We Need Another One? 4. The Need for Commoditized Collaboration

Ticketing: The Fundamental Problem

Let’s start this discussion by asking one simple question: Who’s working for whom?

That question may sound absurd but, I am asking it with a straight face. Are your tools working for you or must you 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 need all wrong? Let’s answer that by identifying common shortcomings in two of the most popular ticketing methods.

GitHub issues. GitHub has been popular for collaboration for a long time, and it’s great. (GitHub is a subsidiary of Microsoft that provides Git, a software program for developing software collaboratively.) It’s easy to get started, especially for one-person projects where it really helps keep things organized. But as you add team members, competing priorities, and overall complexity, something changes. In lots of little ways, GitHub starts to show that it just wasn’t designed for long-haul projects that take many team members and a non-trivial workflow.

Here are some of the challenges GitHub poses  you might already be dealing with:

• You’ve created so many labels that you’ve written a wiki page to tell everyone how to use them (and how not to use them).
• Maybe you want to track bugs and support tickets separately.
• Perhaps you don’t think developers should be able to close a ticket just by committing code. There’s a “feature” in GitHub that lets developers mark a ticket as closed while in the act of submitting code. Our position is that you should not be able to close a ticket by submitting code because real software shops need to run tests to ensure the fix actually works.
• Maybe you’re tired of having to search in Google Docs, Basecamp, Slack, and GitHub to find where you talked about that new feature.
• Could be you need to manage relationships between tasks that depend on or block each other.
• You’re frustrated because your issues need a deeper workflow than what can be modeled when tickets can only be “Open” or “Closed”.

Let’s highlight where GitHub falls short with a couple deeper examples:

GitHub labels. Labels are quick and easy to use, offer a lot of flexibility, and require virtually no setup or configuration overhead. The default labels in GitHub look something like this:

These are probably fine for 98% of new GitHub projects. Over time, however, most teams expand on the list of tags to include different values than the default list, and even different types of data. Adding categories for basics such as type, priority, and status makes a lot of sense when you’re managing a backlog. But all of those new values can expand the list beyond what you can keep straight in your head.

So, how can teams use complex label sets reliably? One common convention is to use a prefix word to identify the group to which each label belongs:

This approach has the benefit of including the type of label as part of the label text, so you won’t be confused between “Status: Test”, “Environment: Test”, and “Task Type: Test”. Visually, the various colors can be used to show differences in specific values, such as production vs. non-production, or high priority vs. lower priority.

The downside is that when viewed across label types, the different colors are confusing and even downright jarring. Instead of quick visual signals based on color, you actually have to read each label value. It’s bad enough when looking at a single task, but when browsing a list of tasks, it can be a hot mess.

GitHub workflow. If you’re honest, you admit GitHub doesn’t really support pushing your issues through any enforceable workflow. In fact, its makers would argue that it is a feature: Less rigidity equates to easier to use. And they aren’t wrong, but any real business wants to ensure all work is handled consistently, which means your issues need more than an Open or Closed workflow. There could be planning, design, code review, testing, deployment, and other activities. It’s fairly common to reflect some of that workflow in the status so everyone can tell where a task is and what needs to be done next without having to re-read the entire history.

Closing a task just because you’ve committed some code assumes everything else will go right. Usually, committing code is just the beginning of the process, not the end. The new fix must be tested before moving on.

So, what is the right solution?

Instead of a mashup of various labels organized by a prefix word or a color scheme, consider this layout (with a few additions that should be obvious):

Separating these various concerns gives you the flexibility to require some fields when a task is created and wait for the right step in the workflow for others. So, rather than manually enforcing your task management process, you can let your tool do it for you.

One last benefit : If you’re using separate fields instead of specific tag values, then changing the name of the field or the values over time won’t break old data. The new field name or value(s) will be reflected in older tasks automatically.

Jira tickets (Jira is proprietary software developed by Atlassian for project management). Its users are quick to point out that they aren’t immune either. Jira’s lofty goal of owning the enterprise market means while they overcome many of the problems of GitHub, they still get some key features wrong. Here are some examples Jira users struggle with every single day:

Performance. Unlike other project management software on the market, Jira isn’t a Single Page Application (SPA). This means you get to enjoy a lot of clicking and waiting and waiting some more.

Duplicate tickets. When creating a ticket, shouldn’t the system let you know you may be submitting a duplicate? Furthermore, shouldn’t the system tell you the problem or goal in the ticket has been addressed already on sites such as StackOverflow?

Batch updates. Updating several tickets in batch should be easy. Yet Jira often makes it far more difficult than it should be.

Quickly adding new tickets. In the planning phase, it is common to create several tickets at once all within the same milestone or sprint. Most systems require you to rekey many of the same pieces of data instead of using the same defaults.

Ticket types. Although the distinction about tickets is important (e.g., user story, epic, task, bug), adding flexibility shouldn’t slow the team down or complicate tasks.

Imposing workflow. Workflows can help teams stay on track and handle tasks in a consistent manner. But the system shouldn’t force a specific workflow on teams. Furthermore, implementing a custom workflow, however infrequent this may be, should be far easier than Jira makes it.

Dependencies. Dependencies between tickets are common, yet Jira doesn’t 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 need a separate email for each update? You should have the option of receiving daily digests.

Ticket previews. Because the work in tickets can be a part of any milestone, release, sprint, etc., you often need to know more than just the ticket number and summary. Yet, surprisingly, Jira doesn’t give you ticket previews everywhere a ticket is referenced.

Pull Requests: A Bottleneck

Believe it or not, many collaboration programs work against collaboration. To illustrate this point let’s look at the traditional model of pull requests (PRs). Remember, today’s model of PRs was popularized by some of the world’s largest open-source projects. What’s good enough for them should be good enough for anybody, right? Absolutely not. That’s because open-source projects are a unique animal and their needs can differ from those of a business. 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 do that, you create a PR which is essentially another 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, code review comments live in the PR, not the ticket. Performing code reviews in the PR (essentially against your repository) works great for open-source projects because contributors are cloning the repo all the time deciding what issue or issues they want to fix. In fact, it isn’t uncommon for a PR in open source projects to address several issues.

“But that isn’t a problem?” you ask. Consider that for every PR that comes in, a lead on the project has to process that PR. Open source leads will tell you that a lot of PRs are rejected because they are tackling too many issues in a single PR. So many open-source projects end up with a huge signal-to-noise ratio resulting in a lot of wasted time by the leads. Business simply can’t afford that kind of waste.

“So what’s the fix?”, you ask. To put it simply: less is more.

You already have a ticket to “Implement Feature X”. Your collaboration software even lets you associate your commits to the ticket. So why not do the code review and merge cycle in the original ticket. A ticket is the smallest unit of work, then doesn’t it make sense to do all of the work in the ticket? Performing PRs this way ensures 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.

Chat Solutions

Using chat can be a great choice for the central hub of any successful project. Chat conversations give concise context and often include references to key project artifacts such as tasks, support tickets, and documents. Yet organizations find that moving to products such as Microsoft Teams and Slack often fail to meet their promised value propositions. Here’s why:

1. Integration. The value of chat is being able to discuss various project artifacts (tickets, documents, support tickets). Standalone chat solutions either don’t provide all the integrations you need or, if they do, API changes on either end of the vendor chain can wreak havoc on getting things done.
2. Authoritative source. Have you ever collaborated on a Google Doc in Slack? It works fine, but how many times have you opened the Google Doc only to find additional comments in the document? Who is the authoritative source for direction?
3. Velocity. A good chat room allows direct collaboration among a team, but it should also stream project activity into your chat rooms. Seeing new support tickets being opened or commits coming in, all in real time, help project managers gauge and monitor the process of various projects as they develop.

For these reasons, you should consider collaboration solutions where chat is a foundational component, not an a upsell, marketplace purchase, or afterthought. Solutions with chat at the core of your collaboration helps keep the entire team in sync and gives your team one place to go with questions.SH:

The Need for Commoditized Collaboration

Will you answer yes to any of the following questions?

• Is your organization’s intellectual property a primary concern?
•  Are you worried about your ability to control cost on collaboration solutions?
• Is data locale or data ownership important?
• Do you worry about locking in vendors?
• Do you have to comply with industry regulations?
• Does your organization have to worry about national security issues?

If you answered yes to any of these, you should strongly consider an on-premises solution rather than a cloud-based one. Ah, but there’s a catch: While most collaboration solutions have an on-premises offering, you can rest assured it will come with a high price tag.

Then there is our old friend Total Cost of Ownership (TCO). See, once you purchased your collaboration solution, you will now be tasked with assuming the responsibility of keeping it secured, running, up-to-date, and backed up. It will also be your responsibility to assure it works with third-party hardware and software. TCO only climbs higher if you work in industries like defense with complicated network security and no internet access.

Commoditized collaboration makes collaboration much easier for end users. In any successful organization, collaboration is as fundamental a need as that for water, food, and power. To make collaboration a commodity, industry must hold vendors accountable that:

• Running in a private or public cloud should not only be possible, but trivial to setup.
• In public clouds, you should have the option of running either multi-tenant or on your own.
• On-premise customers already recognize the challenges they face but don’t make installation, configuration, or upgrades any more difficult than they need to be.
• Moving from cloud to on-prem or vice-versa should not only be possible but trivial.
• Running more than one instance of your collaboration system should be possible and affordable. I can only imagine the fits our friends in defense and aerospace have with security clearances, network security, and server security when it comes to collaboration.
• Building on the last point, moving individual projects from one instance to another must also be possible.

The problem is that vendors are often too busy trying to convince you why their product is so great instead of trying to solve the real problems we face with collaboration. As soon as vendors get over that hump and view their product as a commodity, it will align quite well with a variety of industries and each of their unique needs.

Tony Bibbs is president of The GForge Group Inc.