Jira isn’t the problem. The problem is software estimation, managers who require a date, probability, and ever letting process people touch agile.
Software estimation is basically a useless craft. Rather than focusing on when things are being delivered I think it’s much more important to focus on are things being done most efficiently right now and making sure past obstacles don’t come back. Management often requires a date of delivery for broader strategic planning - which is understandable. However they confuse precision for accuracy. The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. The joint probability of a bunch of very positively skewed distributions “and”’ed together yields a random date skewed way too early. To solve this process people were brought in to “fix” agile but creating bullshit like story points and points poker and burn down charts and pigs and chickens. Then they graft all this into Jira to improve automation, structuring, and reporting.
Agile used to not be like this. Not every project of every org was well adapted to agile, and it required management that gets once you embark on a software effort there’s a lot of indeterminacy involved. Pressure to stay lean and agile should be focused on the present, that efficiency is high and decisions are made quickly, regret is addressed to ensure it doesn’t come back, etc. The future takes care of itself if you take care of the present.
I also like to describe the an uncertainty principle of software development. The more you try to measure it and predict delivery the slower it is, with worse outcomes, less reliably forecasting, with more attrition and burnout.
> Software estimation is basically a useless craft.
It depends on how you're thinking about estimates. Just saying they're useless is arguably missing the benefit of the process.
Estimates are not generally useful in and of themselves (as in, the estimate value isn't particularly useful), but the process around agreeing on the value within a team is. If you're on a team and estimating a task during refinement, and there are wildly different estimates from the different team members, then the definition and/or understanding of the task is wrong and it needs more clarity and discussion. Another thing is that date estimates are problematic, and estimates should more generally be used to estimate complexity, and while they might be linked in some way, they're not the same.
The issue with estimates, in my opinion, comes down to the process after the value has been determined. If it's used as a benchmark or metric in some way, then you get into problematic situations.
I also do disagree with this:
> The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways.
Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.
I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion. Estimation is almost exclusively for the benefit of management is determining when something will be done.
I would say if this is true in your work:
> Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.
You’re probably working on fairly rote easily producible stuff. That’s not a knock for sure - buildings are complex projects but are easily producible and rote, and contain some but not many unknowns. I imagine in modern times (I’ve not tried to do it for about 25 years tho, and it definitely was complex then!) making modern websites and e-commerce stuff is fairly rote and predictable and mostly a design process.
Developing something innovative is full of unknowns that can only be determined by trying to do it. Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. Developing complex business systems as well.
> I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion.
I see your point, but I would argue that estimates are more valuable than just discussing the task because they give you a shared language to quickly define how complex you think a task is, and can also help avoid getting too into the weeds about specific implementation details when talking about the task in general. There are definitely problems that can arise from estimation, but if you're able to avoid them, it can be a useful tool for a high functioning team.
I’d counter further than this sort of estimation naturally arises in any discussion of a problems solution. The challenge arises from the recording, accounting, and aggregation of estimations for any purpose other than the development of the solution - which is important for the purpose of allocation of talent and sequencing of immediate dependencies. The thing is the error bars in these estimates are large and positively skewed so you need to make your estimates about the smallest possible piece of work, and attach as little importance and dependency on their accuracy as possible.
The problem comes when you string estimates together and compound the mistake by assuming a precise estimate is an accurate one. I generally refuse to give precise estimates for that reason.
I don’t think I agree, I think most software is written in the context of megacorps, and it’s mostly complex business logic. Further, an awful lot of developers work in government, military, scientific, big tech, and a bunch of very technical software development endeavors. I think some work that can nominally be called software, which I classified as mostly graphic design and related plumbing in my response is relatively predictable. My web design folks claim they’re very productive in scrum, mostly because it’s mostly about pinning down customer requirements and churning out known patterns. This is not something you get a degree in computer science to do, and I don’t really consider it software development. Likewise, setting up SAP integrations or Salesforce integrations isn’t really software development. It’s something like it - but there’s no development of software - just configuration of already written software to customize it to a context.
I’m sure we can disagree here, but I would note we don’t all agree.
In my experience pinning down user requirements (and then getting feedback on your understanding of their needs, and iterating on that) is one of the most important parts of software development, not just in "web design". It's also the hardest part of "complex business logic", and the main subject of books like Domain Driven Development.
And it's the hardest part to estimate. To make estimates you must first get the requirements clear, but that's a major part of what you were trying to estimate.
I agree, and that needs to be done in both cases. A complex business logic system has an awful lot of unknowns because it’s never been built before. While systems that talk to similar problems might have, businesses are highly complex in themselves and even the users usually can’t articulate how things actually should work or why. They usually can only explain what they like or dislike about the small part they do in their job. That’s much harder than a brand managed layout rendering.
Edit: the hardest business logic is actually brownfield development - where the users who knew why don’t exist any more, and the developers who figured it out have moved on. I think these are the hardest to predict efforts with the least management margin of error for prediction mistakes. It also, IMO distinguishes between a good engineer and a great one. A good engineer can write code. A great one can improve code that been improved by hundreds of different people over decades.
Sorry but your entire point sounds like a no true scotsman to me. The work of developing useful software which most people get paid to do is, in fact, relatively predictable. Maybe we are all truly peasants who do inferior work that you don't dare classify as software, maybe what you do is truly groundbreaking (I already accepted that as a valid exception), or maybe you have been working with people who just suck at estimates.
I’m not saying design based work isn’t real work or has no value. But I don’t consider it software development in the way I don’t consider magazine layout software development, even though it’s complex and difficult work. But it’s fairly rote and mechanical, and doesn’t require any software development.
For instance I consider developing react to be software development. I consider making a chat system in react software development. I do not consider making a brand layout using a web framework to be software development.
As an example, generally in business you classify software development as R&D for accounting purposes. It’s speculative, has uncertain payout, uncertain development times. Website creation on the other hand can’t be treated as R&D. It’s capitalized under a different amortization schedule.
I’m sorry if it sounds like I’m making some qualitative distinction in terms of value or whatever. That isn’t my point. My point is when we discuss software development and software engineering they are about development of software. I think most people can distinguish between front end web development, and say, developing a web development framework as distinctly different pursuits with very different characters in terms of skill sets, riskiness, predictability. You can adopt an expansive view, but you took issue with my statement without taking into consideration my measure.
> Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.
Funny, I've been hearing this constantly over the 24 years of my professional experience as a software developer and I've yet to see it proven true.
Unless we're talking about toy examples like Hello World, developing quality software is devilishly complicated and, in my opinion, downplaying this complexity as an "excuse" is in itself an excuse to compromise quality.
EDIT: Fixed a few words my phone auto-"corrected" for me.
I want to add that if the team is focusing on the present, it becomes clear that estimation is a passive, descriptive (rather than active, proscriptive) act. No ticket has time pressure on it. The manager predicts the future timeline based on how long similar tasks took in the past, on average. No idea if one task will take 5 or 15 days, but 10 of them will take about 100 days.
Once you understand that, there are many very simple ways for a competent manager to get development velocity out without adding work for the developers... and all management actually wants is average velocity and remaining work in similar units.
If your team tries to keep tickets about the same size, ticket throughput is your velocity. At most the devs can slap gut instinct Easy/Medium/Hard labels on the tickets so they don't have to "right size" everything. Either of those (or a thousand variants), when coupled with the pile of work left to do (in the present understanding) can give a competent manager high precision long term estimates with confidence intervals. No need to make it more complicated (or time consuming!) unless the devs tell you they NEED more.
In my experience, teams that focus on the present, and which are in control of their own process (ie adding or changing only when DEVS feel the need) typically end up evolving their own agile process... which is way more effective than OOTB processes like Scrum, and doesn't feel like a burden (the team drops anything that feels like a burden). Teams who have a process imposed upon them, on the other hand, spend years ranting online about how terrible agile is, and waste a lot of time in unnecessary bullshit.
Sad but true. And to make matters worse, those seem to be the same environments where businesspeople make target dates without engineering, and then get angry when the deadlines aren't met.
Put another way, poor management is a human layer problem. No technology (whether process or tool) can solve that for you.
I agree with your opinion. The problem is that managers have the notion of software estimation as a "craft". It should not be considered a craft at all, and once you held estimation to the importance of being a "craft", it is going to be a massive burden. It should be just a numerical representation of your gut feeling and past team experience.
Software engineering always has to account for uncertainty. You may try to deal with it before starting the project (waterfall) or in the process (agile). Management seems to think that by pressuring the team they can just do away with uncertainty and make their strategic planning seems more concrete, and make questionable decisions like publishing untested code. It's a power struggle all the way from the top brass to us lowly devs, but management need to understand that this is always going to bite them in the ass on the long run.
Jira certainly has its quirks, slowness, bugs, etc. but I don't think I hate it (nor my manager). What I hate is 'stand ups', 'sprints' (even the language of it all is repulsive), pretending point estimates are in units of abstract complexity (and then having time for a certain amount of them within a fixed time period sprint), retros, .. I hate 'scrum'.
(Or, because some 'Scrum Master' is going to tell me I just haven't done 'proper scrum' which I would obviously love - whatever non-Agile (manifesto sense) pretending to be 'doing agile' term you want to call it.)
I think it's supposed to go the other way. One adjusts the sprint point capacity based on recent point completion trends. The abstraction should make it harder to over promise because it's disconnected from discrete units of time.
Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.
Because they need an estimate in time units. E.g. marketing needs to plan their campaign for when the new release comes out; management needs to know whether we can finish that potential new project in the time frame the customer needs or not.
Developers sometimes don't think about the rest of the business.
It's the pretence that it's not time that I don't like - not that people try to use it for or need something for time estimations.
I often find myself saying things like 'well it's trivial, but it's going to be quite a slog because xyz' - leave it up to someone else how they want to point that.
E.g. every single endpoint needs to be reviewed and updated to use appropriate status codes, where previously responses have all been 200 with potential error message. API is already versioned, this will be a breaking change but no need to worry about that or the clients at all. -- low complexity, very time consuming.
I suppose high complexity tasks are less often quick, or at least not that you would know in advance (optimise SQL query, identify cause if & fix bug) but certainly low complexity tasks can be very slow.
The purpose of the ambiguity is to keep engineers involved in the time estimates. Otherwise folks may naturally compare the visible portions of some new shiny to previous old shinies, not realizing some massive, hidden differences. If they cut out the engineers then the estimates are guaranteed to be way off.
Pointing and T-shirt sizing aren't meant to make planning impossible. Just impossible to do without involving the workers closest to the work.
Directly using time units could work, yet in practice are too easily misinterpreted as more precise than they really are.
A ticket for each bug or new feature, with commentary including images and videos as necessary, linking to consequent code commits, with a not-done/under-review/complete status field, raised by the reporter, assigned to the responsible person, and indicating the target release.
That is the essence of a good workflow tool, and Jira will do it fine. It is all the extra stuff that seems to cause the grief.
That's the cloud version, the self-hosted version is actually rather good. Atlassian sadly don't really want to sell that anymore and it's only available as a "datacenter" edition at a completely insane price.
Your JIRA instance probably needs to be hosted on more powerful hardware. In my experience, JIRA on-premise is way faster than JIRA cloud (but I do prefer the new UI in JIRA cloud, though that's a matter of preference).
Over-the-wire latency is the tiniest fraction of the time spent in a transaction with Jira (and Confluence). Most of their slowness is due to poor implementation in the client and backend, i.e., their applications.
But at other companies I’ve been at, it’s not a productivity tool. It’s a management too.
Estimates for planning. Which is fine. Until pointless rules appear. We’ll use standard story points. But not 1, that’s too small. So things start at 2. But after a while that’s too small. So they start at 3. But you can’t go over 8, past that they have to be split. And you shouldn’t probably use 8 anyway. Pretty soon everything will be 5s. No matter how big or small. Good thing we point.
And of course the whole point of pointing is to put things in sprints. That’s fine. But then the rules come. You can’t go over your capacity. You can’t go below your capacity. You have to roll over everything you didn’t do. You can’t roll things over. We committed to finish by Junetober 37th even if we’re not ready so it has to go in the sprint now. So now you put things into the sprint after the sprint started and remove things before it’s over so that the magic numbers look correct even though they are complete BS.
But luckily you can track things.
Except every team is forced to use the same workflow even if they don’t work the same way. Because otherwise it would be “complicated“. So the IT tickets have to look like software development tickets. And the planning tickets have to look like software development tickets. It’s important to have tickets to plan your future plans so you know what tickets to make. After all, if you don’t schedule everything 18 months in advance to the day, are you really doing agile sprints?
But you can link tickets. For example you can choose requires, or needs, or is dependent upon, or can’t be done without, or is waiting on. Wouldn’t one thing do for all of that? No one actually knows. It’s an unanswerable question.
Did I mention there’s Kanban support? You’re not allowed to use that. Because.
And all this gets so complicated you need people whose job it is to wrangle Jira full-time. Make reports, add more fields, etc.
Of course those fields don’t make sense in a lot of cases. But sometimes they required. And other teams want them required but aren’t allowed to because everyone has to work the same way.
So the ZRX team invents their own email gateway to put issues into Jira their way. You didn’t know about that right? Because if you add the issue directly they’ll ignore it. Productivity!
I don’t know if it’s fair to call the thing I used at those companies “Jira”. That’s a bit like calling a battery made out of a box full of potatoes a “vegetable medley”. I mean it’s sort of true but that’s not the point anymore is it?
I like actual Jira. It’s a good product. Too bad almost no company will let you use it, only corruptions. It doesn’t exist to do its real job but to instead generate management reports. Which they don’t read.
Yes, but no one can say that. Managers need to go off on project management, team management, and all sorts of other scenic hotel retreats to learn how to use JIRA better because of course the fault is JIRA and the underlings.
Funny thing is that the example given of a "bad workflow" is in fact a fairly basic software development flow:
1. Ready to start (requirements and technical solution direction clear)
2. Working on it
3. Merge (to see if it also works live)
4. QA (typically dedicated role)
5. Regression testing (did we break anything?)
6. Release to Prod.
7. Sanity test on prod.
You could argue that you don't need both "Ready for QA" and "In QA" but for the QA team this distinction can be of value.
This doesn't even include a UX/UI sign-off, security audit, privacy review, and in my case several health-tech related audits.
For a typical developer, you're only asked to move your stories/tasks from 2-4, unless you get feedback from 5-7. That's not too much to ask, it's just basic sanity.
In my experience, that's not wasteful, it's a basic flow of work. What is wasteful instead is endless meetings that disrupt, of which only 10% of the content is relevant to you. What is wasteful is 5 million stakeholders asking about the status of things whilst that is the whole damn reason we have the system. What is wasteful is poorly written stories/tasks that require enormous detective work to understand. What is wasteful is constantly shifting priorities, moving work in and out of a sprint whilst it's already ongoing.
I think the biggest problem with tracking all of that process in a workflow engine like Jira is that a lot of it is redundant.
Merge status is tracked by your pull request/merge review tools.
The things available in QA testing should be known to your CD tools, your Release pipelines, and your QA environments.
QA sign off should at the level of "a release", not the level of a dev task/user story. (Cherry-picking, reverts, and other types of "unmerging" create unanticipated bugs.) It's also most home directly in your Release pipelines.
Same with Production sign off, sanity testing, and rollbacks to previous releases. Those are Release pipeline concerns and tracking it in Jira is at best redundant bureaucracy at that point. It shows either a lack of faith in the reporting tools of your Release pipelines or a management's devotion to Jira over the tools that actually get things done.
Jira does integrate pretty deeply with source control (and not just Bitbucket) to handle release pipelines. I'm sure it's a pain to set up but it's magical when it works and tickets automatically have the right status as they get merged or deployed.
Sure, but you can also have those integrations update the Releases/Versions boards/reports (which is what they were built for) without making them part of (and complicating) the ticket workflows themselves. Even if you have that stuff automated between your primary systems and Jira, you also still don't need redundancy between Jira's workflows and its view of release status tracking.
You can use much simpler, dev-focused issue workflows and still get the benefit of some of manager's eye views that they want. It's very rare in Jira to actually do that because over-configuring redundancy in Jira is easier than the simple life.
(Also, for some personal gripes on this subject, the Jira integration with AzDO is painfully shallow and mostly broken and badly maintained. I realize that everyone should be using GitHub today, but until Microsoft actually admits that AzDO is dead in public, out loud, without hemming or hawing about it and "it still has a roadmap" [eyeroll] there's too much corporate momentum leaving people like me stuck in AzDO.)
I have found having my own, personal, task management system was the foil for this. It is extra overhead, but at least I always have a system that works for me, even if everyone else is mired in chaos.
In my last job, I definitely hated my manager and how they used Jira, but I actually liked Jira for the most part.
What I hated about Jira was that it allowed my manager to decide on an expectation for how it should be used, and though technically it did do that, it didn't enable me to use it in a way that aligned with their idea of how it should be used. It frustrated him that I didn't accept the guilt he was trying to throw at me for not using the tool in the way he decided was important. Also, it suffered from the same problems as any isolated tool; being out of sync with other tools and invisible unless I'm looking directly at it. I never really got the unresponsiveness that others mention, even on an intel MacBook pro.
What I like about Jira technically, is that it has a pretty decent rich media interface for expressing ideas. If I found a bug, or needed to document how something currently works, I could use the native screen recording on my mac and then drag the video file straight into the comment.
It would have been great if my manager wasn't a petulant, controlling, and passive-aggressive tool, so that I could use Jira in a way that better suited the development process.
This article reminds me a bit of the Java advocates who used to pop up in every discussion comparing programming languages and remark that, well actually, Java's reputation as a slow language full of boilerplate is wholly underserved and JVMs are in fact beating speed benchmarks left and right.
And it's not wrong - you can write fast and concise Java if you are very disciplined, know exactly what you are doing and stay clear of most dependencies. However, that's hardly relevant in practice as both the language as well as the ecosystem and the established "best practices" want you to abandon both conciseness and efficiency in favour of some vague goal of extensibility.
I think it's the same with Jira. Sure, you can use Jira as a simple Kanban board, but then, why would you buy a Jira license in the first place? There are cheaper tools for that. On the other hand, even if Jira advocates tell you that insanely complex workflows are wrong, all of the software is geared to supporting exactly those kinds of workflows. So if you're actually want to get your money's worth from a Jira license then you'll have to design complicated workflows and add numerous special fields.
First time I used Jira I was lucky that the company had it setup quite nicely. I really enjoyed it.
One of the things I really enjoy about Jira is the fact that a task and a sub-task have the exact same UI. A sub-task can be easily moved to be a full task and vice versa.
"Hey this PROJ-1234 task is in fact a subtask of PROJ-1111!"
"Agreed! let's move it to be a subtask of PROJ-1111! and here's a new PROJ-1235 for the second part, let's make it a subtask as well"
"Wait, I can't make PROJ-1234 a subtask of PROJ-1111..."
"Ah, I see, PROJ-1111 is already a subtask of PROJ-1002, which indeed makes sense"
"Oh, right! I forgot subtasks can't be nested. So maybe PROJ-1002 is an epic?"
"Sounds about right! Oh wait, PROJ-1002 is part of epic PROJ-223"
"Oh. I get it now, forgot about that epic which tracks things for product item foo"
"Alright, is foo still on track and required?"
"Yeah, it's merely been postponed because the currently worked on project item bar was priorised as we needed a bit more work to refactor and complete foo"
"So now we're set to do PROJ-1234 in the current sprint, and this would complete both foo and bar, two birds one stone!"
"Yeah that was the plan all along, having the design lend itself to that, with proper composition and all."
"But we can't make it part of both epics"
"Correct."
"What if we create a new task and link it with PROJ-1234"
"Could work. How do we qualify it though? It's "duplicated by" but we keep that for duplicate bug reports as there are automated workflows for it, notably a duplicate is supposed to be closed."
"Blocked by maybe?"
"Well it's kind of bidirectional and blocked by is one direction only"
"Drat there's no "Linked to" in the combo box"
"Yeah management wants everything qualified so that they can build reports. IIRC they don't scope it by kind "bug" because marking some tasks as bugs biases another counter, so some bugs stay as tasks, so they can count only bugs reported by customers and not internal bugs"
"Oh right, doubles down on why we can't use duplicate, we'd break the report. Actually I think we can't use the link feature at all because it's really the same task and that'd break their report too"
"Screw it let's just put a link on each one's description to the other. I'll shoot an email to the JIRA admin to see if we can add more link kinds, and maybe fix the automations and reports"
"Yeah, we're already overtime for that sprint planning anyway. Let's move."
"Should we do that at the PROJ-1234 level or at the PROJ-1111 level?"
"Not too sure. Maybe we should have used a checklist for PROJ-1111"
"But then PROJ-1478 depends on PROJ-1234 only, not PROJ-1111 as a whole"
"Ah, right. Maybe we cleaned up the arch a bit too much lol"
"Right? Maybe we should switch to an arch that matches how we can link tickets lolsob"
"JDD: JIRA driven development"
"Hold my beer while I write a JIRA plugin to export task structure as a code scaffold"
"Kill me right now"
"Goddammit time flies, let's finish this. So where are we on PROJ-1526?"
"Blocked, we're waiting on feedback from the user"
"Alright. Wait, there are two "Waiting on customer" statuses now? Which one is it?"
"Huh. Let me look at the browser inspector... Ok, id 17, so I think it's the second one. No idea where the other one comes from."
"Ha. Ok, moving on."
Slack pings
> Hey, meeting xyz has started 10min ago, are you joining?
But it uncritically swallows the idea that the only way to have reasonable transparency is through atomizing work into trackable to-do items. I do successful work of all kinds with clients and collaborators and never come near a Jira.
This is a keen observation and 100% true. A lot of people (both engineers and managers) willingly align behind this regime because the system gives them ostensible clarity on what they need to do, and a paper trail to show how hard they've been working as air cover if anything goes wrong. They are optimizing for comfort and covering their own asses.
Unfortunately, this puts a very low ceiling on the type of problems that can be solved. In fact, it works against creative problem solving because it obfuscates the big picture by drowning out the strategic summaries and narratives needed at different zoom levels for different stakeholders. The devil is in the details, and the only way to get the details right is to have real expertise and collaboration based on higher level understanding. Ideally every individual involved has the highest level goal they are capable of executing on, and is empowered to work out the details collaboratively with whoever needs to be involved. This is easier said than done, because most people—even experts in specific domains and skillsets—are not experts in collaboration and understanding other people's mental models. Management's job, if they are doing it correctly, is to understand these dynamics (hopefully rooted in deep hands-on expertise) and to set up the structure that facilitates the necessary collaboration.
Useful tooling for this problem is context specific, but less is usually more nuanced messaging or vision doesn't travel or align well across large groups of people. Jira does nothing to help with this; it's just not built for strategic planning or collaboration. It shines for tracking a huge influx of unrelated tasks that have to be passed around between silo'ed teams without dropping any balls. This allows project managers and operations folks to monitor things mechanically where the problem and process is already well understood. It offers very little to support higher-level problem solving.
It's a 'remembering' tool - but 'forgetting' is also a valid and productive activity. Some things should be remembered, e.g. important bugs, but other things quite often benefit from being forgotten, like irrelevant feature requests.
It is surprising how many problems can be solved by simply ignoring them - the trick of course is knowing which ones to ignore. To-do lists tend to preclude this strategy entirely though.
Between every PM, every manager, etc, everyone wants to track slightly different information. The ICs can't keep up - they have five people telling them to use Jira just a little bit differently. The bosses/PMs don't feel this tension, they see only their asks, their report they want to stay up to date, they wonder why its so hard. Eventually, ICs see it as confusing hassle (like TPS reports in Office Space). ICs don't know what to do, and everyone gets confused, information doesn't actually surface in Jira, real issues get dropped on the floor, etc etc
The problem isn't that any one of those bits of reporting is wrong. It's actually that the higher levels need to realize they're actually asking for different / conflicting / excessive information and need to have a stronger hand in reducing information reported so to ensure that which is there is actually accurate.
(The insane configurability of Jira and other PM tools just reflects this chaos)
I like my manager and I like our very simple workflow. I do, however, _strongly dislike_ Jira's UI. It's almost as slow and broken as Confluence's UI, and that's saying something.
JIRA's search feature, well, let's just say it's a real gem. Once your pile of tickets grows over the years across a delightful array of projects, attempting to find anything resembles a treasure hunt in the Bermuda Triangle. Good luck with that!
Points about the main problem being organizational aside, Jira has been consistently unreliable in the I’ve 10 years of using it (both hosted and self hosted). It’s a moving target. Right now, I can’t add a comment from a mobile browser (either their mobile view or requesting desktop mode) so I have to use their mobile app, which is very poor compared to the web product, especially for teams with customized screens/workflows. Their rich text editor has consistently sucked and has destructive bugs in it. Despite being logged in, it eats comments and updates all the time with various csrf or authentication errors. Tomorrow it will be something else.
We use cross functional teams so it’s impossible leverage Releases to effectively coordinate releases to software that lives between multiple Jira projects. I’d rather use gitlab issues or whatever, but in an organization with lots of products, product people understandably hate those comparatively inflexible repository-based issue management. So that’s part of Jira or any issue management system is rectifying the strategic (product, project) and tactical (engineering and support). Jira's the only one that comes close (at least that I have used for any length of time) which is why it isn’t going anywhere any time soon.
Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instance as a sort of skunkworks project, because the bug-tracking tool the company had been using wasn't working for them. They set it up to fulfill the basic need for programmers on a team to keep track of their work.
Fast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance.
The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful.
Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.
The problem with Jira is that it's not opinionated enough about what using it "correctly" means. Every company I've ever worked for that used Jira had turned it into a giant foot gun.
I don't think being opinionated helps. TFS is extremely opinionated, and has gotten more so, but I can't say it's better. It's just as easy to make a convoluted mess that doesn't mean anything. It's only real advantage is if you use the full stack of MS stuff the integration between all the parts is really good, where Jira seems like a totally separate entity from your source control and build system. Both have their advantages though.
someone on here a few years back said "You dont hate Jira. You hate that it's a mirror". It meant that Jira just reflects whatever your busines management policies are and I think there is some truth in it.
Nah. I hate how long it takes to load different pages. I hate the UI and how there's a bazillion non-removable fields that don't need to be filled in, but are present. I hate that you can't click on links inside Jira, but almost every real thing is actually a link, so that's unhelpful. I hate how it automagically saves changes.
I hate all software that isn’t a mirror. And yet none of it can be.
I’ve never used Jira but every task or list program that I’ve used does not reflect me and to do it I would have to manage it constantly.
It doesn’t reflect the context switching I do, or all the communication I do outside it to make it work, or my notes on how I’m going to do a thing… rarely is it accurate on my time and so on.
I used to get snotty comments from people opining about how awful Perl was and how great python etc was.
The funny thing when it was time to get something done, I’d be finished by the time they hacked together whatever python dependency shitshow they were buried in.
Perl’s time is in the past, but I wrote a ton of it, and some is still running in production in a few places 20+ years later.
My biggest complaint with all of the Atlassian tools I use (Jira, Confluence, etc.) is how slow and unresponsive they feel. Creating a new Issue requires waiting at least a few seconds, sometimes more, for the newly created Issue to pop up on the bottom left. Editing a Confluence doc requires clicking the edit button and waiting a few seconds while the entire page does, what appears to be, some massive shift to editing mode (understandable that there would be big differences between read and write mode, that's not my issue). I think my perception of and feeling towards the Atlassian tools I use would be, no exaggeration, 10x more positive if everything just felt zippy and close to instantaneous. "Speed is a feature", or however the aphorism goes.
Besides being slow as shit Jira and Confluence have terrible UIs. None of the controls are clear, it's hard to tell the difference between a clickable thing or a typeable thing. Then there's just nowhere you can place the cursor on the same screen that doesn't make something animate or change color.
A mystery meat UI is bad enough but a slow mystery meat UI is just infuriating.
> it's hard to tell the difference between a clickable thing or a typeable thing.
Or both at once, because the description on a ticket isn't a text field until you click it and then it becomes typable (oh, you weren't trying to select text, were you?).
Right! I didn't even mention the actual UI, but I agree. There's no cohesion, nothing feels intuitive. It all kind of feels like it was designed by engineers/developers honestly :)
We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here. It's not a small organization either, so I wonder if it's some misconfiguration that's killing performance for others?
It is 100% possible that it's a config thing... but I've used Jira on-prem with a fairly complex setup and in the cloud hosted version with what I believe to be the simplest out-of-the-box setup it has and both were terrible at performance, so... if Atlassian themselves can't tune it right, I'm comfortable saying it's just bad (or at least) software.
EDIT: Someone else in the comments suggested that the cloud version is slower than on-prem. This might account for things; if I've only seen complex on-prem and simple cloud, it might well be that simple on-prem can be fast. But... that's still concluding that Atlassian themselves can't make their own software performant, so it's not exactly a redeeming quality.
We had a pretty complex on-prem Jira/Confluence/Bitbucket/Bamboo setup with pretty good performance, at least good enough that it wasn't something we thought or complained about. We also managed and used cloud installation for customers, those pretty much always felt slower. We did have a fairly large number of Atlassian certified people in the company, all of which are probably A-tier when it comes to managing Jira, so that might have helped our on-prem performance. It's not like we had massive database and application servers running the software, but we might very well have thrown more hardware at it than Atlassian does per client.
It could be a plug-in. But anecdotally I’ve also heard the cloud version is much worse than on-prem, which if true could explain the big differences too.
I’ve used both Jira and Confluence on premise and Atlassian Cloud. For what you pay (when you pay), the cloud service performance is an absolute joke. It’s god awful slow compared to alternatives, even with small orgs and datasets.
> We use confluence and jira, an d for some reason it seems perfectly usable compared to others stories here.
I've been using Jira Cloud off and on at various startups and it always had its slow moments. At my most recent startup, it's been working very well with no slowness thay I'm aware of (knocks on wood), and that includes all of the stuff I do directly via API.
That's quite possible! I'd love to know what it is. If it's somehow a consequence of the total number and age of stories since our account's beginning, I'm not sure what we could really do about that other than to do bulk deleting which...we really don't want to do.
This times 1000.
We use an XRay plugin for JIRA to create tests, test runs, executions etc.
I shudder every time I need to go into XRay's TCR (Test Case Repository) which isn't even that large (~3k tests in total). The amount of "desync error, please refresh" is bad when viewing but goes absolutely bonkers when actually creating or editing tests.
Not to mention that the actual "writing area" takes maybe 1/4 of the screen estate. I hate this so much in the modern web applications - "Here we have this whole screen... let's make 25% of it actually usable and put useless crap on the rest."
Sorry, I suppose I had to vent as JIRA makes my blood boil.
They want everything to be WYSIWYG and in consequence re-implement almost every browser feature in JavaScript, which breaks everything which relies on the native features. Every time I click on a text area, the cursor disappears. It works if I tab into the text area. Infuriating. And for this it downloads 10MB of JavaScript.
Yup, that was my first thought reading the title: No, my manager is fine, I actually like the workflow, I like the process; it is very much the implementation of jira that I hate for taking good ideas and making them slow, buggy, and unintuitive.
I work in a fairly large S&P 500 company that uses JIRA to manage most of our software projects. While I do agree that the performance of JIRA can leave a bit to desire at times, I don’t feel the same animosity towards it as many seem to. Since we also use GitHub Enterprise, I’d personally prefer to use GitHub for issue management but I can live with JIRA.
Perhaps I’m just fortunate to work under leaders who don’t force a lot of overburdening JIRA processes. At my work each team can setup their JIRA project and workflows, boards, etc. in a manner that makes most sense for them. Teams can use hours or story points, kanban or scrum. The focus is on delivering features and quality (in terms of customer reported open CRM issues not JIRA issue counts). I feel like management is pretty transparent on how they use JIRA and what their expectations are. My boss and their boss openly share with us what they look for in terms of team project health. I feel like anyone on my team could suggest a reasonable JIRA process change and it would be considered.
In my first month as VP at a growth stage startup, I asked everyone in Engineering why we used Jira. The responses all boiled down to what was basically a shrug. I followed up with what they felt we should use it for and the universal answer was just to be a scrum board, so I spent a bunch of time removing fields and nearly all workflow steps and rules enforcement except in cases where a particular team wanted them. This ruffled a few feathers of folks who loved making tools do all the work, but the improved QoL and happiness the team at made any objections moot.
Similarly,I asked all the external stakeholders what they wanted out of the Engineering team, and the common answer was regular delivery of features and products. So now that's what we're optimizing our process around, and (not a surprise) that's been more of a "make the product team focus on fewer things", reduce architectural debt, and automate more things kind of effort.
Now, estimation is still a big part of this, but it's used mostly for capacity planning and to gauge the effectiveness of efficiency related efforts.
> I’d personally prefer to use GitHub for issue management but I can live with JIRA.
No, you wouldn't. I promise. You'd spend months fucking around with GitHub Projects, hoping you could figure out how to unclusterfuck it and you'd miss Jira. It's not good enough. I didn't know how much I actually didn't hate Jira until I worked at a company that tried every other option. They all suck. Jira sucks less.
Management _loves_ to observe and analyze tickets to death. They think that's their entire job.
This is why they buy JIRA. It lets them sit back and look at charts of BS points, BS tags with little to no understanding of what the work actually means. They don't buy JIRA because it helps engineering. They couldn't care less that it takes so much of engineering time.
Which leads to why engineering hates management. Because management doesn't care about engineers, why should engineers care about managers?
And when they don't reveal transparently what they use to measure, engineers feel the gaslight burning and stop complying. Then manager asks, "What's wrong?"
I work at a large company that uses Jira. I had a need to create an issue tracking system for a non-IT org with a large volume of repeatable, largely repeatable tasks with an easily defined workflow and the need to track various approvals and decision points.
“Perfect! I’ll reuse a tool we already have! Save everyone money, document and standardize our processes! It’ll be great!”
Nope. Our instance of Jira was set up for IT projects only and could not be set up for any other workflow. I tried to work around the administrative limits only to find a mess of tags and types and requirements that demonstrated that absolutely nobody had made any effort to adopt standard taxonomies even in the IT space.
It’s not a perfect tool, and there’s enough wrong with it that both the “dysfunction taints Jira” and “jira is inefficient” crowds can be right. But it really is a good enough tool that does not do nearly enough to encourage its good enough use.
I liken Jira to a fire hydrant and each and every PM and every level of (mostly completely useless) management to a small dog that is congenitally compelled to "lift its leg on [Jira]" by "customizing" it in some way, sometimes on a nearly continuous basis. What results is a nasty smelly mess that only gets worse over time.
I encouraged our IT team to try Trello (now owned by the same company, Atlassian) which sports a JIRA integration[0]. Either due to the fundamental limitations of the integration or a botched setup, it's useless. There seems to be two copies of each ticket (one JIRA, one Trello) that can be in different states. It was not just another UI for the same underlying data.
I do hate JIRA. JIRA adds all the beauty of a government bureaucracy to what should be post-it note management. It's hard to overstate how demotivating JIRA is to my work and especially to my planning. Worse, everyone in the organization has to use it.
I miss Trello sometimes. The Atlassian merger killed most of its old spark, and on top of that the micro-managers of Jira at my company wound up eating my old Trello account (because Atlassian decided to merge accounts on email address, which was dumb) destroying a lot of data in the process, and then decided to turn off Trello entirely (and block it).
I'm much more of a Kanban sort. Jira is awful at Kanban. Trello was great.
We migrated some of our Trello boards to Microsoft Planner (inside Teams), which is a laughable joke. Then eventually to Jira because Jira is an inescapable black hole and "oversight" from the micro-managers matters more than getting projects done on time.
My company moved to Jira 2w ago and I feel the burden, it's a horrible tool. I don't care if my manager set it correctly or not.
1) What correctly means in Jira?
2) Honestly it's not a good use of all our time to learn how to use it correctly.
Right now, I can't move a task to another column which gives me a non helpful generic error. Should I spend time investigating this?
And yeah it's not only slow but sometimes it crashes your browser, sometimes it doesn't even load what you click on.
I can't seriously understand the appeal. I would prefer anything else, including post its.
IMO it's not Jira's fault (although I hate Jira with a burning passion). It's the problem of management trying to force their opinionated certainty on a very uncertain process of software development.
One of my past team used another lightweight Jira alternative, and even though the software does it best to keep things light, agile, PMs read the burn up chart as religiously as the Bible, then make their strategic decision based on the most optimistic estimation of the chart.
Agile is great at its core, but business people ruined it. And we have craps like Agile Expert.
I don't hate jira or my manager. I do dislike the misapplication of jira as a tool to problems by rote, and I dislike some of the consequences my manager accepts to achieve his KPIs.
Managers and Jira have their place. It depends on context and scale of problem amongst other things.
I can imagine a tool like jira helping prevent a space shuttle disaster, and I can imagine a tool like jira not preventing it. I can imagine a manager preventing, and not preventing a doomed launch.
I can imagine a 2D grid of jria and no jira, manager and no manager and every single square can have "maybe, maybe not" inside it.
I agree. I’ve said Jira is a code smell. It doesn’t automatically mean an engineering department is broken, but I’ve personally never seen a counterexample.
My problem is that the wrong kind of manager takes to Jira like a lab monkey to meth. You don’t have to use it to build a development process that makes reporting happy but devs sad, and yet that’s what always seems to happen.
And if you’re willing to use Jira with its defaults and not as an inner platform, why not pick something that devs actually like to use? For instance, my coworkers think Linear is great.
Anyone who says "I spend more time (documenting, entering bugs, reporting progress, etc) than doing work" is missing a key point: those things ARE the work. Writing the code is only a tiny part of being a developer.
Writing a giant blob of undocumented code and jamming it into the tree is bad, m'kay.
Write succinct, well documented features that are unit tested and can be traced back to a test using a bug tracker and merge easily into a code base is what we should all strive for.
In the majority of my consulting engagements, the client is using Jira. I don't think the permissions for my account have ever been right on the first day.
The article seems confused. It acknowledged that the problem is annoying customization of workflows by managers, but then bemoans the fact that no one has created a replacement that supports customizations. But that's the point! We don't want fucking customized workflows. Because we know that any product that offers them will end up being used by managers to create an annoying mess.
I disagree with the equivalence between "you don't want any manager" and "you want to hide your work".
I don't want to hide my work, I just think the reason most of our managers are non-managers is because the team can manage itself. We can produce the same reports the manager can, after all we tell him what to put in them. The manager is often an unnecessary layer.
No, I love my current manager, and really despise Jira. It’s slow, bloated, and tries to solve every project management problem and ends up solving almost none of them well.
It takes an impressive amount of experience, self control, and perspective for the management and product types to not take full advantage of the kind of absurd abuse Jira enables.
Jira gives people bad ideas and makes them think they’re supposed to do things that way.
Jira encourages bad behavior.
I don’t hate addicts for being addicts.
People with not enough to do find things to do and with jira around those things are “bothering developers with ever increasing process”, it is indeed the tool’s fault.
No, I hate Jira. I tried using it at home, too, back when they offered licenses for mere mortals. It's slow, the UI is weird and full of old and new stuff that totally mismatches, I hate the API, etc. Maybe some of it has improved, but when it got its reputation, it sucked.
I absolutely prefer Linear no matter the manager, and it's not even perfect.
If you are a jira admin, you CAN stop people from using it incorrectly.
Be an asshole with permissions. People need to EARN the right to do more than just comment and move through the workflow. That doesn't mean they have a fancy title. That means they have earned your trust through consistent good behavior.
Yeah I hate my manager for complicated UIs, slow load times, complicated queries, lots of ways the setup can fail, and generally making everything into a complex platform rather than just putting tickets in a column. Totally not a product design problem.
No, we actually do hate jira. Having to open a browser load a heavyweight page and then fill out various fields on multiple forms on just to enter some text is stupid.
It would actually make it less annoying to use if it was some kind of CLI/TUI. Like in the old days of mainframes when you’d talk to a receptionist to schedule an appointment or register for classes and they’d be typing away on a colorful/neon terminals.
It doesn’t need to be vim like. But it definitely shouldn’t be what it is today —which is a tool for geriatrics and designed by literal clowns.
The Jira API is pretty good, probably the only thing I can positively say about Jira. In a previous life I pretty much only interacted with it from the API.
My workflow was: run script to automatically grab the issue I should be working on from a predefined JQL thing, create a new branch locally and spit the contents of the issue to stdout. I'd just use my email client to reply to comments.
Also had a script that would parse my own format to create bugs/features with all the random extra metadata and I'd only have to write a title/description.
Jira is like the `extends` keyword in Java... It makes it way too easy to create huge hierarchies of classes that then take tons of additional tooling to refactor. Sure you can have a simple process in Jira... but it will be constantly whispering into the ears of you and your coworkers, "wouldn't you like to have an approval step for that? I can easily add one here... How about we add another state that this issue can be in? Then we can hide those issues from this alternate view over here..."
Jira ossifies your company process in concrete which feels great when you first build it but then agility becomes a struggle. You don't even notice it at first but slowly over time your company will fight to get things done outside of the process. You'll then spend so much of your time adapting Jira to reality, you'll wonder what the point of it is.
So yeah, you hate your manager who is mostly just trying to use the best tool for the job, and bought the most commonly used and well regarded tool for it... but that tool is encouraging them to build a giant mess.
Software estimation is basically a useless craft. Rather than focusing on when things are being delivered I think it’s much more important to focus on are things being done most efficiently right now and making sure past obstacles don’t come back. Management often requires a date of delivery for broader strategic planning - which is understandable. However they confuse precision for accuracy. The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. The joint probability of a bunch of very positively skewed distributions “and”’ed together yields a random date skewed way too early. To solve this process people were brought in to “fix” agile but creating bullshit like story points and points poker and burn down charts and pigs and chickens. Then they graft all this into Jira to improve automation, structuring, and reporting.
Agile used to not be like this. Not every project of every org was well adapted to agile, and it required management that gets once you embark on a software effort there’s a lot of indeterminacy involved. Pressure to stay lean and agile should be focused on the present, that efficiency is high and decisions are made quickly, regret is addressed to ensure it doesn’t come back, etc. The future takes care of itself if you take care of the present.
I also like to describe the an uncertainty principle of software development. The more you try to measure it and predict delivery the slower it is, with worse outcomes, less reliably forecasting, with more attrition and burnout.