
The use of JIRA is (often) a symptom of a Management problem - bwghughes
https://medium.com/@benhughes/the-use-of-jira-is-often-a-symptom-of-a-management-problem-3d5e0c2d0cdd
======
joshstrange
Very misleading title IMHO... A couple excerpts:

> I have no beef with JIRA per se, but its the one we come across the most. >
> Here’s what a colleague said, just this morning about JIRA: >> We must
> ensure JIRA usage is identical across teams, in order to ensure velocity
> parity

> So, clearly this is no fault of JIRA — I (as I’m sure you) have seen it used
> many a time successfully, but all to often, it is used (and abused) as a top
> down management tool, mandated from the centre.

Uh... then don't work for company with shitty management... This has
absolutely nothing to do with JIRA. You could find and replace 's/JIRA/Rally/'
and while the article would still be wrong it would make as much sense. There
is nothing inherently wrong with JIRA itself. If you have shit management then
you have shit management and no tool is going to help/hurt that really...

~~~
bengillies
Right and as it says in the title, use of JIRA is often a symptom that there
is a problem with management. Nowhere is it stated that JIRA itself is the
problem.

~~~
chii
So the title should've been 'the use of an issue tracker is a symptom of a
management problem'. But that title is absurd, hence the click bait title.

~~~
p4wnc6
I disagree. JIRA goes further out of its way to accomodate Agile/Scrum stuff
than many other issue trackers. I was on a team once where we used FogBugz
(without any of the metric tracking nonsense -- our managers didn't even log
in to it, they just talked to us when they needed to know about progress) for
a long time without any issue, and only after some big middle management
restructuring did we switch to JIRA, specifically because managers wanted a
tool that spit out useless junk about velocity and burndown. We even had to go
and do really dumb training about "story points" and how to enter the progress
data they wanted (which added so much overhead to entering things into the
system that most of us just stopped, or at least cut every possible corner so
as to not waste our time doing manual data entry for the sake of middle
management).

Not every such tool focuses on these kind of pointless metrics so much. Using
the GitHub issue tracker is joyful, especially when you don't have someone
trying to micromanage you with it. Some tools focus instead on what the actual
developers need to get their work done, instead of what managers want in order
to be more micromanagerial.

Another tool that is starting to go down the dark path of JIRA is Asana, which
is a shame because the original design of Asana was great. But now it's all
about Scrum metric bullshit, catered to middle managers who have the power to
choose it over other things, and usually don't make the choice based on
developer preferences or rational arguments.

I'd say the title could be "Agile/Scrum metric trackers are a symptom of a
management problem" and that JIRA is absolutely the poster child for such a
tool, so it's not bad faith to tie it directly to JIRA. Though your point does
bear repeating: JIRA is not the only tool that suffers from this problem.

------
UK-AL
Click Baity title. Has nothing to do with JIRA but trying to compare velocity
between teams.

------
kylecordes
I followed a few links, and didn't see much background information about Ben's
experience with companies using JIRA at scale; from the tone of the posted
sounds like he is seen some bad management and action.

But here's another point of view; at work we (among other things) train and
consult companies on effective use of JIRA. As best we can tell, our students
and clients are well-intentioned, trying to use JIRA for good, not for evil.
They often want something similar to what Ben wrote about, to get numerous
projects and teams across a large organization using the same tracking tool
(JIRA) in approximately the same way, with local variations as needed but
avoiding pointless variations.

I've actually not heard of any of them trying to "ensure velocity parity", but
rather the typical goal is to be able to roll up and understand project status
and progress across a large and sprawling organization working on goals that
far exceed what an individual team could do. This seems like a worthy and
important goal.

~~~
thachmai
> able to roll up and understand project status and progress across a large
> and sprawling organization working on goals

The major problem with that is we are incredibly good at gaming the system.
I've seen mediocre, at best, team became a glowing beacon under the velocity
game; they managed to close 2000+ stories in one year! (a developer closed
well over 1 story per day on average).

Software estimation is a really hard problem. We can attempt to establish
order by pretending that burning down/velocity charts actually say something
useful. How do they work when all the methods we know fail? No idea. But have
faith, because we have plenty of anecdotes of its success!

------
nowprovision
Sounds like a shitty company, you're probably missing much bigger symptoms..
Get a new job

JIRA is [s]fine though[/s] ok, I've used when at a HN hip company, and it
worked really well, granted it could have been a little simpler, but still
much better than any homegrown alternative, and it was on-premise too.

Clojure use it to track issues too, and very few moans (surprising given the
amount of hammock time devoted to simplicity)..

Disclaimer: At one point prior to using JIRA I did retweet '"Im so happy we
use JIRA" \- no programmer ever' or something like that, cargo-culting jira
hate?

------
karlkatzke
The author has an incorrect definition of Taylorist management.

> Now obviously this is a blatant transgression — absolute, unequivocal
> application of Taylorist management in the context of a Product Development
> mindset

From the Wikipedia article that __HE LINKS __, this caveat is given as to why
Taylorist principles still sometimes apply:

> Although scientific management as a distinct theory or school of thought was
> obsolete by the 1930s, most of its themes are still important parts of
> industrial engineering and management today. These include analysis;
> synthesis; logic; rationality; empiricism; work ethic; efficiency and
> elimination of waste; standardization of best practices.

And that's what JIRA is used for in most companies.

~~~
crpatino
> [Taylorism] include analysis; synthesis; logic; rationality; empiricism;
> work ethic; efficiency and elimination of waste; standardization of best
> practices.

To be fair, you have to accept that Taylorist doctrine states very
emphatically that analysis, synthesis, logic and rationality are the exclusive
domain of _management_. Boss's responsibility is to think very thoroughly
about how work is to be done, and worker's responsibility is to do _exactly_
as told. In Taylor's work it goes as far as to dictate how ofter and for how
long workers are to take breaks (so the maximum amount of labor can be
extracted from them without exhausting their muscles _before_ the end of the
shift).

To complete your list, empiricism and work ethic are the tactics that are to
be used to apply all that management's brain power; efficiency and elimination
of waste are the end results; and standardization and best practices are the
institutionalization of those end results so that the manager's enlightened
intelligence can move on to "fine tune" the next process in the assembly line.

I am not saying that there is no use of standards and best practices. If
anything, in the software industry we need to be more strict, not less, about
the best practices we already know and have known for several decades. But
there is a big difference between that and the kind of micromanagement that
this kind of tools elicit in practice.

i.e. Professional athletes do need to drill until individual movements become
second nature, and proper technique matters a lot if you are competing at the
highest levels. But you do not see coaches trying to dictate what each player
will do on every conceivable situation. Even in extremely structured sports,
like football, the coach dictate a general strategy and changes tactics
according to the dynamics of the game, but each individual player needs to
apply a minimum of discretionary judgment to react to situations that arise
mid-play.

A coach that tried to move his players like puppets would be crushed by the
competition. An army with such general and soldiers would be crushed in a more
literal way. Why is it not the case with software companies?

------
code4tee
Crappy teams and bad management creates management problems, not tools.

JIRA is fine. So far as "enterprise" tools go I'd actually say it's quite
decent. Good teams need ways to collaborate and communicate on projects and
JIRA has a lot of good features to do that as do other options out there.
However, at the end of the day good tools don't make up for crappy teams...
and honestly good teams will find their way to work with/around bad tools.
However if you have crapy teams and crapy management then you're basically
just screwed... but you know someone will decide to do another pointless re-
org or something dumb to try and solve the problems.

------
alistairSH
This blog elicited a chuckle. My employer recently mandated JIRA for all
teams, even those teams which have been using other agile tools for years. No
good explanation was given.

~~~
jdcskillet
Ditto... it was a way for them to standardize reports from various teams
veiled as a cost cutting initiative. Since they are unwilling to pay for
anything (read plugins), our JIRA boards are shells of the tools we were using
and paying for team by team.

------
debacle
Centrally mandating the use of a tool is not a management problem.

When you need to try and account for where your time is going, there are two
ways - have everyone use a slightly crappy tool that they loathe (mostly for
its purpose), or have some sort of process in place that is less efficient
with everyone's time.

> We must ensure JIRA usage is identical across teams, in order to ensure
> velocity parity

In real talk:

> We want to standardize our time accounting across teams to ensure everyone
> is moving as fast as possible.

How diabolical.

The bemoaning of having to do basic project communication is a symptom of a
novice professional.

------
mtVessel
cum: [http://grammarist.com/usage/cum/](http://grammarist.com/usage/cum/)

