This is a guest post from Chris Le Petit– a senior consultant with Valiantys and a former support engineer at Atlassian.
Anyone who works in support will agree: it feels like the dev team isn’t exactly on your side. One of the biggest frustrations in support is when a problem can’t be solved because the dev team is needed to fix a bug or create a new feature.
We love solving problems; we’re support. It’s what we do. But now, the incident is out of our hands, and we never see the outcome. It’s frustrating. The customer is frustrated; there’s a lack of closure, and we have little to no control over how the issue is resolved.
Connecting the dots
I worked as a support engineer at Apple and Hewlett Packard prior to working at Atlassian. Now, I work with Valiantys – a leading Atlassian Expert consulting companies in the DevOps and service management space who is behind azanda ITSM, a modular solution based on Atlassian tools. The tension between support and development was felt at every company. But when I got to Atlassian, I was surprised to hear the developer side of the story. Surprisingly, the narrative wasn’t dissimilar from my own.
Every time I talked to the developers, I found they lacked context for issues they tried to solve. They had no attachment to the customer who raised the issue – for all they knew it was picked up by QA, not by an actually frustrated human.
While we lacked closure, the developers found it frustrating to never get feedback on their completed work.
Atlassian issues between development and support were:
- The lack of visibility on what happens to a bug after it’s raised
- Zero context for the developer about the bug
- No feedback loop for both teams
Support had to watch the bug, but we had no idea when it would be completed. If the developers wanted customer context, they had to dig for info. There was a serious lack of communication.
We tried many options to bridge the gap between development and support – we had adhoc methods, workarounds, customizations, and even created a team.
How collaborating on the same platform changed everything
Software development in Jira side-by-side with service projects in Jira Service Desk made it easy to link a customer support issue back to the development bug. When everyone does this, you get a lot of context for the development team.
In development, a lot of time is spent creating and referencing personas to serve as reminders that users are real people, and that real problems are being solved. But nothing is better than seeing the frequency and the emotions behind that ticket with comments from the customer. It’s incredibly rewarding to alert customers when their issues are resolved. Using the same platform, like we did at Atlassian with Jira and Jira Service Desk, both the development team and the support team had context and collaborated better.
Setting the information free
As a support engineer, information is everything. To solve problems in a queue quickly, generally, we would search old support tickets (with the customer error message) to find whether this had been solved before. Setting up a strong knowledge base is everything for support. It allows us to constantly check back and refer to previous problems to see whether or not they’re still relevant to solving the current customer’s problem.
Ticket history lets us know:
- If the issue is linked to a bug
- The details of that bug
- Workarounds or suggested fixes
- If it’s been scheduled to be worked on
- If it’s already fixed in an existing release
Sharing critical information based on the issue helps the development team prioritize their work – if there are two issues of equal value and difficulty, checking the support impact can decide what gets worked on first. Linking issues meant we could work as independent teams with different styles, but at the same time work together towards the common goal: helping the customer.
Are you the right person to handle this question?
We worked hard to reduce frustrations between teams and found a critical factor: escalation points were undefined. People couldn’t pass the information along, or the information went to the wrong people.
Second, information needed to flow both ways. It wasn’t just the support team asking developers to help us understand how to repair the ranking data after it had been partially corrupted; it was also developers asking support, “If we make this change to the ranking system, what do you think we should look for during migrations?”
Once we established internal escalation lines on each team and external points for contact, we had a smooth and unified way of communicating between teams. We took ITIL and coupled it with DevOps methods and what came out is how we bridged the gap between two worlds – agile + ITIL – and it worked.
About Chris Le Petit
Today, I’m helping companies implement these best practices with Jira Service Desk and Valiantys‘s azanda ITSM – a collaborative solution helping business transform their service teams. Based on Atlassian technology, azanda ITSM is pre-loaded with ITIL based processes and best practices and lets me enable faster deployment and standardization across the organization.
It’s been an absolute blast, not only helping teams get set up with these tools, but also sharing my experiences. I’ve always been passionate about service and the customer experience. Just knowing that development teams felt the same was a relief. Jira Service Desk allows us to share that passion from our ends of the cycle, and that’s my favorite part of the job.
What are your thoughts on how support and development should work together? Leave your comments below.
If you’re interested in how DevOps can be applied to IT, watch the latest webinar by ITSM expert John Custy. He’ll show you how to bring DevOps principles into your IT support team with actionable tips.