3 collaboration patterns between developers and non-developers

In a world that increasingly relies on software, there’s a need for smooth project collaboration between developers and non-developers in order to realize business objectives successfully. This is where Backlog comes in handy.

Its user interface is simple even for non-developers to understand, navigate, and use for work without going through extensive training. At Nulab, our developers and members from various teams, including support, marketing, accounting, and legal, use Backlog every day to collaborate on projects and tackle different tasks.

In our own experience working with Backlog, we’ve identified three general patterns for managing tasks and issues between developers and non-developers. To help you consider which you should use for your teams’ collaboration, we’ve put together a list of our methods along with the pros and cons.

Three patterns for issue management/collaboration

1. Manage one-off issues in a single project

This is the most straightforward pattern. When there’s a one-off request for help, it’s registered as an issue in either the requestor’s or assignee’s project. Both team members will discuss the registered Backlog issue to complete the task together.

For example, the marketing team requests that the development team updates contact details or changes an image on the company website.

Best for: You’ll want to use this for simple, one-off tasks that do not occur regularly. Usually, you’ll be able to complete this work within a few hours or days.

Pros: Since there’s only one place to raise issues, the issue management cost (in terms of time, effort, etc.) is comparatively low.

Cons: The work request will be registered in one project, so it requires the other party (e.g. the developer) to have access to that project. This will increase the number of members you will have to manage as a part of this project. Because the assignee is working on tasks in several projects simultaneously, it can be difficult to correctly prioritize tasks between multiple projects.

The solution is to use this pattern for more straightforward tasks, notify the assignees (i.e., the developers) of the issue, and decide on deadlines. Then, it shouldn’t take too much effort to manage the task while working on it.

If your dev team typically handles a low number of issues outside of their normal work, this pattern is an excellent place to start.

2. Manage the same issue in more than one project

The second pattern is to register the same issue in more than one project. This may be complicated and time-consuming to manage, but each team can have the independence and flexibility to manage issues according to their workflow.

For example, the support team receives a bug ticket from a user and reports it to the development team. Resolving the bug might entail working on other subtasks at the source code level — these are details that the support team doesn’t need to know about — so the development team can manage those subtasks in their project. Meanwhile, the Support team continues their workflow in handling the issue and communicating updates with the user.

Best for: This method works for complicated tasks that tend to take more time and effort. It’s efficient when each team has their workflow to manage the job from their perspective.

Pros: It’s easier for both the requester and the assignee to view all of their tasks and task priorities. Besides, each team can flexibly manage issues according to their workflow needs.

Cons: Double management of issues is required.

At Nulab, we use this pattern for some of our operational work. For example, the copywriting and image design tasks related to a website update are tracked in the Marketing project, while development work tasks are followed in the Product Website project.

This approach has two goals: We can prioritize individual issues within the project and track the teams’ health and workloads based on the increase or decrease in the total number of issues they handle.

3. Manage issues across teams in one project

In some cases, separating work into team-defined projects like the previous two patterns makes it difficult to gain an overall perspective of a significant project or campaign.

For example, after completing a feature development, you may want to carry out marketing or press-related activities to publicize the new release. In other words, the teams that are involved change according to the phase of the project.

In a case like this, it’s possible to create a pattern where the project has different phases and different team members are involved in each stage.

By centrally managing and visualizing the project in this way, it becomes easier to see how each member contributes value at each step and how everyone’s cooperation is critical to success.

It’s also easier to manage and optimize the overall process in this way. For example, suppose the marketing/PR column is clogged with tasks, and new features/updates are developed and released. It will be challenging to carry out marketing activities that can promote the new updates adequately. If the development column is overladen, consider making adjustments at the planning and requirements stages.

Thus, it would be prudent to pace the work or hire temporary staff to ease the workload. Keeping track of the entire process and seeing how the different team workflows are linked is the necessary first step to optimization.

Best for: This pattern is best suited to tasks where we want to have a bird’s eye view of the overall process to consider ways of optimizing the process. Optimization would be from a business-wide perspective involving multiple teams rather than partial optimization from a single team’s perspective.

Pros: It’s easier to see the customer value provided as a whole, and the end-to-end workflow becomes transparent so we can achieve overall process optimization. It’s easier to achieve better collaboration when every team is aware of their common purpose.

Cons: It takes time and effort to identify the business objectives and processes that span multiple teams.

Summary

We can summarize the three patterns for managing tasks between developers and non-developers as:

• Using a single project to manage one-off or simpler issues
• Using more than one project to manage related issues independently
• Using a single project to manage issues involving multiple teams at various stages

Which pattern is best for your organization? Well, no one design fits all. Consider the complexity of the work, members involved, the frequency and amount of communication needed. Then, you can better decide which pattern to adopt for your collaboration between different teams.

We hope that this article has been informative and helpful for you. As always, happy collaborating!

References:

This post is adapted from the Japanese article, Backlog utilization technique taught by Backlog engineers, written by Nulab team member, Tomonari Nakamura.