Atlassian research highlights major disconnect between developers and leaders
atlassian.com
atlassian.com
No one ever got fired for buying Jira but all your engineers hate it.
It’ll be phrased in HBR terms, but that’s the essential core of it. It’s not about how leadership can change their own beliefs and priorities. It’s about how they can modify others so they don’t have to change themselves.
Like most things, I think it’s a people problem. Story points, velocity, burn down, etc are mostly nonsense.
Tracking productivity can be largely subjective and unfair, probably better left to judgement of a decent manager.
At the end of the day I think it’s systemic incompetence and lack of clear communication, from any combo of product engineering and business, that causes frustration more than creating epics, stories, subtasks and bugs.
Most of the major issues I've seen with Jira come down to a disconnect between engineering and product, sales, etc, etc.
Of course, there's a bunch of other stuff they should just fix. For instance, Atlassian should pick one markdown dialect, and then default all their tools to it at setup time. Also, bugs stored in their cloud offering often go unavailable for a few minutes, even with tiny bug databases. (When I say a bug goes unavailable, I mean I can't access issue XX-1234, but other pages load, often including other bugs.)
Anyway, it's the least bad bug tracking tool I've encountered.
That's a large part of the issue though, just like any corporate software that promotes its customisability as a major feature: SAP, Salesforce, ServiceNow, it's all a shitshow of dissonance between the technical and managerial sides. Workflows that are designed by a committee of the people who are not going to do the work but will manage it, implemented by consultants that sell themselves as specialists in "integration", usually because the company is too cheap to have its own internal set of good developers to drive such projects.
Things breakdown, workflows that are more of a hindrance than a leverage, requiring constant finicking and adjustments, also constantly breaking work because somethings has to be done in the system, while the system itself is not working well for its purpose.
It's a mess, and I have no answer to it, there's something more substantial, and generalised going underneath this mechanism of customisable workflow software eating up actual productive work.
Being opinionated as a product actually matters in the end, but there's no incentive to not try to reach every single possible customer in a market.
Preach!!
> Being opinionated as a product actually matters in the end, but there's no incentive to not try to reach every single possible customer in a market.
Yes undoubtedly so. I’ve seen a lot of companies using Monday.com for non-tech projects and the endless flexibility / generality of the tool leads them to just waste a ton of money and time, in the end they are none the wiser that the issue is them all along.
If me, you and an academic/finance guy/content creator/etc wanted to start working on a project tomorrow, would it matter that much to you if we used jira or a google sheet to communicate the scope and current status of the project?
Edit, addendum, I’ve been thinking about the larger picture, the personal and organizational issues in software, for some time now. I’ve come to realize that a serious lack of talent, interest or enthusiasm really gets in the way of enterprise software.
I have started to think the solution is to focus on tradecraft; most organizations lack the ability to create decent software for a reasonable cost much in the same way that every company hires outside developers and tradesmen to build a new factory or building.
Yes, genuinely it would matter to me. I would immediately stop working on said project. I'm not exaggerating when I say I would prefer an excel document named ProjectIdeasAndFinance_final_JohnD_v2_jan23_finalfinal.xls.zip.xls over working in jira
Any misguided over-engineering of attributes, status values, workflows, is made easy and can be project and team-specific.
The default from where I stand, having had to automate around many a weird Jira & Confluence setup, synchronizing, pushing summaries to pages, etc...
...is that figuring out the name of a custom field through the hack of setting it to a comical value on your test Jira issue does get old eventually, and much convoluted Atlassian-based cleverness would be easier to deploy, operate, maintain, and so, so, so much snappier, with a straight custom built Django app.
but doesn't mention your culture still needs to work, their product isn't a drop-in replacement for a passionatrly well-organized and communicative team.
My big complaint is Jira is that it’s too flexible. Way too easy for micromanagement to seep in to solve a problem with “just one more field” or one more ticket state.
If I ever owned a company, I would make sure anyone who authorizes a single Atlassian license purchase would be fired.
What is it about Jira that you think engineers hate?
I personally don't like how a ticket can only be associated with ("assigned to") one person; and how clumsy it is to split a ticket into small pieces within a sprint. I don't like how there isn't a clean separation between the concept of a product backlog item and a sprint backlog item. I heard the "control chart" is massively misleading as well (though I've never used it myself). It's meh, but tolerable for me; not something hateful.
Splitting up in small pieces sound like subtasks?
A good example from the article is AI. Leaders think it is the greatest thing, but two out of three developers don't see the benefit. This needs to be solved bottom up. Devs love new shiny tools that make them more productive or that make work more fun. That's why we invent a new framework or language every three days. If the two out of three developers can't find a way to make AI work for them, then their non-technical leaders surely won't help.
This is phrased as a brag, but it sounds like they belatedly realized they hadn't been investing in something key to their business.
Ah the tech debt argument. Most likely it's true, but what developers really want to do is Rewrite The Whole Thing, often in something new. That's always a fun, career-advancing project. Being in the position of seeing others do this, and being the person who's wanted to do this before and has done this before, I can say it's not often a good outcome. Software development and UX are different skills and it's a rare developer that has both. This is otherwise known as Refucktoring. When the tech debt refactoring project is given to the wrong person, it's a good way to end up with even more tech debt and less willingness of leadership to try again.
The push for complete rewrite from developers is super rare. Usually they want much smaller changes. When people talk about technical debt, it is usually in codebase with massive number of bugs and teams that are constantly under pressure.
OSS alternatives could eat their lunch overnight if it weren't for "corporate hospitality" or however else they conspicuously manage to shove their dogshit down everyone's throats