Why you’ll end-up with Jira anyway

We have been building our development team for quite a few years now, during which we've tried many different approaches to task management. Along the way we have both failed and learned a lot. Let me share that story.

The startup

We started out as just a couple of guys building our first products. We handled work as it came: one task at a time, one project at a time.

At first, Trello was perfect for us. It was quite hot at the time, being both visual and easy to work with. Everyone understood it right away and everyone had an overview of what was going on.

But that did not last. As the workload grew, the height of that “To Do” column grew too. Good luck finding anything there. So we split it. We kept the board just for tasks that were planned soon and created a second one for the backlog. There, we could categorize tasks into different sections.

But still, prioritization was hard. Things got lost. And because of the unstructured process, we could never really estimate when we would get to things.

We promised that we could get to a task next month. But before the next month even arrived, a couple of new tasks emerged. And those were more urgent. So a month went by and our estimate was still the same: next month. Nobody was happy about that.

So we introduced batches. Inspired by what is now a well-documented system called ShapeUp , we decided that if we commit only to specific tasks for the next  6-weeks, we’ll avoid all that pain. We should embrace that we don’t know when we’ll get to something. If it’s a top priority, we’ll do it in the next batch. If not, we’ll reevaluate in 6 weeks.

But Trello was still hard to manage. We had a hard time estimating tasks, and we created a lot of custom fields but at the end of each batch, it was still a bit of a mess.

So we decided to try something new. Get rid of the baggage and move somewhere else. I played a bit with Jira at that time, but it seemed too corporate. Too hard to set up; too slow and bulky. I gave up and decided to try Notion.

Manager’s dream

Immediately I loved how organized it was. Notion is more like an internal wiki than a task manager. And that showed. It was easy to create a dedicated page for each batch, which was an organized task list. Everything was in its place—or was it?

Notion provided a great overview for a manager. But individual developers did not have a good overview of their tasks and statuses. And because our team started adding new members, this was quickly becoming an issue.

We tried a couple of batches and even though I loved the reports I could create after each one, it was soon time to move.

Jira seemed like an obvious choice. So I tried it again. This time I spent more time configuring it and we compared it with the other contender - Asana.

But still, Jira seemed too bulky. Too slow. A bit ugly. So we went with Asana.

Growing too fast

Organizing tasks in Asana was much easier. The killer feature was the ability to have one task in different projects. That allowed us to create different lists based on our workflow.

We had a new project for each batch but kept another prioritized list with all the tasks. The batch list had columns, and the task list was… a list.

But as always, not everything was rosy. We started noticing the issues the 6-week batches brought.

Often there was an urgent task that needed to be done sooner and it was not possible to wait 6 weeks or longer. So that disrupted our process and again, we were unable to keep promises because something else needed to be pushed.

We also discovered that estimating a given project for the 6-week period is quite hard. We now understand that if you want to be able to do that, you also need flexibility in scope. The team needs to be able to make decisions on what to keep and what to remove. And because of a complex stakeholder structure within our company, we did not have that flexibility.

In the end, it was obvious something needed to change again. This time the biggest pain point was the long batches. To get better estimates, we decided to shorten the period significantly and we adopted 2-week sprints. With those, we could get a much tighter feedback loop on our planning and we’d be much more flexible in accepting urgent work.

Our team grew as well. We needed more developers and with that, some help to manage the whole process. So we also hired our scrum master.

While all this was going on, we started working on some bigger projects with larger teams. As a result, we needed to divide our work even further. We started using subtasks a lot, but that started to create some headaches. It was hard to process them in bulk. They did not have the custom fields we needed either. So managing all the tasks was again a bit painful.

This time we had someone experienced with Jira on the team. And it was the right time as Atlasssian also created a modernized NextGen version that looked much more approachable. So we switched our task manager again.

Agile our own way

One benefit of switching the system from time to time was that we were forced to clean our backlog. We moved only what seemed critical and left the rest. Of course, you can do that without going elsewhere but sometimes you just need the extra push.

Having a dedicated team member taking care of the tasks helped a lot. We also introduced story points to estimate our work and got much better at managing expectations. We never adopted Scrum as a whole. As with everything we do, if we see a problem, we fix it. We look at how others are solving the issue and pick or create our own solution. Always push hard against bureaucracy and processes that are not solving real problems.

There was one (last?) piece missing, though. We estimated the work during meetings, but in one meeting you can’t understand the project as a whole. You don’t have time to think through all the implications. And you don’t have time to push back on the original assignment with suggestions on how to make it cheaper.

Developers or designers can’t modify the scope themselves. But we can easily have discussions with the project managers and check if the difficulty we estimate is in line with what they expected to invest. And if there is a mismatch we can start over looking for a better solution. But to do this well, we needed time. So now with any task we start, we first plan a technical analysis. It’s a separate task and it’s done during a sprint as any other work. In the end, we have a much better understanding of what we are building and what it’s  going to take. We can easily share that throughout the company.

So here we are. We went a long way to get to our current setup. It’s far from perfect, and it will change and evolve. For example, we are now looking at Linear as it seems to bring better speed over Jira but is missing a lot of things we are currently using.

Throughout our history, we tried to avoid Jira. But we ended there anyway (for now). As your team grows, you’ll start valuing things that are well known, flexible and powerful over things that are modern, good looking and easy to use. You’ll have someone taking care of the whole system and a bit extra complexity in setup and getting-used-to won’t matter as much.

But I don’t think that anyone should start at the end. If you are just starting out with a small team, start with something simple and fix problems as they come. Don’t resist change and don’t try to over-optimize things. But make sure to hire great people that care about doing good work and listen to them when they call for improvements.