While maybe not the nicest way to phrase it (and I think you know that), I'll take the bait and tell you how I think we differ from Trello:
- Crazy amounts of hotkeys. You can do everything in Kitemaker without using the mouse. It feels pretty awesome to move issues around the board, assign them, etc. all with hotkeys. Also like many modern products we have a command center (ctrl+K or cmd+K) where you can do everything.
- Our issue screen is quite a lot more powerful than Trello's card view. We've talked to many teams who use Trello and they rarely have much content in their cards. In our issue screen, you get a rich document part (feels quite like Notion, with a lot of things you can drop into the issue like images, Figma designs, etc.) and an activity part (with threaded comments, a history of what's happened with the issues, updates on relevant information from integrations, etc.)
- Better GitHub integration. Our issues actually have issue numbers, so you can do things like "Fix ABC-123" in your GitHub commits and our automation feature will move the issue around the board accordingly (you can set up different rules for if such a message appears in a PR, a commit in master...er main, etc.). We show any activity in GitHub related to the issue right in the issue's activity feed as well.
- Better slack integration. Mentioning issues in Slack automatically attaches the conversation to the issue and also provides useful info about the issue in Slack
- List view. You can see issues in a list instead of a board if that's your thing. Nice for use cases like backlog grooming.
And we're moving fast and adding more useful stuff all the time without becoming too complex or unpleasant to use.
So yes, we have a pretty board and pretty boards tend to look like Trello. But there's a lot more to it than that.
If you haven't noticed the chorus of trashing Jira for the sake trashing Jira in this forum you aren't reading it. It borders on the hysterical. A large part of this crowd believes they have an objective handle on cognitive bias yet most of the Jira commentary seems to come from the subjective experiences of developers who simply don't like having their work organized or fixing bugs. Jira is the most extensible, best platform of its type for workflow management & I would argue (without at all being linked to Atlassian in any way other way than having seen it succeed in numerous disparate use cases) that bad experiences with it are the direct result of not having any idea how to use or configure it correctly to model the work being done.
That's all well and good, but being a foot soldier engineer in a big company, I don't have any influence in either how it is configured or how the work is being modeled. I just know that the page loads took multiple seconds and converted a sub-minute task of updating status or checking information into a multiple minute task.
I tend to track my personal workload in a text file at a more granular level. When my team's project was approaching a deadline and a crunch and I needed to stay synchronized with the developers working closely with me, I transcribed this list to Trello. I showed it to the PM as a curiosity and the next day all of the cards had been printed out and affixed to the wall with masking tape. That's the type of environment a lot of us are working in.
The problem with JIRA is the culture that it encodes and enables. It's rooted in the belief that programmers are factory line workers who aren't smart or organised enough to keep track of their own work, so invariably control of it gets assigned to a "project manager" who then spends far, far too much time engaged in busywork. You end up with hard-coded workflows that don't match how people actually work and the people who need to actually use the workflow get frustrated.
Fundamentally JIRA is an over-grown bug tracker. A bug tracker should be designed, built, administered and used by programmers and only programmers. Project managers should not even have access to it, in my view, let alone try to use it to create reports or control the team.
Typical problem I face in my JIRA shop: there'll be no way to move a task straight from "to do" to "done". You have to move it to "in progress" then "in review" then "in qa" then "done", even if in fact, the ticket just tracked the need to do a quick code cleanup that happened to get done as part of some other task. There's no justification for this type of thing beyond over-empowered project managers.
You believe that Jira has "encoded" that culture in your company, not that your company has encoded it's crappy culture in your Jira implementation? Please see: https://en.wikipedia.org/wiki/Conway's_law
I saw how that culture evolved over time as the company got bigger. It didn't start out that way. JIRA was once a bug tracker for us. It became a some sort of flowchart madhouse with horrifically convoluted processes around it. Partly yes, because the company felt a need to hire project managers, and partly because the tool existed and therefore there was something for them to fiddle with all day. If they didn't have the tools to create over-engineered processes, it would be less likely to occur.
At some level, yes, JIRA just enables problems, it doesn't directly create them. On another level, its whole structure encourages that way of thinking.
Part of the reason people complain about jira is because their own company has tweaked it so much it became slower than a turtle and is riddled with all those random fields their upper management requires to make some meaningless reports.
Jira Server is really hindered by the centralization of its workflow management administration tools. You cannot have "workflow admins" that can change issue type schemes and stuff like that for a subset of projects without giving them full admin rights.
Imagine having a guy in Dev that can fix your workflow so that "Start working" is not hidden in the dropdown menu.
I don't have to imagine it. This is a textbook example of a Jira implementation failure not a Jira failure: "not having any idea how to use or configure it correctly to model the work being done."
i am completely fascinated by this response. it is literally so dense with self-parody and hacker-news-ness that any attempt to quote it, analyze, refute, or satirize it in any way would only dilute the message.
I think if you need a tool to "keep them honest" you may have a major culture problem in your company. We started our company to make a tool where people collaborate to get stuff done together, not to be a place where managers keep tabs on their people.
That being said, despite that I personally don't love Jira I do think there are some cases where you need particularly complex workflows (e.g. compliance use cases) where Jira's complexity is fully justified.
And we know our tool is not for everyone. If your team is happy using Jira, power to you. But I think it really is important that the team is happy with it, not just the bosses.
> I think if you need a tool to "keep them honest" you may have a major culture problem in your company.
What kind of organization doesn't have real OKR's or performance metrics? Do you draw a pretty picture with sunshine and rainbows and report that to investors?
- Crazy amounts of hotkeys. You can do everything in Kitemaker without using the mouse. It feels pretty awesome to move issues around the board, assign them, etc. all with hotkeys. Also like many modern products we have a command center (ctrl+K or cmd+K) where you can do everything.
- Our issue screen is quite a lot more powerful than Trello's card view. We've talked to many teams who use Trello and they rarely have much content in their cards. In our issue screen, you get a rich document part (feels quite like Notion, with a lot of things you can drop into the issue like images, Figma designs, etc.) and an activity part (with threaded comments, a history of what's happened with the issues, updates on relevant information from integrations, etc.)
- Better GitHub integration. Our issues actually have issue numbers, so you can do things like "Fix ABC-123" in your GitHub commits and our automation feature will move the issue around the board accordingly (you can set up different rules for if such a message appears in a PR, a commit in master...er main, etc.). We show any activity in GitHub related to the issue right in the issue's activity feed as well.
- Better slack integration. Mentioning issues in Slack automatically attaches the conversation to the issue and also provides useful info about the issue in Slack
- List view. You can see issues in a list instead of a board if that's your thing. Nice for use cases like backlog grooming.
And we're moving fast and adding more useful stuff all the time without becoming too complex or unpleasant to use.
So yes, we have a pretty board and pretty boards tend to look like Trello. But there's a lot more to it than that.