Monday, January 14, 2019

Crazy little thing called Jira

Old School Scrum board.
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 which used Azure DevOps to one which 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 which 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 a 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 serious 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 am going to attempt to set it aside and try to compare the tools.  The first thing which 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 it is clunky and requires 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 they 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 serious limitation of the product and hope someone from Microsoft can show me how to do that inside a story or bug form.

The next issue is Jira has three types of backlog items; bugs, stories, and issues.  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 major 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 struggles 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 easily see.  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 time to larger product.  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 serious damage.  As a coach, I need to be able to respond to change over following a plan.  Jira is certainly a change from how I am accustomed to working.  Fortunately, my agile coaches and mentors have given me a good working knowledge of how to manage a backlog.  If the stories and vision are clear, it does not matter what project management tool you use.  Jira is good enough, and I will accept it because working code in production is more important than the work item tracking tool which manages the process.

Until next time.

2 comments: