Jira can’t stop people from using it incorrectly
jarvispowered.com
jarvispowered.com
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.
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 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 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.
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 think we can all agree that the vast majority of software work does not belong to the categories above, and is therefore relatively predictable.
I’m sure we can disagree here, but I would note we don’t all agree.
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.
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.
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.
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.
In my experience, this is the vast majority of cases. Hence:
> spend years ranting online about how terrible agile is
Put another way, poor management is a human layer problem. No technology (whether process or tool) can solve that for you.
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.
And part of who we are is that we blame Jira, because it's so much easier than to fix ourselves.
(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.)
solved this one by enforcing estimates in time duration. you can easily convert to SPs for any SP-specific metric.
Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.
Developers sometimes don't think about the rest of the business.
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.
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.
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.
We are apparently moving to the cloud version soon, and it’s being sold to the users as the saviour for all the performance issues we’re encountering.
As an example, Atlassian themselves still use the on-premise version, and it's really snappy: https://jira.atlassian.com/issues/
On-premise was designed for LANs. It does not traverse the internet well.
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.
Poor Jira.
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.
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.
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.)
It is also painfully slow.
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.
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.
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.
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.
"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?
"Drat"
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.
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 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)
order by lastViewed DESC
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.
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.
And many more things.
Huh? That must be configuration on your project. I haven’t experienced that.
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.
Is this just a restatement of Conway's Law[1]?
It's slow, it's clunky, it's ugly, it's bug ridden, it's unloved, and nobody understands it.
May it die a quick death.
Did I also mention it's slow? I think I wrote this entire comment faster than one Jira page navigation. Maybe two, if I have to be charitable.
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.
I needed a point of reference for the analogy. If I'd mentioned PHP instead, people would have come out of the woodwork and vigorously protested.
I figured there wouldn't be many Perl fans left. (Still tongue in cheek.)
Also, I'd be remiss if I didn't link to https://ifuckinghatejira.com/ (for the lulz)
A mystery meat UI is bad enough but a slow mystery meat UI is just infuriating.
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?).
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.
Atlassian tools are decent enough, and mostly usable is how I'd describe them. I'd take anything else though, even Rally.
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.
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.
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.
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.
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?
Management _loves_ to observe and analyze tickets to death.
They think that's their entire job.
But after layoffs, it was revealed that management literally just counted up Jira tickets to measure developer productivity.
So any time you had spent helping others was essentially just time you spent destroying your own performance ratings. ¯\_(ツ)_/¯
Management is an utter bane of the tech industry.
“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 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'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.
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.
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.
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.
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.
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.
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.
> You don't hate Jira, You hate your micro-Manager
Yeah maybe, but also: Jira is an attractive nuisance for micro-Managers.
High dependence on Jira is therefor a red flag (i.e. an indication that a bad thing _might_ be happening and other indications should be checked).
“because it’s slow as balls” is conspicuously absent as the first reason!
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.
I absolutely prefer Linear no matter the manager, and it's not even perfect.
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.
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.
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 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.