Crazy little thing called Jira

As an Agile coach, I have learned to consult the Agile Manifesto whenever I get stuck on how to proceed.  When I changed firms, I moved from a company that used Azure DevOps to one that used Jira.  It was a bit of a shock.  Fortunately, after working with the tool and reading the book “Agile Software Development with Jira,” I feel comfortable enough to work in a busy software shop that uses Jira.  The experience gives me additional insight into the differences between the two tools.  I want to talk about that insight this week on the blog.

Before I begin, it is necessary to have full disclosure. I have spent the majority of my career working with Microsoft products.  In 2008, I made the switch from Visual Source Safe 2005 to Team Foundation Server.  I have worked with the tool as it has grown and changed into its current incarnation, Azure DevOps.  I also know members of the DevOps “Blackshirts” at Microsoft and one of my mentors for the last ten years in this business runs a blog called “The TFS Whisperer." In short, I have a severe professional and cognitive bias toward Azure DevOps.  I have even authored a blog defending TFS from a blogger who considered it “destroying development capacity.”  If I were the CIO at a company, I would prefer Azure DevOps vs. Jira.

Now that I have confessed my bias, I will try to set it aside and compare the tools.  The first thing that sticks out to me about Jira is the ability to configure it.  When you create a project in Azure DevOps you have three off-the-shelf templates: Scrum, Agile and CMMI.  The templates can be customized, but they are clunky and require a developer to do the work.  In my ten years working with Azure DevOps, I have not been able to do that task.  With Jira, they have the concept of workflows and are configurable.  I have witnessed project professionals fight about the configuration of workflows.  Azure DevOps allows you to configure boards with custom status columns referred to as “board columns,” but to update them, you have to view sprint backlogs or product backlogs to change them.  I consider this a severe product limitation and hope someone from Microsoft can show me how to do that in a story or bug form.

The next issue is that Jira has three types of backlog items: bugs, stories, and problems.  Azure DevOps only has two.  In Jira, issues and stories behave in the same way.  I find this confusing, and I am observing my development community creating “tickets” with no preference for them being stories or issues.  Off the shelf, Jira does not have tools to track git push/pull data.  You need to install a “hook.”  Build automation and CI/CD features are also absent.  I find this absence to be a central stumbling point for Atlassian.  I should be able to track a story with code changes and build information seamlessly.

Finally, Jira appears to be very good at an individual project with one team, but it needs to improve at scale.  Issues, Bugs, and stories can fit into Epics, but there is no concept of a “feature” or “area” in Jira.  It makes it hard to “roll up” stories into Epics for the business to see easily.  It also makes it hard to manage large backlogs because a backlog can only accommodate one team.  If you are attempting SAFe or LeSS, you struggle to see dependencies between teams and how they lead to more oversized products.  I am sure this is my lack of experience showing.

I do not consider Jira an anti-pattern or a necessary evil.  It is just a tool.  Like any tool, it can be used in a harmful manner and create severe damage.  As a coach, I need to be able to respond to change by following a plan.  Jira is certainly a change from how I am accustomed to working.  Fortunately, my agile coaches and mentors have given me an excellent working knowledge of managing a backlog.  If the stories and vision are explicit, it does not matter what project management tool you use.  Jira is good enough, and I will accept it because the working code in production is more important than the work item tracking tool, which manages the process.

Until next time.