Atlassian today is releasing a completely overhauled and rebuilt version of its Jira project management software from the points of view of permissions, navigation and user experience.

“The Jira you needed in 2002 and the workflow you built in 2010 and the permissions model we put together back then isn’t the one we need today,” said Sean Regan, head of growth for software teams at Atlassian. “And that’s really driven by this change in the market around modern software development,” including the adoption of cloud computing, microservices and containers, as well as organizations empowering autonomous development teams.

“You don’t get too many chances to formulate a new foundation to your product. This is the best chance we’ve ever had to do open-heart surgery on Jira,” he added. “That moment was when we made the decision to split our product into a cloud version and a server-based version. We made that decision a couple of years ago, and when we made that decision, we moved our cloud version to AWS. And that was the moment we cracked it open and took a really hard look at the guts of the product, and that drove a lot of changes.”

Among the changes, Atlassian opened up new APIs, including one for feature flag integration. Already, companies such as LaunchDarkly, Optimizely and Rollout have integrated with Jira. “Feature flags and Jira moves [companies] from software factories to labs. Developers get autonomy but executives can see the rollouts aren’t crushing users,” said Regan. 

One of the key new features in Jira is a product roadmap, which “mirrors the flexibility and customization Jira always had but in one single view,” said Jake Brereton, head of marketing for software cloud at Atlassian. As Regan said, “When you have 10 different teams, all shipping and releasing and testing on different schedules, nobody know what’s going on. It’s mayhem. It’s like writing a book with a different author for every paragraph. It all has to come together and work.”

With the new roadmaps, teams can share their task statuses with their internal stakeholders, so they can see who is working on what task.

Work has been done on project boards in Jira as well. Epics are listed and can be drilled into to see the status of work items. Boards have been re-engineered to enable drag-and-drop workflows, filters and progressions that in the past required developers to write Jira Query Language statements to create. Worfklows, issue types and fields can be customized, without the need to get developers involved. Jira issue functions, the core unit of work, can also be customized to show developers only what they need.

The notions of units of work and developer autonomy are reflected in how the new Jira offers feature choices. “We took the idea of templates and ripped out the features and functionality to turn them on or off,” Brereton said. “With autonomy, teams don’t want strict Scrum or Kanban processes. Let the teams figure out what’s best for them. Kanban zealots say there are no backlogs, but if you want, in Jira you can work with a Kanban board and backlogs.”

Regan explained that the philosophical underpinnings of the Jira changes are based in the fight between developer autonomy and management control. Managers were using Jira to enforce ‘really ridiculous’ process and control, he said. “Atlassian and Jira are siding with developer autonomy,” he said. “We want developers to be able to design the way they want to work, any workflow, build their own board, design their own issue, give the freedom to develop cool stuff, but make sure the project managers and administrators and executives have enough of the reporting and enough of structure to feel comfortable with that freedom. The Jira of the past allowed administrators to be too restrictive. We’re trying to set an example with the way we’ve designed the product in favor of developer autonomy.”