Why engineering collaboration matters in software development

An important part of a software engineer’s job is to gather, understand, and finalize requirements. This often involves multiple meetings with multiple stakeholders (customer, security/network team, managers). Translating everyone’s desires into implementable action points, while avoiding conflicts, is key.

Ensuring that everyone is okay with the finalized implementation plan, before starting development, is also vital. All these reasons warrant the use of inter-tool collaboration for timely and seamless communication during software development.

Why is collaboration key for successful software development?

A software developer lies at the heart of a company’s value delivery system. They keep consuming new requirements and change/feature requests and keep producing tangible value. They often have to juggle multiple tasks raised by multiple stakeholders at the same time.

Prioritizing such tasks and ensuring that the most critical releases get their primary attention is very important. They also have to keep track of the changes they are making in different parts of the application and ensure that they don’t conflict with each other (or with the works of other developers).

All this is not possible without collaboration between different enterprise tools.

Stakeholders also must have access to all the relevant information. They should have visibility into the features under implementation, reported bugs, and priorities of change requests.

This will allow them to make any suggestions before it’s too late (the development has already ended) and know what to expect and when to expect it. Of course, achieving this would require collaboration between tools used by developers and stakeholders.

Moreover, it must be possible to trace every software development task back to its corresponding requirement. At any point, the what, why, and how of a feature must be clear to everyone involved. This is important in avoiding conflicts and assigning ownership.

For example, suppose a questionable feature is identified during a high-level meeting. If the software engineer is asked to explain the reason for its implementation, they must have a way to pass the baton to the stakeholder who raised the initial requirement.

In an official setting, this can only be done via collaboration between requirement and change management tools, where the pertinent requirement was documented by the developer and approved by the stakeholder.

Via efficient collaboration between different tools, all teams (Database, design, development, deployment, management) are always on the same page.

What happens when engineering teams aren’t collaborating

The silo effect is fairly common in companies with different functional areas. Teams work well independently, but don’t have a system to collaborate with people from other departments. This splits business-critical information across different silos and leads to a drastic loss in productivity.

Inter-tool collaboration acts as a great medium for information to flow. Without it, there is a chance for a mismatch in details across different tools. For example, the product owner raises a requirement in their tool, for 3 new options to be added to a drop-down menu on a certain screen.

However, when the development manager creates a task in their project management tool, they accidentally add only two options. Without collaboration between the two tools, the developer attempting the task will have no way to trace the requirement back to the original request.

In addition to this, when there is no collaboration between tools used by different teams, information starts getting shared via other, informal channels. For example, the scope of the project might get shared via email; the new requirements might get communicated over a voice call; change requests might get shared in a PDF over IM, and some features might get implemented over hunches/assumptions.

Collaboration adds traceability and visibility to the entire software development process. A Dev manager can know what their developer is working on, at a glance. They can also know what features the developer is implementing and upon whose request.

If at any point they want the relevant stakeholder to reaffirm their request, they have an official channel to do so. All this helps a great deal in avoiding potential issues that can arise due to bad/no collaboration.

Without collaboration, it’s also hard to track the progress of development tasks/projects. You have to personally ask every developer for updates; you can’t just log on to a tool and see the status of every task there.

However, if managers/stakeholders do have visibility into project progress, they have a chance at optimizing development delivery. For example, they can assign high-priority tasks to certain developers, or reassign tasks that haven’t been completed in a long time.

Doing all this manually would not only be a nuisance, but also ineffective and non-productive.

Which teams and tools need to collaborate and why?

We have now established that certain tools must collaborate with each other for teams to be productive and efficient. Let’s now explore which tools these are, and why their collaboration must be prioritized over the rest:

Requirement and change management tools

Requirement specifications enter the system for the first time via a requirement management tool (IBM DOORS, or DOORS Next Generation for example). Usually, system engineers are responsible for operating the requirement management tool.

All the features, test cases, user stories, expected results, and other important characteristics of a requirement are specified there.

A change management tool (Atlassian Jira, Polarion ALM, etc) is used by developers to organize the different change requests raised by the stakeholders. These change requests are created on the basis of requirements, so, naturally, it would make sense to have collaboration between the two tools.

This will help ensure that the feature specifications across both the tools are the same, and that all involved parties know exactly what’s being worked on. For example, if a system engineer wants to know what change a certain developer is working on, they should have a way to view the change request(s) assigned to that particular developer.

Defect and change management tools

Defect management tools (ticketing systems) are used by system engineers to report bugs and broken features to the software engineers. These usually require immediate resolution as customers are being affected.

These tools must also be connected to the change management tools, as defect resolution requires change(s) in code which has to be managed somewhere.

By connecting the two tools, developers can easily report expected timelines or fixes to the system engineers. The engineers can in turn track the progress of changes, and get real-time insight that can be shared with the customers.

Versioning control system with project management tools

A versioning control system (VCS) is an absolutely necessary tool for software development. As multiple developers are expected to contribute to a codebase, it’s important to have a centrally managed repository that avoids conflicts and keeps everything updated.

The VCS needs to be connected to the project management (PM) tool. Here are a couple of reasons why:

1. Commits indicate progress: When new code for a certain feature gets pushed to the repository, it indicates progress. The same should automatically get reflected in the project management tool.
2. Correlating commits to releases: When you create a release in a project management tool, you bundle up different tasks (features). By connecting your VCS to your PM tool, you are able to identify the commit hash of a feature in the VCS. This helps when you have to cherry-pick certain features while releasing your code as a package.

What does successful collaboration in software engineering look like?

A successful collaboration between different tools has the following characteristics:

• Extension, not modification: A successful collaboration shouldn’t pose any learning curve to the end-user. It shouldn’t modify the interface, or needlessly complicate any existing functionalities; it should just add to them. The user shouldn’t have to learn a new toolchain to continue doing their job.

• Traceability: It also achieves end-to-end traceability. In our case, this traceability means being able to trace a requirement back to its origin. For example, for every task created in your change management tool, you should have a corresponding identifier for a task in the requirement management tool.

• Transparency: It keeps everything transparent. All the relevant parties have access to all the important information at all times. A developer can access the original requirements of a feature they are working on; a high-level manager can view the progress of a change request, and a system engineer can check whether or not a critical bug will be resolved timely. All this helps in making sound, informed decision-making.

• Real-time Collaboration: Continuous, real-time collaboration results in everyone being on the same page. Even the system engineers know which developer is working on which bug and even the non-technical managers know how much time a certain development task is going to take.

• Knowledge sharing: An integrated dataset means that knowledge gets shared across different tools and different teams seamlessly. Even if the teams don’t explicitly share information with others, the collaborating tools do it for them.

Achieve successful collaboration with OSLC Connect for Jira

It has become more important than ever for teams working in complex software development to collaborate efficiently. Requirements, test, and defect traceability while allowing reporting across repositories are critical cross-team collaboration touchpoints for successful software development.

OSLC Connect for Jira allows Software and Systems Engineers to achieve end-to-end traceability and increase visibility along the product development lifecycle by enabling linking and friending between Atlassian Jira and IBM Engineering Lifecycle Management or Siemens Polarion ALM repositories. OSLC Connect for Jira will allow you to:

• Connect your Jira team with your IBM Engineering Lifecycle Management,
• Connect your Jira team with your Siemens Polarion ALM,

Software and System teams can now achieve visibility in Requirements Management, Architecture Management, Quality Management, and Change Management from concept to implementation while operating in their tools of choice.