It's a bold but necessary move for Atlassian, which derives three-quarters of its revenues from Jira, along with its companion Confluence knowledgebase. In the past sixteen years, the way that agile teams work has evolved substantially, and those learnings have influenced new patterns of digital collaboration across all kinds of enterprise teams. It was a case of adapt to this new world or die, explains Megan Cook, head of product for Jira Software Cloud:
We thought, let's disrupt ourselves before some startup comes and does it to us.
The changes can be classified into five major themes. The first is providing greater autonomy and self-service control to small teams that work in a DevOps environment. Hand-in-hand with this goes the second theme of greater transparency and visibility across teams within a given project. Ease of use is the third theme, which in part recognizes that not all team participants using Jira will be developers. A fourth theme is much closer integration with other tools that developers use alongside Jira. And finally there's a new cloud-native architecture, delivered on Amazon Web Services (AWS).
Designed for smaller developer teams
Agile evolved along with the advent of massively scaled cloud infrastructure and the rise of continuous integration/continuous delivery (CI/CD). Software engineering teams adopted new cross-functional DevOps structures that fused development with operations. To enable greater agility, reliability and iteration, the software they built gradually broke down into smaller discrete functional building blocks called microservices, and the teams themselves also broke into smaller, autonomous units.
When Jira first came out, it wasn't unusual for an agile development team to be a single group of a hundred or more engineers delivering new code every few weeks, and the way they worked was governed by a single Jira administrator. Now people typically work in small teams of 6 to 10 people delivering new code as frequently as several times as day. The new Jira is designed to allow these smaller teams much more autonomy, says Cook:
Thanks to advancements in architectures like microservices, they can be really focused on just a specific part rather than having to understand the entire code base. What that means is they're able to move really, really fast, but they're also able to use different technologies. They're able to work in the context that makes sense for them, which is awesome, but then they have completely different processes from each other ... because they're moving so fast, they've got to deal with all of these problems that crop up and they're the best people to solve them.
This means managing everything that's going on becomes as tricky a task as herding cats. The degree of autonomy these teams enjoy is often surprising, as I learned a couple of years ago in conversation with Sky Bet's Gavin Harris, engineering manager for platform services at the online sports betting firm. Individual teams didn't have to follow his recommendations, he told me:
We definitely don’t set the rules. We’re not prescriptive, we provide the platform and the tools ... We don’t say how you need to release your application. We don’t say how you manage security patches in your autonomous team. That’s up to your autonomous team to decide. It’s your application, you own it and you run it.
Combining autonomy with transparency
In the new version of Jira, autonomous teams like these can even choose to switch between completely different styles of agile, explains Jake Brereton, Head of Marketing for Jira Software Cloud:
For example, the backlog is something that a typical scrum team uses to prioritize their work, [whereas] Kanban teams don't. But if you're a Kanban team and you've got a lot of work and you want to turn it on for a week, to help you better prioritize, that's totally fine. You shouldn't be stuck in a world where you can't do that. So you click on backlog, and it's on ... it's literally the click of a button.
Giving teams this kind of autonomy can only work if there's still oversight of what's going on. So the the second strand of the new Jira is that it offers much more visibility across a project — not just for managers, but for everyone in the various teams. A new roadmap view of a project presents the status of each major element — known in DevOps circles as an 'epic' — with the ability to drill down to individual 'stories' or work items. In the past, this kind of project overview might have been gathered in a spreadsheet or a slidedeck, but now it can be seen and adjusted in real-time, as Brereton explains:
We're giving teams a very visual way and a very simple way to see the streams of work that are in flight and how they're tracking ...
Teams really need one place to come to, that they can quickly look at and they know with accuracy that what they're looking at is the most up-to-date, real-time view of how they're tracking towards a project.
Ease-of-use and integration
Ease-of-use is a third element that runs through the new Jira. Several capabilities that used to require coding have now been brought into a point-and-click board layout that has much in common with Trello, the popular project manager acquired by Atlassian early last year. Filters that let users view work streams by assignee would previously have been coded in Jira's own query language. Now they're available by selecting an icon at the top of the board. New steps can be added to the workflow by drag-and-drop, instead of digging down into the configuration controls. This not only saves time, it also opens up these capabilities to a wider set of users, says Brereton:
That was always possible in Jira, but we've brought that simplicity to the board. It might have taken three or four minutes to probably do that before and add another workflow. The other thing is, it's now available for more people to be able to make that change.
Integration is a big part of the new functionality, again acknowledging the many different bespoke tool choices that individual teams make, while also recognizing the extension of those teams to include other disciplines such as designers, product managers and data analysts. By integrating all of the tools people use back into the Jira issue, it becomes the one location that brings all those different sources of information together, says Cook:
Your work is spread out in ten different places. We really wanted to make it easy to bring all of that information back onto the issue as the unit of work. So you have just enough information, at a glance you can see what's going on, where to find it, and not necessarily have to go searching through all of these different tools.
New APIs bring information back into the Jira ticket from code repositories including BitBucket and GitHub showing its status. APIs also now support releases directly into feature flagging, which allows iterative roll-outs of new features to subsets of users to test adoption and impact before rolling out more widely.
Outbound integrations into Slack and Gmail can send notifications and updates that people can view from the message or email, and either respond from there or click a link to view the issue within Jira. It's all part of ensuring Jira continues to play its role as the central point for tracking issues, says Brereton:
We want ultimately to bring all the context that anyone needs from the tool they're using onto the Jira ticket. So that in this world where everything's moving so fast and things are constantly in different states, tickets are being created, tickets are being shipped, there's one place that says, 'Hey, we've got it all' — this is the central nervous system, the center of gravity.
The final big theme is that all of this functionality has been built as a cloud-native, microservices architecture and runs on an AWS platform. It targets the 80% of new customers who choose the cloud version of Jira, rather than the older cohort of organizations that have installed it on-premise. There's no word yet when the new functionality will become available to on-premise customers, and in what form.
This is a big re-engineering of a flagship product but one that makes a lot of sense given the evolution of Atlassian's target market among developers. The vendor needs to keep pace with their changing needs and work patterns as agile and DevOps continues to evolve to encompass new disciplines such as site reliability engineering (SRE).
In retrospect, it also makes sense of the decision earlier this year to hive off its messaging products Stride and HipChat to rival messaging platform Slack, despite the pain this is inflicting on users. Atlassian has made a difficult but sensible choice to focus on evolving its successful core product, rather than soaking up development resources on a new product that would find it difficult to make headway against a fast-growing competitor. Instead, the company has reinforced Jira both with this new release as well as the recent launch of a Jira Ops sister product after the acquisition of OpsGenie.
Doubling down on strength is a wise move in the highly contested collaboration sector. Atlassian still has a big opportunity in the fast-growing software development market and is right to refocus on keeping its flagship product relevant to the user segment the company understands best.