Case Study: Why did APRA|AMCOS Go Jira?

About APRA|AMCOS

APRA|AMCOS work to ensure that composers, songwriters and publishers are rewarded whenever and wherever their musical works are played, performed or reproduced. They also help Australian & New Zealand music consumers get access to the world’s musical repertoire. APRA (Australasian Performing Rights Association) and AMCOS (Australasian Mechanical Copyright Owners Society) are separate not-for-profit organizations, but a number of members belong to both, so AMCOS appointed APRA to manage their day-to-day operations in 1997.

Handling Incoming Information

APRA collects performance data for songs and musical works composed by their members. I spoke recently with Mark Atkins, Solution and Support Manager, about why they moved to Jira after using a tool built in-house for many years. Mark’s new Jira deployment went live to all 220 employees across Australia and New Zealand on Friday, May 18th, 2012.

So Mark, what is your development team working on?

“A large amount of data comes in, and we need to process that data and distribute that money to the appropriate people–the people who wrote the songs. One of our largest data feeds is from songs purchased on iTunes. To manage all this data, we’ve developed our own system in-house over the last 15 years. It’s a reasonably complex system and naturally there are lots of enhancements, bugs, and bits and pieces with that system.”
How do you track that work?

“To keep track of Assistance Requests (ARs)–what would be known as ‘issues’ in JIRA–in the past, we developed this Lotus Notes database. The problem was that, by the way things were organized in that tool, we couldn’t locate ARs very well, prioritize them, or easily track the status of specific ARs. It was very difficult for us, as managers, to have an accurate understanding of different teams’ workloads.”

“So, we decided to do something about it, and that was to switch to Jira – and I’ve worked at other places and looked at tools like Bugzilla, and the last place I worked before used Jira. We use Confluence here as well, so it was an easy choice for us to make because of the integration between Jira and Confluence. We’re also looking at Crucible and Fisheye of course for our development teams. Probably two thirds of IT are developers working on that big system, and managing those people and the amount of changes that we need to make to suit the business is difficult. So, we’re very happy and excited to have Jira coming in to help us do that.”

Why did APRA|AMCOS Go Jira?

Did you consider anything else, any other issue tracker?

“Not really, no. I was in charge of the product selection process. I’ve used Jira before, so to me there’s no question. When I downloaded an evaluation of Jira, played with the newer version, and got to know it from an administration point of view, it was an obvious choice. That was it. Especially because we’d already committed to Confluence as well, which was up and running. Integration between the two was very valuable, and it’s great to be able to make issues between the two.”

“And the other thing is, I’ve seen Crucible and code reviews over the years. The ability put a Jira ID into a commit tag in Crucible and have it automatically link, and to have Jira aware of the source code that relates to a particular – these things are fantastic. You guys should be up on top of the Empire State yelling out loud.”

What else can you tell me about development at APRA? Are you Agile?

“We lean toward an agile methodology rather than waterfall. We’re integrating Fisheye & Crucible on the source code side and using Subversion. We’re also using Crowd for single sign-on – that’s amazing as well. Crowd is backed by Active Directory, so we use delegated authentication for that. I’m considering Crowd as an authentication tool in the future applications that we build. It’s kind of like the promise since the 80s of single sign on, but it actually seems to work.”

“The nature of APRA’s business is quite complex, and especially because we’re gathering other peoples’ money, we need to be spot-on. So, we emphasize quality and reviews a lot to make sure that things are being done in the right way. It’s not quite an agile methodology yet, but it’s moving much more in that direction.”
How have you found working as an administrator in Jira?

“Well, there’s pretty much no work to do. Once a project has been configured with the workflow – and I’ve managed to learn that myself without documentation, it’s that simple – there’s nothing to do. It just runs itself. We’ve automated backups and that sort of business, and it just runs itself. Administration wise, the time commitment is pretty much zero. Especially because we’re using Crowd. That removes user management from administration. A big plus there.”

Reporting & Metrics

I asked Mark about the volume of tickets they currently handle and how well the team is meeting SLA’s and members’ expectations.

“Well, even this is information we don’t know. I know that from the existing system, because of Jira’s great importing tools, we’ve already managed to export 1,200 current tickets that will be imported to Jira to carry over into the new system.”

“The main thing we’re concerned about is throughput, because of the amount of work that we have. We don’t even have figures at the moment from the old system, like how long issues take on average to be resolved. And especially not detailed information like the time and status reporting that Jira has, like how long the issue has sat here, and then somewhere else, waiting for approval and waiting for peer review, and all that sort of business.

To see what’s going on underneath the covers – that will be lovely. And Jira can help us set resources for the team and also set expectations for the business. As I’m a liaison with the end users, I want them to be a lot more engaged and a lot happier with how we do their work for them.”

“We’ve definitely customized workflows in Jira, because it’s so flexible. We’ve been able to make it suit our own complex workflows, with peer review, testing, final reviews, and so on. That level of management and control, particularly with Jira’s in-status reports, which show us where issues are taking a long time and where bottlenecks are–that’s information that’s never been available before. We’ll be able to look at, for example, whether we have a bottleneck in peer reviewing, and add some resources there or have some training, and get the most out of the team that we have in view of this massive workload that we have.”

“One of the things that normal business people have complained about for the last few years is that they raise tickets and they’ve just disappeared. They never hear anything else, or were unable to find them or easily tell them what’s going on, and so on. The torchlight that Jira will shine onto that is amazing – we’re looking forward to that.”

The Roll-out

Mark’s team was using a home-grown tracker for many years, but the data migration over to Jira simple.

“We used a CSV export.

In the import tool in Jira, the mapping of priorities and statutes and so on was just fantastic, so I could set everything up exactly the way that I wanted.

On that cutoff date on the 18th, we’ll do a final import and just spend a day re-prioritizing things and working out what’s needed to give us a fresh start. The import tool is great. We’re going to turn off the old system instead of running in parallel. And that’s why we’re importing data in: so we can just shoot it in the head.”

How’s adoption going?

“We’ve put together an implementation team who we’ve asked to take some time out of their job and create a lot of issues for us. And we created some generic roles for Jira, like a recorder role, a signer role, and so on, and gave them all access to the system. And they’ve been playing with adding issues. And once they get over the ‘Oh, it’s new. I don’t like it’ feeling, they all pretty much universally liked it and are looking forward to it.”

UPDATE: Mark’s email to me this week, after the final migration:

“The final import of data worked seamlessly, and we were surprised to see exactly what we had there – already Jira’s dashboards have shown us the workload for different developers, which departments are raising the most tickets and what issue type they are, how old (blush) some of the issues are. Emails are flying around the place as we assign and prioritise – one of our user’s complaints was lack of communication, which has definitely been resolved!”

Why did you #Go_Jira?

If you switched from an old bug tracker to Jira, we’d love for you to tell us why. Let us know by tweeting the #1 reason you decided to #GO_Jira:

[THIS IS] why I ditched [MY OLD BUG TRACKER] to #GO_Jira http://atlss.in/GoJira

Did you Go GreenHopper too?

Tell us why you decided to #GoGreenHopper:

[THIS IS] why I decided to #GoGreenHopper http://atlss.in/GoGreenHopper

Exit mobile version