Fortunately, you can ensure collaboration and cooperation between your teams and their toolsets without changing your entire tool ecosystem. The key is to connect your tools together in a way that allows them to share information and make work visible, but without changing the way people work with each tool. Many tools have built-in integrations that let you share data directly with other tools. But if no such integrations exist, you can use connected lifecycle management tools to integrate with them in order to collate and share information. This article examines how connected lifecycle management tools enable effective communication at the
enterprise level without changing how each team works.

Islands of DevOps

A key tenet of DevOps is to break down walls, remove silos, and form teams capable of everything required to deliver software: developing features, deploying them to production, and maintaining them to ensure high quality and high availability. Due to the organic way in which DevOps has evolved in many organizations, and the ever-growing number of tools aimed at the DevOps market, it’s not unusual to find teams working side-by-side, but using different tools.

Each team manages its own pipeline, maintains its own backlog, and uses its own testing tools, deployment tools and monitoring tools. For many teams, this works well; it makes no difference to them if other teams are using alternative products, as long as each uses the tools that they consider the most effective for their needs.

Why It Matters

While each team works perfectly well on its own, the team members often have to integrate with other teams. When one team delivers a service that is consumed by another, it’s not always possible to create a cross-functional end-to-end team that can cover everything from the service’s back-end to the user interface on the front-end. The two teams will need to synchronize their work, and be able to share assets and information.

For example, if the consumer team finds a defect in the service, and they can’t fix it on the spot, they must log the defect. If the two teams are using different defect tracking systems, it’s challenging to share these assets. For one thing, the defect needs to be logged in the provider’s system, so that they’re aware of it, and can fix it. If the consumer team doesn’t have login rights to the provider’s system, or even access to the server, there’s no way to record the defect, and it won’t be fixed. In this situation, the teams will continue to rely on email and other inefficient and ineffective collaboration tools that aren’t suitable for this purpose. While improving and evolving their DevOps practices, organizations sometimes encounter the situation where a single team uses more than one tool for the same thing.

It is not uncommon for test engineers to use one tool for managing their backlog and tasks, while the developers use another. This is often a historical artifact of organizations that had a clear division between the QA and the development teams – a strong indicator of Waterfall development – and who are now combining their people within the same team. However, the various specialists continue to use the tools they’ve used in the past. This results in a situation where even communication within the team is stifled.

A Simple Approach

A simple solution is to pick a single set of tools and enforce them across the organization. Everyone must use the same lifecycle management tool, the same functional testing, performance testing, and security testing tools, the same deployment automation tools, etc. But this is naïve, and the cost of replacing the existing tools with a new set of tools is prohibitive, because:

Many organizations are still paying for their existing tools, in terms of licenses and support. There’s no guarantee that they’ll get a refund if they end the contract early. They’ll end up paying for both the existing software and the new software at the same time.

The effort of disconnecting the existing tools from their DevOps pipelines, and adapting the new software to replace them, can be unexpectedly high in cost and time. Customers are more interested in getting their hands on software updates than on waiting for the team to re-engineer their pipeline.

The DevOps team should be concentrating on delivering value to the customer. Introducing new tools often means introducing new defects and bottlenecks, as the team learns its way around the new ecosystem.

Even if a single set of tools is chosen, there’s no guarantee that the tools are able to share information and provide teams with the insights that they need in order to track their investments, manage their backlogs, and resolve issues.

If a new organization is forming from scratch, this approach may work (although keep in mind the last point). But how often does that happen? Most large organizations that are moving to DevOps have a long history and investment in tools, processes and procedures. These can only be changed gradually.

Conclusion

Teams need to have the autonomy to make decisions about the toolsets that work best for them. At the same time, teams need to work with each other, and if they choose tools that don’t integrate closely, communication channels within and between teams are hampered. The most effective solution is to let the teams choose their own tools, and in parallel, adopt a connected DevOps tool set that provides the necessary communication and collaboration channels end-to-end— and that integrates with the tools the teams already use. Each team decides how it prefers to work, while the information it generates is automatically shared with the other teams and the senior managers. The organization can ensure that each team is giving the most critical and strategic investments the correct priority, and is gaining visibility into the status and progress of each item, regardless of what tools it is using.