
Is Jira is an “antipattern”? A rebuttal to the recent TechCrunch article - themeta
https://www.adaptavist.com/blog/is-jira-is-an-antipattern-we-bust-the-myths/
======
tboyd47
All three of these "rebuttals" can be countered by one simple fact: Jira does
not allow multiple owners on a story. That misguided restriction creates much
administrative headache, and is not shared by most other agile boards, such as
Trello and Pivotal.

We have this truism/platitude in software that you should never blame your
tools, so if a tool isn't serving you then you just aren't using it in the
proper place, but there are times when a tool really just isn't built on a
solid foundation for the general problem space it's designed for, and Jira is
one of those.

~~~
solatic
But there's a very good reason for that, and it's because single ownership
provides clear accountability for progress. When multiple people "own"
something then everything thinks that someone else is in charge of moving
things forward, and orgs with multiple responsibility are generally
dysfunctional as a result. If responsibility for action has moved to another
stakeholder, then the Assignee should be changed to reflect that.

Of course, Jira allows multiple stakeholders to be kept in the loop by adding
them as watchers. The UX could be better by making it easier to add user
groups to the watch list of a batch of issues, but that's beside the point
that single-responsibility is strictly better.

~~~
tboyd47
Jira is a bit of a kitchen sink, so it's strange for them to be doubling down
like this. Lots of customers have complained about the restriction and the
other trackers don't have it. It would be great to see some research
supporting their opinion or if they could just accept that it is a legitimate
need for some customers.

One negative result I've seen in Jira (that I haven't seen using other
trackers) is that management is very careful to split up stories individually
and assign each person tasks. As a result, team members are only concerned
with their own tasks and don't want to help each other, which is disastrous on
an "agile" team.

~~~
solatic
> team members are only concerned with their own tasks and don't want to help
> each other, which is disastrous on an "agile" team

I think there's a delicate and nuanced balance here. On one side of the
spectrum, there's dysfunctional teams where team members constantly interrupt
each other and make it impossible for other team members to get anything done,
because nobody can reach any level of focus. Team velocity stays a constant
low, and incompetent management accepts low velocity because it's perceived as
the stable and predictable output of the team in question. But on the other
end, you have teams which don't communicate at all, and that's a different
kind of dysfunction.

I guess the question is, how much does any tool shape team culture, and how
does that compare to management's influence and responsibility in shaping
culture. Ultimately it's management's responsibility, but management also
chooses the tools which a given team will use. I think that management has
much more influence over team culture than any tool.

------
fbonawiede
We also wrote a rebuttal. =)

Regarding myth 1: Agree! That is actually one of the reasons we built our
tool, Delibr. And we don't aim to replace Jira. Instead, we will probably
replace Confluence to a large extent.

Please have a read and let me know if you have any questions!

[https://blog.delibr.com/jira-is-in-desperate-need-of-
refinem...](https://blog.delibr.com/jira-is-in-desperate-need-of-refinement/)

