Bridging the Gap Between Engineering and Business Teams

by Rachael Byrne June 30, 2017 | 4 min read

It sometimes feels like engineering and business teams speak different languages and work in completely incompatible ways. Agile development teams work with sprints, user stories, scrums, and relative estimation, whereas project managers gravitate more towards gantt charts, calls for proposals, and change management techniques. These differences can be seen in bimodal organizations where some teams practice DevOps with agile methodologies and others use more traditional organizational structure and project management.

Inevitably, though, these different teams need to work together. PagerDuty was faced with this challenge for a major business system implementation that required product engineering as well as business system configuration and process changes that touched sales operations, finance, and customer support. This big project was successful because we were able to adopt four key practices to collaboratively plan and execute across engineering and multiple business teams.

Focus on Use Cases

Start by bringing representatives from both the engineering and business teams together to brainstorm use cases that should be possible in the project’s final product. It’s important to list out tasks end users will perform in the system regardless of who or what will be involved to build that functionality.

By focusing on use case-based requirements, you will enable the teams to consistently deliver valuable end-to-end functionality throughout the project. Waiting until the end of a long project for disparate work to come together creates risk that what teams build separately will be incompatible.

Documenting the use cases you want to build can also serve as a runbook for user acceptance testing, release notes, and a starting point for an end user how-to guide.

Divide the Work

Next, consider what work is required to build each use case. It’s likely that each will require some engineering work and some non-engineering configuration. Being clear about what each team is responsible for delivering will help ensure required work is not missed. This discussion will also help the teams understand what they will need from each other, anticipating dependencies and necessary coordination.

Visualize the Work

Now that you’ve started to capture each team’s tasks, it is important to visualize all work in a single task management tool. This maintains transparency across teams. Looking at each other’s in-progress tasks and backlogs of upcoming work helps teams manage their dependencies.

Stay in Touch

Finally, for projects that require such close coordination between teams, it’s important to maintain a regular cadence of communication. Cross-team daily standups are helpful to keep teams informed of what they are working on and what they need from each other. Touching base briefly at the start of every day will help resolve cross-team issues quickly.

Teams should also touch base on a weekly, bi-weekly, or monthly cadence to share what they’ve completed. Regularly demonstrating the teams’ completed tasks together validates that they are producing compatible work that delivers end-to-end customer value throughout the project.

Just as DevOps promotes product development and operations teams working more closely together to deliver a better product and customer experience, engineering and business teams must learn to work together in order to build better internal systems that support the business. Engineering and business teams can successfully collaborate by clearly dividing their work, keeping their work visible to each other, and communicating frequently.

This collaboration model was such a success with one of our system implementation projects that this methodology is being adopted by more teams across the business. To learn more about introducing lightweight agile practices to business teams, read our 4 Tips for Introducing Lightweight Agile to Business Teams blog post.

And let us know, how do you enable cross-team collaboration in your organization?