Hating on Jira? Here’s Why You’re Never Too Small To Reconsider

As a young SaaS startup, managing your day to day development tasks is as essential as it gets. And so, although we’ve only been around for about a year, we have already fully migrated to Trello, then to Flow, and then to GitHub Issues in our search for the perfect issue-tracking software. Recently, we’ve made a choice that may come as a surprise to some. We have adopted a tool everyone loves to hate: the infamous Jira.

When we were just starting out, 2-3 developers in the metaphorical garage or more realistically, in a local coffee place that wouldn’t kick us out, we thought Jira would be an overkill. But as the team grew and our product became complex, we found ourselves needing some of the more advanced Jira capabilities much earlier than we expected. Thinking back, knowing what we know now, deploying Jira from day one would have saved us a lot of trouble.

But we asked around, and we knew from experience what “everybody knows”: Jira is a nightmare to install, a bummer to configure, and painful to use. In fact, earlier in my career as a dev team leader, I personally refused to adopt Jira. So what changed? Is it the fact that I’m a CTO and co-founder of a startup? Is it because being a product owner gave me a different perspective? Or maybe it’s just that I’m getting older? Maybe. But there is also a rationale behind it, as I hope to show you.

Not the Jira you think you know

Jira 2019 is not the Jira you remember from the past. It is now available as SaaS and is quite easy to provision and install. It meets all the security standards, and thus far we have had no availability or performance issues whatsoever. We also like the existing features and have not found too many missing features (except in the reporting areas; more on that later).

Jira has made a huge leap forward in its end-user UX and is actually quite easy to use. It can be tweaked even further from the admin panel. This makes it almost as fun as the more lightweight task management tools. It has pretty good Kanban support, better than any other tool we have tested.

While we went for the rich and advanced functionality of advanced Jira projects, smaller teams with fewer demands can use the next-gen projects, which should make things even easier. But that rich and advanced functionality is what helps us get a sense of control in the chaos that is managing an R&D team in a startup. Let’s see what it means for us.

1. Structure

When you start a new project, a new product, or a new company, you don’t usually know what structure you’re going to need. Plus, as a small startup trying to remain lean and agile, an unstructured tool gives you the flexibility you need to focus on delivering your tasks rather than managing the management. That’s why many product owners (myself included) opt for the unstructured option when they first get going.

But as you grow, both the team and the project become harder and harder to manage. At Rookout, we first felt that pain early on, back when we only had 4-5 developers. We observed this pain turning into a major bottleneck when we had ~10 developers and ~4 distinct components and areas of specialization. We had ~50-100 new tickets opening and closing every week, with differing levels of granularity and urgency. And this happened much, much sooner than we expected.

As a product owner, I found myself struggling to figure out who was doing what, what was done last week, and what could be done next week. At the same time, my developers found it hard to keep track of their tasks in an ever-growing, hard-to-groom backlog. The transition to a more structured system, with fully customizable, and sometimes mandatory, fields and automated workflows, helped me and my team improve the quality of our tickets. This, in turn, improved the quality of our code. It helps us stay focused and happy, since we know that we’re doing what needs to be done, and we can show progress over time.

We were able to make this transition in small steps. We didn’t need to bring in a paid consultant and Jira integrator. Nor did we need weeks of training to ramp up the team. Instead, we were going through a gradual, smooth transformation into our personal flavor of CI and Kanban, adding and removing fields and automated workflow options as we need.

2. Automation

Being a dev-focused team, Git is our single source of truth. The only way for me to tell if a task is really done is by making sure the code was written, tested, merged, and deployed into our production environment. And the fact that we were able to integrate Jira into our Github and Jenkins flow meant this now happens automatically. As the code-change transitions down the pipeline, the Jira ticket automatically moves to the relevant kanban column.

A happy side-effect of this is that my developers can keep on spending most of their time in their “happy place” – their IDE. They may look at Jira when starting a new task, to make sure they are picking the right ticket and that they have all the info they need in order to implement it. But once they start coding, they can stay in their IDE. They don’t need to get back to the management tool in order to move and monitor tickets. This makes the fact they’re being managed less painful and gives me a clear, real-time picture of the state of every ticket.

This also aligns well with our DevOps agenda. We invest so much time and effort into building our dev pipeline, monitoring our staging and production environments, automating everything that can be automated, and measuring everything that can be measured. WIP, Lead time and resolution time are a key part of that. The fact that we can automate and measure everything is a huge advantage.

3. Reporting

Speaking of measuring everything that can be measured. On the one hand, I try to avoid graphs for the sake of graphs. It feels like something a big enterprise makes you do to keep the managers happy. On the other hand, I find it helps me keep my team focused and efficient. We use simple reporting to track some questions that are interesting for the team. How quickly do we release features? How long does a ticket get stuck in the pipeline? Who in the team has a bunch of tickets assigned to them and needs help or at least some prioritization?

I used to try and answer these questions by manually analyzing the tickets. Like other manual workflows, it was time-consuming and error-prone. Automated reporting saves me time, so I can be a more effective product owner. I can spend more time talking to my devs face-to-face because I’m not busy collecting data manually. And I now have more time to keep my tickets fresh and my backlog groomed. This way, my team gets high-quality assignments to work on, which also makes them happier.

Besides, we are engineers who like graphs and data. We like performance and stability graphs from our APM, and they help us make sure our production environment is stable. We like an interesting red-green graph showing the health of our CI/CD pipeline. It helps us make sure our tests are as stable as possible. So why not make some more helpful (and pretty) graphs showing our day-to-day tasks?

On top of our APM and CI graphs, we now have graphs that show us that the average time for delivering tickets gets shorter every week; that we deliver more tickets every sprint; that we have fewer tickets getting stuck in staging for more than a day or two; and that each of us has no more than one or two tickets in progress at a given day and no more than three-four tickets at our New column.

The reports we now have show my team how I measure them, what we look to improve together, and how we aim to improve it. The added visibility allows me to build an agile mindset focused on delivering value, not on moving tickets around and getting lost in lists. To be fair, we couldn’t find all the reports we wanted in Jira or in the rich add-on marketplace it brings. We had to export data to a small BI system and use Chartio to present it. It’s not perfect, but Jira does collect all the data we need, and it’s easy to export it using an API.

4. Ecosystem

The Jira ecosystem is rich and mature. Everything we’ve thought about doing, someone has already tried to do. People have already posted about it, and the post has long been answered. It’s also very likely that the answer has a step-by-step guide, and sometimes an add-on has been developed. As we worked to build the Structure, Automation, and Reporting described above, this was a huge help.

While not all of the guides and add-ons were exactly what we needed, the fact that a rich documentation and forum ecosystem exists really helped us ramp up much quicker. We still tweak Jira every now and then, and the tweaks are less painful than they could have been.  Our initial assumption that we would be spending too much time installing and configuring Jira was based on our own past experience and that of friends we consulted with. This assumption was proven to be wrong and Jira’s excellent ecosystem turned out to be a great aid and an advantage for using the tool.

Jira is a lesser evil

Even though we recommend it, we’re very much aware of Jira’s downsides. The admin UX is still terrible and configuration is not a walk in the park. The dev experience is much better than it was 5 years ago, but it’s still not perfect. And yes, the reporting features are lacking. For our needs, we found that building our own reports was more cost-effective.

That being said, it does deliver the benefits some of the lightweight tools don’t bring to the table yet. And you may find you need it sooner than you think. At the risk of sounding like a wannabe Yoda: Structure enables Automation. Automation enables Reporting. Reporting leads to the dark side. Except, in this case, the dark side is an agile mindset with a focus on velocity and efficiency. It’s a fresh backlog and a happy team writing beautiful code without struggling with tickets. Oh, and pretty graphs.

Your developers may still object. But then, no one likes a system managing them, no matter what tool you choose. Jira is a lesser evil. The culture and agility you can build with it will make you and your team happier and more efficient in the long run. So if you’re taking your first steps with a new startup or a new side-project, give Jira another thought.