Hey folks. My co-founder and I started noodling on productivity tools a few years ago. After interviewing 250+ engineers and founders, we discovered that most project management software a) takes a lot of time to configure b) is not built for cross-functional teams and c) takes away focus from the release cycle. The status quo is that engineers spend precious time wading through tickets, and EMs + PMs continue to lack visibility at the release level. This only gets worse with distributed teams across different time zones, and as teams outside of engineering rely on product to meet customer milestones and release dates.
Currently- the tool helps run and manage tasks, requirements and sprints. With team level insights and a smart indicator for sprint planning.
This is our open beta. RN Github integration is live for PRs and commits tied to sprints- we're still working on Bitbucket and Gitlab.
I work at a place with mobile apps. You can't continuously release a new app update every day so a release cycle is useful for structuring when we're going to ship, when qa starts to test, and having deliverable dates in anticipation of app store/play store approvers (couple days)
>most project management software a) takes a lot of time to configure
Every project management software will have some reasonable defaults that can get you started in no time.
The problem is that every company (and certainly any company with more than a handful of employees), at some point, will want to adjust the tool to their use case and that's where the complexity comes in. If you can't adjust things like statuses and workflows, then you'll have issues with adoption.
All the best, this is an incredibly crowded and competitive scene.
This. This is what we think about, constantly. How do we maintain the low to zero config teams ask for flexibility. We are a few apple engineers on the founding team (I'm not), and they really want to follow the approach set by Mac OS. Overall, Tara won't be for everyone, but it's a fine line between balancing the intuitive simple design and use case adjustments/workflows. Could be considered a matrix with several trade-offs.
Do you offer tools/services to folks who want to transition off of JIRA? How painful will this be? How long would it take? How many resources will folks require?
These are some questions potential buyers will have, specially if they are transitioning from a tool like JIRA and related suite of tools. It might be a good idea to capture this on the homepage.
It’s a nice looking tool, but the marketing feels oh so very Enterprise Agile(tm) in ethos.
“Run your weekly sprints on time” — as opposed to them taking two weeks?
To achieve predictability, something has to give. It’s usually “learning” which is never on the plan.
The next release will be done when the right top priorities are met well enough. When’s that? You decide by prioritizing how many priorities are in the release and your bar on quality.
Focus on execution? Why not on building the right thing, and building the thing right?
The thing to manage isn’t tasks, requirements, and sprints. The thing to manage is: “Is this team effective, enough to be trusted?”
As a manager I follow two principles that help me to prioritise tasks for a weekly sprint.
First, every project has three levers: budget, timeliness, features. Choose two. So it's not about not trusting the development team. It's about understanding the tradeoffs and how the delivery date will be affected.
Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable. Likewise the estimate of what you can achieve is more reliable in a one week sprint than a two week sprint. Being able to break fully deployable commits into smaller chunks (up to three days coding time) is a skill that gets better with practice. But sometimes you just don't know how long something will take because it needs breaking down and investigating. One week sprints are ideal for timeboxing investigations; here the output isn't software but discrete software tasks that fit in a one week sprint.
Ultimately it's not about trust, it's about accountability and predictability. Sprint planning tools when used appropriately don't constrain engineers, but rather highlight the truth of how things are going.
Sorry, teams can't be only devs. That's IT or something, and implies that tech isn't the business.
Team has to include 'the business', as in, voice of customer, features lens, in those tradeoff prioritizations along with what do we engineer, and what's the truth of where we are on the field, for delivering what satisfies the customer and our constraints. // Hat tip Rands in Repose.
As for "Ultimately it's not about trust, it's about accountability and predictability" that's precisely the characterization I reject. Accountability means you earn your keep by being effective. Predictability, well, milestones come and go, the software gets used forever. That's the predictability needed, which goes right back to effectiveness. You won't magic either of those in a Jira.
The team I work in has a product manager, a designer, a cloud infrastructure automation engineer, as well as seven software engineers. Together we collectively advocate for our users and help with those tradeoffs.
> As for "Ultimately it's not about trust, it's about
> accountability and predictability" that's precisely
> the characterization I reject.
How do you know if you're effective? Perhaps it's a difference from one company to another but I don't think it's unfair that my manager (and others dependent on my team's output) want to scrutinse my decisions, and the outcomes of the team.
Likewise, I can scrutinise the choices of engineers with weekly sprints, to ensure the goal is hit i.e. a timely release with flexible features, or a feature complete product that might overrun.
JIRA doesn't magic effectiveness, agreed. It can help show the truth of the decisions taken toward a goal and how work is progressing. I'm not advocating waterfall (any estimate of "this fully specced feature should be finished in two months" is pure fiction) but JIRA or other similar products can work to let managers know ahead of time, "We're not going to finish this by our initial estimated delivery date." That's a useful tool.
I’m starting to be fairly confident that the ‘budget’ lever for a project might as well be disconnected from the feature and timeliness ones. Spending more money doesn’t make things go any faster. Especially adding more people makes things fo slower.
Completely agree on the not going any faster point. The Mythical Man Month demonstrates this exact concept perfectly.
The budget lever is still available in limited forms e.g. do you devote two engineers from the team to project A or three? The point here is that the engineers have to be already up to speed on the codebase and already know how to work with their colleagues; and adding more on project A leaves fewer for project B, C, and D etc.
Also there is monetary budget. Can I solve an engineering inefficiency by throwing larger servers, or buying a licence for a relevant software service?
It is connected... until the project start, eg. in the broad general planning phase, when you press "start" it gets disconnected and stays that way until you ship a usable (±new) version.
Once the wheels are in motion you can only accelerate by breaking off sub-projects/teams... but if you're at a point where this can accelerate you, it means you were already slow-as-hell :|
> Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable.
I’m not so sure that’s true. I mean, it’s probably not worse but often I find that my gut feel of “it’ll take for weeks” is more accurate than trying to break the feature down beforehand and add up the parts. I’ve always said that the estimation process rests on the hope that if you break a big wild-ass guess into a lot of smaller wild-ass guesses, the errors will cancel out. I don’t think that’s always the case.
That's non-negotiable to me. You can make a short-term decision e.g. this implementation will only scale for the next month, but automated testing, clean code, other standards must be maintained.
I think I have to agree. I understand the impulse to say that it's implicit, and certainly the desire to build a quality product usually is. But in reality, to actually verify quality before you ship often requires a lot of costly infrastructure and time-consuming work. So in practice, it really is a lever that often gets sacrificed---usually at the alter of the timeline. You could argue that a feature that is broken isn't a feature, but there are many subtle degrees of broken-ness. A bug that happens 1 in 1000 times might be acceptable, or it might not.
...if you consider quality a lever, you're not the kind of person anyone should want to work with!
You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!
You could just as easily say that you agree on the feature set beforehand, and you deliver that feature set, not more, not less (you deliver sooner if you finish the features early).
"The quality level you agreed beforehand" is meaningless without some infrastructure and processes in place to verify it. And in practice, those infrastructure and processes are compromised at least as often as the feature set, the budget, or the timeline.
Quality is implied within the feature/scope grouping. Its always a three leg stool trade off for balance. Changing your quality output is just reducing or adding to scope requirements.
Budget = Resuorces / Time = Time / Scope = Quality
Quality could be grouped with features as "usefulness" of the software. Low quality software is unusable, or more expensive to use.
Timeliness has an equally direct impact on software value, but in this planning context it makes sense to distinguish what is delivered and when it is delivered.
As someone who makes this type of product, I tend to hate this industry. We make things far more complicated than they need be. It's all just ticketing software with labels changed and I just want a list of all the tickets for me to manually filter. I'm tired of companies thinking I don't know the best way to see the tickets I want to see.
I'm personally not a fan of ticket systems in general. They're often abused and simply turn into the worst kind of micromanagement and pressuring tools instead of simply acting as a tool for project management complexity.
I'm not against these tools in theory (though Jira is a bit convoluted and overly complex for most simple projects) but I am against how they're widely adopted and abused in practice by businesses to enable terrible internal development cultures or perverse development strategies.
These are the types of tools that when abused, lead to swaths of developers working 50, 60, 70+ hour weeks and burning out. I'd say they're more frequently abused than they are used as aides.
This is an exact reason why I decided to make another task management tool (recently showed here on HN), where you can simply create tickets, assign tags and get everything filtered. I would highly appreciate feedback if you decide to try it.
I made this for Jira. It just ingests all the issues in the project, and displays them in a big list, sorted by a variety of factors (is it assigned to me? Is it in progress?). It generally allows me to just go down the list of issues until there’s nothing left unfinished.
At some point I realized that there’s just no stopping enterprise from going to use Jira, so it’s better to work around it.
We're actually building something fairly simple in Smartsheet, which has Gantt, table, and kanban views that can all be filtered. It's slightly more sophisticated than just tags, but our business model requires Gantt integration, unfortunately.
I wish I could be off of Jira and all of Atlassian. Sadly, that is not my decision to make.
Atlassian's antics with Jira, Confluence, and BitBucket have really started to make me mad.
Jira is changing it's editor... slowly. The old editor had nice shortcuts, like h1. - h6., {code}, {blockquote} etc. When you create a ticket - it's the old editor, but when you edit a ticket or write a comment, it's the new editor! This new editor has none of the markdown-ish shortcuts the old editor had.
Confluence is also changing it's editor and the old wiki pages do not have a 1:1 match to the new wiki pages. This means you have to go through each page, convert it, and edit it to fix the broken things - because depending on what you use, it will be broken. For example, there is no longer a note, warning, or error macro - instead it gets turned into a info macro that you have to go in and edit it to the style you previously had. Code blocks no longer let you pick the color scheme you had, instead they're all generic. There's even more here I'm not listing.
Confluence has also just been wonky lately. It's supposed to automatically format a link into something nice (e.g. https://confluence/page-name -> Page Name or https://jira/AAA-1234 -> AAA->1234) and this only happens sometimes. Other times I'm finding the page frozen or slow and the only thing that fixes it is refreshing the page or publishing the page and going back to edit it.
Of course with BitBucket I dislike that they're dropping Mercurial. I understand why, but I am really going to miss it. Git is way more powerful but Mercurial is (at least to me) way easier to use and pick up. The infuriating part is that they offer no tool for converting existing repositories whatsoever. Github has a tool that will turn your BitBucket Mercurial repo into a Github repo!
For any tool that aims to be an alternative to Jira / Confluence / BitBucket, please don't do what Atlassian does. If you are going to make any transitions or any major change - please make it as easy and seamless as possible for your users.
Definitely. From a buyer’s perspective, Atlassian is awesome. It checks every single box of requirements a development team could give to an “IT department”.
This is particularly prevalent where you have software teams working in a non software business. That’s an environment where you get execs pushing for ‘unity’, whatever that is, and every team must use jira (or Monday/notion etc).
Even worse, often they’ll expect you to use jira without the software specific features.
When my org tried this, it was a good test of my influence outside the dev team.
Why do you think it’s a silly reason? I don’t want to spend a lot of hours every day working with something I genuinely dislike.
Don’t get me wrong, I know I’m fortunate enough since I get to pick and chose, but the time we spend on project management, even as developers, isn’t exactly insignificant.
Having come from a JIRA/Github/Confluence setup in my previous role to a Phabricator setup in my current role, I can't believe I'm saying this but I'd give anything to have JIRA back.
Would you like to elaborate? I haven't properly used Phabricator yet, but have so far had no problem (maybe even a bit of joy) browsing https://phabricator.kde.org/
I've found that phabricator seems to lack support for more complicated workflows so you end up having to hack together things using tags/workboards/milestones to mirror how your process works. This could be a positive though if you've suffered through really crappily configured JIRA projects.
To phab's credit, the web UX of phab is more respectful than JIRA (10 second load times anyone? constantly (re)moving things) but I've used go-jira[1] for the past 2 years to great effect and there's simply no equivalent of that for phab.
It could also be that I'm just stuck in my habits and don't like change - or the way my current orgs phab install is configured (I've never been a JIRA or phab administrator so I don't have much insight here)
I'm happy that you are able to open Jira editors. Today I wasted half an hour to discover I can only open "My Work" (the timesheet summary page) if I'm on an issue page, not from the blank main page.
As a smaller team, we never had good luck with the hyper-complexities of JIRA, we were stuck with Trello (and/or a simple Notion Kanban board) for a while. But Tara's really worked the best for us.
I personally, really like the personal dashboard for every developer on the team, flagging all your main tickets, PR's, and your teammates commits. I'm hoping for awesome things here.
That sounds like a more realistic description than "alternative to Jira".
Jira is an Enterprise product which means it is designed to tick every feature checkbox any company could ever wish for. It integrates with whatever (Enterprise) ecosystem is around it.
We have also been really eager to try Tara at our company. Everyone who tries it says this is wayyy better than Trello, Asana, and Monday. Glad to hear it's worked well for you.
Apparently Atlassian was aware that most customers didn't need all of that so these days they are rolling out 'next gen' projects where one of the incentives was apparently to expose less configuration and make things less complex. The setup of a such a project is now a couple of clicks and the defaults seem pretty sane.
> With your permission, we will collect location information from your mobile device to [insert purpose]. You may turn off this feature through the location settings on your mobile device.
Kudos for the release! This comment might seem counterintuitive, but I think Tara's adoption would grow a lot if you offer a way to sync or import from JIRA.
JIRA sprint planning is painful. In my current company, we use it, and its shortcomings shape our way of working. I.e., not able to link histories' subtasks to a sprint, causing that the backlog is full of long histories, and you need to go looking around to see how the histories are going.
If we were able to sync epics and histories (JIRA <-> Tara), we could probably have the better of both worlds. I see Tara very focused on devs, but not all JIRA users are devs. For instance, how would critical bugs - reported by users - be handled in Tara?
I imagine this synchronization as bidirectional, where you write the specs as a list in JIRA's issue description, but they are actionable in Tara. So no more subtasks in JIRA and Tara become a complementary tool that, once you are used to it, you can go with entirely standalone.
Just writing this quickly, with no deep thought, but it was my very first thought after checking your website.
- We've done exactly this for Github <> Tara. We have a bi-directional sync with Github issues, and active issues are converted into tasks in Tara. Basically, if a user wanted to, they could just use Tara as a Github issue tracker.
- We wanted to start with Github, then work our way through more git/source control platforms, and then move to Jira. Interestingly, structuring incoming data from Jira requires a few months of work on data models IF we don't want the user to spend a ton of time labelling. Jira's data structure can be a hot mess to deal with.
- If the sync took a day or even a week of configuration, would you find it worth your time to invest and go through that? Or would yo expect the sync to work instantaneously (like Github <> Tara).
- What would be your expectations on mapping for histories?
It makes sense that you started with Github. I agree too that Jira's data structure is a mess. I've managed one instance for years and any update was a whole mess on itself.
I think the sync configuration should be quick, something that can be bootstrapped like Trello integration with an export artifact.
About mapping for histories, it should be 1-to-1 and each spec to be a list point or a subtask. Nothing fancy nor complex if Tara is the main source of truth, leaving Jira as a way for non-tech users to report issues.
Well done for getting your project out there ! I'm sure its great.
I've commented on this in the past. This is what I want from my "ticketing-software":
-I don't want 100 ways todo things or configure a ticketing tool...
-Sell me the BEST "Software Development PROCESS" with a tool.
-Don't give me a "Great Ticketing-System" !
I want to know what is the fastest, best process to develop software and track it.
All of "these ticketing software" starts with "track , manage , assign tickets" but leave the process up to you... I want to buy an EXPERT PROCESS not a REALLY GREAT TICKET TOOL with x10 options.
I always use the example of the "ultra high-end amplifiers" they don't come with a "Tone-Control" because these companies are THE BEST... my ears can never be better than their in-house "mozart-prodigy-tuning-expert".
Why would I soil my ears by thinking I can better adjust the "tone" of the amplifier that cost $500k :/ I'm buy FANTASTIC SOUND... not a great amplifier with 100 ways to get good sound.
Sorry rant over..
So... Sell me a GREAT SOFTWARE PROCESS - if it comes with software and a ticketing system... so be it. But make sure the software supports the process and I don't want to configure anything but user accounts :)
I am working on SaaS solution in different area. We would LOVE to sell our approach to the problem but then you start getting big customers...
Guess what, each one of them wants this changed that different color, "tasks" should be named "todos" or whatever. Then everything has to have customization options because next customer contact changes mind and the other one is leaving company.
For now our sales reps do loads of configuration for those big customers, but yeah you have to have big bucks to have sales rep do config tailored for you.
One thing that bugs me with development workflow tools is how they never really integrate with the true workflow of developers. Once you have a development workflow with Pull Requests, Code reviews, QA etc, it would be nice to be able to encode it into the
What's the true progress of an issue (ticket, work item...)? Why do I need to remember to set a ticket to "resolved" after a PR completes, and so on.
Every place has a different workflow and they are usually very complex, but these tools (Jira, YouTrack, GitHub issues, Azure DevOps, ...) are complex. They are often configurable, yet they still (as far as I'm aware) fail to integrate the process part of things with the code part of things. At best you have some loose integration between version control and process e.g. "this ticket has these changes" but they don't integrate the two processes so that the state-machine that is a ticket (is it done? why is it not? is it because a PR build failed? Is it because an approval that must be done after merge has failed? is it because the issue has several pull requests associated with it and not all are merged yet?).
I absolutely don't mind complexity in these tools. Having an extremely simple post-it process is good. This is the second best. The process complexity in big enterprises and distributed teams will always be there. If I can configure a tool to make it go away I'm glad. The worst situation is when you have a hyper complicated process and no tools to help. That's the situation many businesses are in. "You didn't mark the two fields and change the state to Y and then send the email to the translation person and notify the regional development person about the change! You have to do that".
Have you heard about Basecamp's solution to this, Hill Charts (https://basecamp.com/features/hill-charts)? It's definitely not an 'enterprise' solution, but I find its simplicity a really good map for the _true_ workflow of developers. That is to say, it's abstract and simple enough to use for devs, while meanigful enough for managers to gauge progress.
Plus, their writeup on imagined vs discovered tasks and how Jira et al give false sense of control when creating tickets upfront is also illuminating: https://basecamp.com/shapeup/3.4-chapter-12
We use JIRA to track our product development with a fairly large team (including 17 engineers) and while JIRA has its pain points, it does have integrations with development workflow.
In our setup, after a PR is merged in Github, the ticket automatically moves to the next “step”, in our case “Ready for QA”.
Beyond that there are automation workflows that accomplish much of what you are asking for here, the issue is that these are complex tools/flows that require a lot of up-front work and continuous maintenance which might not be worthwhile for all teams.
So internally, we're calling it the "task lifecycle". It's going to be a big feature, and the idea is to figure out the true development workflow (that works for 80% of users) and have statuses that update automatically based on Git. We're working on figuring out how to do this well enough, where the user doesn't have to go through complex configuration.
Tickets are for people not machines, they’re used to communicate with the team/PM. All the information in the ticket comes from people (usually developers) anyway. There’s no way for a machine to know if the content of a PR truly represents what the ticket asked for or what the actual status of the ticket is.
I think the only time I’ve ever used kanban in the original form was in college robotics but my understanding is that these tools are supposed to replace sticky notes.
> Why do I need to remember to set a ticket to "resolved" after a PR completes, and so on.
This is my biggest peeve. Every place you have other stuff related to a project, whether it's Trello, Jira, Google Drive, O365, Miro, Confluence, Figma, Travis, CodeClimate, etc etc etc, it's just another ever-increasing set of things to try to keep in sync and up to date.
It makes onboarding new members way more difficult and make everything slower, more frustrating and more error-prone.
We just launched https://treenga.com because of this constant Github mess of product discussions and development details, so we can focus just on product development in one place and just on code in another.
I've been using clubhouse for myself and it's pretty much what I need in terms of "advanced to-do list" but "not as heavy as JIRA".
What I'm more interested in is how project management software like this keeps popping up and I genuinely wonder what the rationale is?
We use JIRA, Trello and Asana at work and between three of them, yeah, things are working. How much more do we want out of them? Not much. Let's just get on with actual work.
But I must be missing something - some market research, some user research where there is a big unmet need or problem that none of these tools are currently solving and not just in "missing a feature" way, but at a fundamental level where it justifies an entrepreneur to jump in and create an entire software from scratch.
I'm not in the domain, so I obviously don't have the data. I know lots of people complain about JIRA (including me), but my complaints don't warrant me to move.
Maybe these companies are targeting "new" users? New companies, new teams, people who are starting projects anew and looking for project management software?
They keep popping up because ticket/todo-list software is a perfect medium for people to project their aspirations for success. People believe if they use that software they will accomplish their goals.
My immediate thoughts are "Yeah, it's working well for you, but I imagine there are considerable numbers of people out there who aren't happy with the existing systems and want something different to fit a different workflow"
It's like a Git client. Sure, you can do it right from the commandline, but some people want something a little different-- and that's why you get clients like GitKraken with different ways of visualizing things.
I've tried 8+ different task tracking systems (though never Jira), and each has had it's merits, but has always been some critical feature missing for me. Be that custom metrics for sorting, performance, looks or something else. So I'm still shopping around.
it wasn't immediately clear to me that the product is still in beta, and was unable to find any pricing information which threw me off.
another question - is there a reason why Github isn't a support authentication method, considering that Github integration is a big part of the product?
But the tool looks super interesting - going to try it out and intro it to our team!
Hey munkay- we're free for unlimited users. Principally, we believe teams shouldn’t have to be limited by user counts when deciding which project management system to use. Most are still clunky and cap at 10 users for free accounts- planning to have a free forever plan for unlimited users (much like Gitlab).
Paid plans may include functionality for enterprise teams, full fledged integrations and/or smart features such as automated sprint management.
Another recommendation is that I see task states are To Do, Doing, and Done. It'd be nice to have a Review state as well which could be used to say it's ready for either code review or QA. This could also end up being a runaway train so it may be better invest time in allowing the user to specify up to x (3?) amount of additional custom states.
I feel this is how Jira took off initially in orgs when they had a really affordable unlimited user tier. When hooked into LDAP/AD, suddenly every employee in the company was a user.
Unfortunately I work at a large company which has 'standardized' on Jira + other related tools. Now that the majority of work is being done through Jira, it would take a world ending event to move away, no matter how good of a product the alternative is.
Disclaimer: I run an Atlassian consulting company.
In most scenarios I run into, "Unfortunately I work at a large company which has 'standardized' on Jira" translates into "Someone set up Jira poorly and now we dislike using it". The thing is that if you replace Jira with any tool you can imagine, the statement will hold true. Jira isn't inherently a better or worse tool than most others out there.
If you're at an org where it feels like Jira is holding you back, and you don't see the org changing tools in the near future, the best thing I can recommend is to bring in an external team to show the org how to clean it up.
Feel free to ping me if you need help (info in profile)
> Jira isn't inherently a better or worse tool than most others out there.
I'm not sure I can fully agree with this based on my experience.
When you talk about Jira being set up poorly, it makes me think about how workflows, permissions, project structures, etc are configured. This is definitely a pain point for me and I'm sure someone like yourself could bring a lot of improvements in this area. I fully buy that Jira is extremely powerful in this regard and it is possibly my orgs's fault for why it sucks so bad right now.
However, there are some other issues that I imagine are not so easily correctable. These pain points are mostly related to how the product integrates with other software - how slow it is, how cumbersome and nonintuitive the UI is, and how absolutely god awful the content editors are - particularly the wysiwyg editor in confluence (seriously bad!).
Maybe I'm off base here, so feel free to correct me. I'm sure you've had more experience with these products than I. However, I have used a lot of alternatives and from the point of view of a simple user, the Atlassian experience is not on par.
Overall I think you're correct, but I want to add some color to your comments:
Integration with other software is going to depend on a per integration basis. Some integrations are done by Atlassian themselves. Some are done by the other software provider. And some are done by third parties. Slack is a great example where the integration is owned by Atlassian, but there are also third party alternatives. The "quality" of these integrations varies, in large part depending on what your specific org needs. In the Slack example, the Atlassian integration has no support for creating issues in Jira from Slack. This is a use case that a small subset of customers want. Does that make the Atlassian integration bad? If you have specific integrations that you are frustrated with feel free to shoot me an email and I can dig into it. Especially if it is made by a third party provider, we're a really tight knit community and I can likely email their CEO and see if things can be improved for you. Or hell, it may even be one we make and something we need to fix :D
The UI is slowly improving, but yes it is not the most intuitive thing in the world. It is also a 16 year old piece of software, where if you look at the UI, the chrome has changed, but the structure has been fairly stable.
Performance is a topic near and dear to my heart. I have given a number of talks about this and for a long time our company branded itself as the "performance and scale" experts for Atlassian software. With good governance, and qualified admin skills, Jira and Confluence can be "fast enough" in terms of enterprise software. Will this be web scale speeds? No. Does achieving web scale speeds provide value for 95% of users? No. The thing to do here is to improve integrations to reduce the amount of application switching that users are doing. For example, if you're a dev, use Smart Commits[1] to interact with your Jira issues as part of the commit message. No going into Jira or BB in the first place.
The editor in Confluence has been a work in progress in Cloud, but they're hitting a lot of issues. Part of the issue here is that providing an editor that is both friendly to an HR person, and to a dev is a complicated challenged. When Atlassian deprecated Markdown from Confluence, I was working for them at the time and published the Markdown Macro for Confluence [2] as a ShipIt project (internal hackathon). This has helped thousands of orgs interact with Confluence via Markdown. At the same time, we're building a Drag and Drop editor for Notification Emails in Jira, and holy moly are there a lot of edge cases and problems that we hit. There are entire businesses that do nothing other than sell make and sell editors. I wouldn't underestimate the complexity involved in this.
Depends on what your timeline is for changes, but you can also learn how to use it and do it yourself.
My experience is that if an org decides to use <HIGHLY CONFIGURABLE TOOL> then they will do it wrong the first time without external assistance. This holds true even for popular tools like Postgres, AWS, Terraform, or even Git.
Anecdotally, I don't know of any tool that is highly configurable that makes it easy for users to set it up and then scale it over time without learning the specific domain knowledge. Jira is no different in that sense. If you have an example of a tool that bucks this trend, please share it, I would love to play with it and see what I can learn about how to better serve users in this type of use case.
I feel that Jira first adds a lot of restraints and red tape, and then makes those highly configurable. I prefer tools that don't have the constraints in the first place.
Ie if in the middle of the sprint a developer finds that some tickets are stuck waiting for some other team and he wants a column on the board to make that visible, he should just be able to add the column.
In Jira if I accidentally put the wrong issue in Done, I have no idea how to get it out... It's the complete opposite.
A physical whiteboard with post-its is rather good. You can use different colors, if each team member has one magnet with his/her name then it can't be on multiple tickets at once, you can draw lines and write words wherever, it's very flexible.
What an online tool should add, besides corona compatibility, is being a good issue tracker. Jira doesn't seem much different on that front compared to almost everything else I've used.
What Jira adds is lots of rules and constraints and imposed structure that gets in the way.
We are in the process of leaving it in favour of Github projects.
Re: the board thing, Jira has actually been trying to solve this problem for years now with a concept called Simplified Workflows. [1] This allows the project admin to create Statuses and adjust their workflow without needing to get a Jira admin involved. The problem with this approach is that every project does something completely different (often times even multiple teams within a project use different processes) and the people working to do higher level planning can't grok what is going on.
The rules get in your way, but as an entire org, they provide value. A lot of what we do is work with large orgs to actually enforce those rules top down on devs. The difference between our approach and most others is that while we agree with the idea of governance and top down rules, we drive the creation of those rules as a bottom up process. This way the devs get to agree on how they want to work, and as long as there is a degree of consistency, we get to tell management that this is the way forward, and we can now report on things while ensuring we're not getting in the way of the devs.
That's what we tried (our teams are self-organizing, as they are in Scrum, so we couldn't do it another way) but the things the teams wanted had hardly any consistency (partly because the products and projects are very different, partly because of the people).
This is where an experienced consultant can help. We often start with what you're describing here as the baseline, and then work to find a middle ground. I would say that 3/4 times we can find something that works for everyone. And it's ok that sometimes people need different workflows. Some Jira admins or managers trying to pull reports will be upset about this but they can be handled once you demonstrate why doing it this way provides more value to the org as a whole.
Large companies in many cases are systems in some local optimum of efficiency. If any part of the system improves, the overall system is worse off. Naturally, there is resistance to any change from the bottom. Change from the top is not done because they only perceive a cacophony of noise from below. Sometimes it is done in an existential crisis.
External consultants are kind of an organizational hack. In contrast to top management they can take the risk of being wrong. In contrast to the workers they are not part of the inter-department politics.
I think you missed the parent's "+ other related tools". My company uses Jira plus Confluence plus Bitbucket, which are each more or less shitty, but they are more or less interlinked. And that interlinking does actually add value. It doesn't matter whether Jira is inherently better or worse than anything else. It doesn't matter whether an isolated Jira installation could be replaced with something else. The network effect keeps us locked in as well.
I did not miss that portion. I wasn't addressing moving away from Jira. I was saying if you don't have a choice in tool, and you're unhappy, then the path forward is to make the experience less bad by getting someone (more experienced/outside your political structure) than your current team to help you.
Jira, Confluence, Bitbucket. By looking at their interfaces and how they are linked to each other technically, you would think they were made by different companies and hacked together after the fact.
We just moved away from Atlassian to JetBrain's YouTrack. Huuge improvement in usability, system administration, cost.
Personally, I don't mind Kira. I also work at a megacorp that uses Jira and the idea that if I found something ten times as good as Jira I could somehow get the organization to switch just strikes me as absurd. We're too invested in Jira. Too many people using it. Too much internal stuff built on top of it. Change is unthinkable.
As a user (ignoring fixable things like our admin set up a state-machine for tickets so you can't move story more than one state at a time...) I mostly just hate that the UI is slow and I can't use Markdown like I can in GitHub and Slack
I had the same "state machine" style workflow with something like 6 steps in it. Combined with the slow load times and clumsy interface, I once calculated that it would take me several hours just to move all of my assigned tickets at the time from state 0 to state 5. Fortunately I was able to switch to a workflow that made more sense.
I feel the two types of problems you mentioned form a feedback loop, each making the other more painful.
> I work at a large company... it would take a world ending event to move.
What's your current Theory of Change[0] for how to affect decisions at a large company? Are you simply "paying your dues" and moving up in the ranks until you've accumulated enough political capital to make unilateral changes in the working lives of your underlings? How much does your individual organizational agility[1] figure into it? Are you, rather, content to let all decisions be made by higher-ups for the rest of your career? How do you suppose your peers model change? Is there any semblance of democracy?
I am curious because project tracking tools seem representative of a whole class of stable, albeit local-optima that don't seem to change as often as they should, and as a company ages what changes are made seem to come increasingly from decision-makers far removed from the tools' impact on the Individual Contributor.
As it's been said, "ambiguity is resolved by actions of practitioners at the sharp end of the system."[2]
I've attempted to push change at a local level (team + department) in various forms with limited success.
Generally, I get a lot of positive feedback and "we should do that!" responses without any follow through.
At one point some of my pushing lead to a significant departmental change. However, within a short time frame, just as everyone was starting to buy in, something new came down the pipe from on-high and became "the thing".
More recently my approach has been to bypass any sort of organizational hierarchy. Instead I've identified a handful of peers who seem interested in these things and figuring out how we can make our lives easier even if no one else wants to get on board. But this only works for things that are not mandated by the company.
Frankly- RN we're more optimized for smaller teams. We lack the admin/user control and SAML functionality that Jira has for larger teams. It should be interesting to see if new teams about to on-board Jira cloud find the heavy config and long load times annoying and consider making the switch.
Majority of teams (for now) switch from Notion for sprints, Trello or Asana.
Well, we happen to have a world-ending event on deck right now, I assume at least some orgs might be interested in something free with a similar feature set to Jira... (of course, if it wasn't also sadistically hard to use and configure that'd be a plus).
How closely is it coupled with Github / Github issues? Would it work as a replacement for something like Zenhub, which is mostly just a facade over Github's own interface? Can you still add replies to issues directly in Github or do you have to do it in Tara?
I would love to replace Zenhub, but almost every other tool would require us moving some key functionality out of Github. We still want to keep all of our issues, estimates, labels, and planning in Github's native issues, while also having some advanced planning and sprint features.
Our Github integration is a two-way sync, so that you can import any open GitHub issues into Tara as Tara tasks. If you update the corresponding the Tara task, the corresponding GitHub issues are also updated, so you can certainly keep using the GitHub issues.
The main benefit of using Tara is that it provides the team a much better way of plan upcoming sprints, and the system also pulls in GitHub PRs to eliminate any blindspots on PRs getting stale.
I'd encourage you to give it a go and try it out to see if it works with your teams workflows.
Hi. I worry that this sort of tool does not benefit engineering very much; in my experience, Jira and other time-management tools are used to allow product ownership and management to request ever-sillier features, while penalizing engineers who do not make themselves legible with constant status updates.
When designing Tara, how did you account for the power differential between the employees who will be using Tara to record their daily work and the managers who will be using Tara to supervise said employees?
So one thing we're working hard to do- is minimize the status updates required. For example- we built a simple home/dashboard where statuses can be updated with one click and individuals can focus on their priority tasks during the sprint.
We feel strongly about minimizing the amount of time spent wading through tickets and updating statuses. Currently working on a few other ideas/features that are related to status changes based on source control. Stay tuned.
As for power differential, the question is how do you instill a sense of camaraderie in individual engineers, and enable managers to load sprints with actual team data vs subjective measures. We're still working on improving this front - but so far - our "home" feature has been liked by both engineers and engineering managers.
Could you explain more? Tara sounds extremely like Jira, both in form and function. The original poster (who is pointedly not answering my question, probably because it is painful and embarrassing) used "alternative to Jira" in the original submission. Other top-level comment threads are directly comparing Tara to Jira. How would you distinguish them?
Painful and embarrassing is whenever I try to ride a bike.
A few quick thoughts on this:
- Jira started out as an issue tracker to monitor issues and tasks - it really wasn't built to handle software projects or the SDLC from the get go.
-Setting up insights and reporting can be a pain. And you need to be familiar with all the jargon (epics, stories, burn-down charts). Overall, it's a ton of cognitive overload.
-I used to just manage my issues on Github vs spending time configuring Jira. I only used Jira when the corporate overloads demanded it.
Here's the take on Tara vs Jira.
- We're zero to low config. There are entire 60 minute videos on youtube on how to setup sprints on Jira. On Tara, it's one click. We're really focusing on minimal functionality maximum impact in terms of matrix, and seeing how we can continue to be low config as we make the platform more powerful.
- Insights are ready and built- in with no setup. Once your github is connected, you can view commits and PRs by sprints
- We shipped our first smart indicator- it basically looks at your past few sprints (x>1 when x is no. of sprints) and tells you if your sprint has been overloaded. We're planning on shipping more smart indicators that make suggestions around effort, etc.
Yeah, and that makes it look like a lead generation button intended to get me to try the thing before I realize that the Free version won't quite suit my needs.
I don't really care if it's a "pricing" page or not. The question you need to answer before I try you product is "what am I not getting by using the free version?" If there's an enterprise version in the works, tease me a little and "Coming soon" a bunch of enterprise-y features in a feature table. Just don't make me give you my email address, go through a confirmation flow, try out the product, and then tell me "if you need more than 1 user, click here to give us your CC".
Does it allow to export all the user entered data in structured format? So that moving out of it is easier if we don't like whatever pricing you guys decide later?
I'm getting double flickers on some pages like https://tara.ai/about/. I'd totally switch over if there was a JIRA importer tool. I've used JIRA for years and would love something similar with a faster and less confusing UI.
Your Jira alternative is currently a better replacement for a limited but important part of Jira features: clearly only an initial, promising feature set that will be expanded and improved. But in what direction?
The more technical side of software development (e.g. configuration, building and deployment of the releases)? Generic ticket handling and time tracking/accounting to expand the product's usefulness beyond specialized software product development teams? Integration with other software and processes?
The key for our platform will always be simplicity. For now, the plan is to head into the technical side of software dev (Gitlab, Bitbucket and integrations with CI/CD tooling), without alienating business teams.
One of the biggest issues with existing PM software is that it's purpose built for singular teams, vs providing utility to cross-functional teams (e.g. engineering and growth). And it's usually overly complex with significant configuration required.
We're seeing early signs of this with requests from teams/orgs to add in marketing, growth and design teams as they need to be in the loop of releases and the overall SDLC.
Would love to get off JIRA but the leverage jira has over alternatives is that there are integrations for _everything_. Slack, PagerDuty, Freshdesk, etc. I wonder how long it will take Tara to get up to speed
We're releasing about two integrations per month (April was trello import and Github bi-directional sync) so we should get there soon! Our speed of shipping integrations is getting faster with time however.
Ahh that's a cool idea- we really need to work on public sprint boards and actually show our weekly sprints and releases. We typically just discuss them on our twitter and our blog. Here's today's release: https://blog.tara.ai/release-log-may-1/
Performance for me is very poor; the app is very unresponsive - you should consider optimistic UI updates. Im based out in Asia at the moment so its the server latency im assuming?
It's a mix of both latency and lack of optimistic updates. We're working on improving our front-end at the moment and some of those improvements relate to optimistic loads and improvements on redux that go in every week.
Hey Tara team. Ben here from Armory (YC W17). Love that you are tackling this very important problem for product and eng teams. We use JIRA (surprise!) as do all of customers. I've long wished I had the time and energy to think about and maybe even tackle the challenge you are facing - building a JIRA-killer. Go forth and conquer! I would be very happy to help in any way I can!
Oh, "free" means "free to use", not "free software". Would've been a cool feature. It also looks pretty cool otherwise, but ... does it contain "AI"? The TLD and title seem to point towards it.
Congrats the on beta! Just a quick question though. Seems like in the about page, you guys mention that the "platform leverages machine learning". How do Tara leverage ML? From the landing page, it was hard to see any features relevant to ML.
We actually need to update our about page - it still shows copy from our older version which was a predictions only product (I also talk about this below) with ref to a question asked about our .ai TLD.
We will be bringing our ML models back into the product for predictions over time. For now, we're really focusing on workflow and design as a platform.
Initially, we were worried that people would think we're putting "AI/ML" in the name/description just for the hype. But hopefully if the workflow/design is good enough, and the AI/ML features follow, customers should be satisfied.
I agree sourceMaps shouldn't be exposed and they also bloat up production code. The reason we have them exposed for the time being is for debugging purposes in open beta and we intend to remove it out of production in our upcoming weekly release.
Shipping source maps allows for better error-reporting instrumentation, and can also be a great help if you need to debug an issue you're not able to reproduce in a local or staging environment.
Tara looks great, trying it out. Also, I love the clarity of the landing page. I apologize if it is off-topic: what product/tool did you use for creating the main video in landing page? Thank you!
Not sure if it's only me. But there's some funky funky things happening on that frontend. There's a white modal that covers that whole screen that pops out at every page load.
Our first version (which failed miserably) was a prediction-only product with no workflow and a minimal interface. Here's what happened:
- Initially our hypothesis was we could build data models that automatically suggested a specification or tasks based on certain criteria the user identified (for e.g. iOS app for video based calling).
- The system would suggest programming languages, frameworks and a set of tasks based on the criteria
- User would immediately reject the suggestions/predictions outright (even if they were based collectively on data from stack overflow and other platforms). This would be due to a number of reasons: 1) Didn't trust the ML models to make the right predictions 2) The predictions were their first interaction with the platform.
As a result- we went back to the drawing board- and realized that to build a true "smart" project management system, we would need to start with intuitive workflows, and pepper in predictions over time based on usage and a team's actual stats. The AI tld stuck, plus we're planning on bringing the ML models to our public version soon. TBD.
We also plan on using NLP for automatic task connect to Git repos/PRs/commits and ML for predictions around effort estimates. But - we're still some time away from the open beta on making that a reality.
P.S. We recently acquired the tara.com domain which took 2 years of negotiations. A story for another time.
One thing that strikes me is that while you present your product as alternative to Jira, both the name and the logo (bluish form looking like an A) hint at Atlassian and Jira.
congrats on the release! I tried a little bit and this looks nice. I like the focus on agile workflow so that people can quickly evaluate whether this is suitable for them. Liking it so far!
although I seem to have a problem searching for task inside my requirement details
Currently- the tool helps run and manage tasks, requirements and sprints. With team level insights and a smart indicator for sprint planning.
This is our open beta. RN Github integration is live for PRs and commits tied to sprints- we're still working on Bitbucket and Gitlab.