
Ask HN: Should I fight back management enforcing Jira? - princesse
I&#x27;m a tech lead in a small shop (around 5 developers and growing) and our company has recently been acquired by a bigger one at the beginning of the year. We&#x27;ve been lucky so far as we&#x27;ve maintained independence of process and priorities. We&#x27;ve demonstrated times and times again that our development processes and our talent was order of magnitude superior to their existing dev teams.<p>Management from the head company is currently in the process of signing us up in Jira without consulting with us. Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex.<p>I&#x27;m close to the product owner so I can pull some strings there if this is a trap but I need to act fast. We&#x27;ve got nothing similar to Jira in place and are dealing with things without any dedicated tools, which means I&#x27;m open to learning Jira as I know our current methods will not scale. I&#x27;m worried for the following reasons : 
- I haven&#x27;t heard good things about Jira, especially on HN
- I&#x27;m afraid it will only add more paper-filling work to my team (or myself)
- I&#x27;m afraid they will use Jira to enforce a specific process to my team (I do not expect to have admin access to setup workflows properly)<p>Any thoughts on how I should handle this?
======
Carpetsmoker
Management has a concrete problem they want to solve:

"Their motivation is to be able to track what the dev team is doing and keep a
log of the activities, with the end goal being to be able to qualify this work
as Capex."

So if you really don't want JIRA then offer an alternative that will meet
those requirements.

Management may still say "just use JIRA". Before pushing back on this have a
think about the cost/benefit ratio and whether this is really a battle worth
fighting. You may lose credit with management, and more importantly, life is
short. Arguing over issue systems is a stupid thing to spend your life on
unless it's really going to save you a lot of time/frustration down the line.
All in all, I would say it's unlikely that it's worth it.

~~~
wtvanhest
To add to your coment, depending on the company, moving a lot of $$$ to capex
is incredibly important for management.

If anything you should embrace Jira and look for ways to help get things
classified as capex. Ask for a meeting with accounting/finance to fully
understand it.

Just think of it as learning a new skill.

For the people saying to look for another solution, I would first figure out
how much work they put in to selecting Jira. It was probably a big decision
making process and you may be too late to make a change.

~~~
awaywopassd
Unfortunately, this is a reality. I am part of a small team where we moved
pretty fast.

We used to write our own stories in Jira and they were mostly one liners. They
have now implemented so many required fields to fill out. Filing out one story
might take 30 minutes.

And the management has implemented a mix of waterfall and agile methodology.

It is combination of worst of both worlds. We are asked to plan our next 10 or
more sprints. Assign points to each story. And then we are asked to justify
points to management. It is a big mess. In a week, we might spend 20+ hours on
planning and planning to plan bullshit.

I fought this as much as I could. But in the end, I realized that this is
losing battle. All we can do is work with them and help them justify their
jobs and our jobs.

We have stories for planning stories. We have stories for reading
documentation. We have stories for breaks. Oh I want to cry.

But good thing is if you work with system and make your team look super busy,
you will get big bonuses and pay raises. Kind of like in real world, you can
write the cleanest code but if you don't write features that customer want and
brag about your product, you will not get paid for it.

~~~
Carpetsmoker
> I fought this as much as I could.

I think that "fighting" this in the first place is not the correct approach.
It would be better to "work on improve" it.

Perhaps I'm being pedantic, but I think it's an important difference, and
creates a different (more constructive) mindset.

But yeah ... I've been where you are and I feel your pain :-(

------
f055
I think you should grow up. I mean, what’s your end game? Do you want to
manage or own projects for the rest of your carrer, or do you want to move up
and retire early? If the former, propose them a tool that you prefer and meets
their requirements (maybe integrates with Jira?). If the latter, be the
champion of Jira integration, get to know the new upper management who wants
Jira in, explore how you can penetrate the structure of the bigger company,
because right there is your opportunity - as, I assume, in your smaller
company you almost hit the ceiling in terms of position advancement. Move up
the ladder, earn more, retire earlier. What’s the point of doing the same
stuff 20 years down the line for probably just a little more money than
inflation adjustment? Btw I used Jira sparsely for 10 years and it is not that
bad. It’s a matter of getting used to. Other more “cool” tools might look
slicker but are often not that flexible.

~~~
wink
No need to sling terms like "you should grow up". There's both a reason a big
share of developers hate JIRA with a passion and also a reason business people
like it. It's hard to find the fine line of it being useful for both parties
and not just making the developers' lives harder and I've seen people having
to spend an extra 30min per day just fighting the tool. This is not about
whining to keep your independece, this is mostly valid criticism that it
creates work instead of making life easier.

~~~
_rrnv
Indeed I could have spared the terms, but your comment is exactly what I am
talking about: developers often place themselves agains business people,
sometimes feel superiority, and are proud of it. But in fact it's wrong and
immature – working in a company means cooperation, and both departments have
experts in different skills. Another common pattern is to glorify tools and
frameworks and be passionate about them. Again, why? It's not like being a
github issues fanatic and hateful of jira makes any significant difference in
the end. You say devs spend extra 30min per day fighting jira. For one, if
they are as smart as they say they are, maybe the problem is not jira but
between the chair and the keyboard. For two, say devs don't spend that extra
time on jira. Who do you think will have to spend extra time to collect all
the info necessary for the company to know what's going on? Probably the
business owner. But who cares, devs want it easy. I wish luck to those who are
very smart, because they will always find good work. I have hopes for all the
others that they won't end up just typing code, because in some years time
they may be replaced overnight by AI.

~~~
setr
It's a matter of competing interests, and knowing your own domain best.
Finance guys know finance best, devs know development best. Something (that
looks) good financially might hurt development speed, iteration-time, bug-
fixing, etc.

And it's not the CFO's job to know/understand these effects; its the CTO's job
to. And it's the CTO's job to fight back on it if necessary, because its
interfering with his domain. It's also the CTO's job to know whether or not
its _actually_ interfering with his domain, and its his job to argue that
position. And ofc, its the CEO's job to look at both offers, and decide
whether or not the cost of interference to development is worth the benefits
to the financials. With perhaps the CFO/CTO coming to an agreement independent
of the CEO where trivial, as an optimization, but the ultimate responsibility
is on the CEO's hands.

It is absolutely not about simple cooperation: its competitive cooperation.
The goal is shared, but the steps to achieve it are not. And because of
specialization, we cannot cooperate by simply knowing the global state of
things, and determining the best course of action. We can only know the parts
we know (a subset of the global state), and optimize our local interest in
hopes that our local optimizations will take use closer to the global
optimization. And _everyone_ is doing that, with a local view. The only person
who truly intends to chase after the global optimization directly is the CEO.

You should be protecting your domain from competing interests, because
everyone wants to have a say in your domain, whenever they can derive even
minor benefits. They don't know the cost to your domain, or the benefits to
it: they know the cost to _their_ domain, and the benefits to _their_ domain.
They may have some _idea_ of it, but ultimately its your own job to know your
own domain, and defend it as necessary.

Development does not, and should not, know whats best for finance, and the
same is true vice-versa. It's not their position to. They specialize in their
own domains, _and thats fine_. Obviously an overly-aggressive defense, or
interference, can be harmful, but it'd be ultimately stupid, and likely
harmful, to blindly follow the orders of people _who do not know your domain_
, in the spirit of cooperation.

------
smackay
The problem here is not the tool but the process that comes with it. From the
managers in the bigger company's perspective integrating your team into the
larger structure makes a lot of sense. What they are probably missing though
is the impact that doing things their way is probably going to negatively
impact your team.

Opposing the tool is not really going to get you anywhere. From the outside it
will just look like you are resisting the integration with the bigger company
and all the baggage that is going to come with not being "a team player".

For entertainment purposes only: fight fire with fire. Make a case for
improving developer productivity by implementing a ticket quality score and
use it as a metric. After all, the better the ticket the faster you can start
work on the problem, rather than having to go chase down all the issues and
requirements. Management will be rather annoyed at you flagging all their one
sentence tickets as inadequate. As I said this is for entertainment purposes
only. It's fun to make a point, but push quickly becomes shove.

~~~
artwr
I am always reminded of this story around throughput metrics for Software
Engineering:
[https://www.folklore.org/StoryView.py?story=Negative_2000_Li...](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

Your suggestion is delightful, and in a former company, one of our PMs, at a
time when we were overwhelmed with requests, tried to tame the tied by
requiring requesters fill out this simple template along the folloing lines
(but I am paraphrasing): \- What is the impact on you/your team from this
feature/bug not being addressed? \- What is the priority of this in comparison
to other asks you have from the team? \- What is the impact to the business?

Even though the team did not like the bureaucratic approach, the number of
requests went down dramatically.

------
mongol
I think you should embrace Jira but require that you get the access and
permissions you think you need. Jira is not bad, but can be used in many ways,
and when you figure out a way that works for you, it will not be a big deal.

~~~
seanjregan
Word. Solid advice. When you delegate all the decisions to a person looking at
the global maxima at the expense of the local needs of your team you will not
be happy with the results. For as long as you delegate this task, you will be
unhappy with Jira. As soon as you take an active role, the perspective on Jira
tends to change.

It's a good example of how being the change you seek changes your POV on
something.

------
eksemplar
I think jira is terrible because it’s complexity does the opposite of what you
want management tools to do. It slows production to a crawl unless you invest
heavily into change management and into building processes and training.

That being said, I think you’d be facing an impossible fight.

No developer loves these tools, and as a manager you hear complaints about
almost everything imaginable, and if you have jira, and you think it’s working
for you, then it’ll be hard to change your mind.

Leading upwards is really challenging, because you’ll need to show the
financial cost of using jira and present an alternative as well as a plan and
a budget for how to get there if you want to convince your manager, and you’re
probably not paid to do that.

~~~
dahdum
I know some orgs end up with crazy Jira processes, but after using it for 7
years in my last company it would be (or similar) the first thing I set up for
company larger than 5 people.

We never used the workflows much, didn’t go crazy with required fields, and
didn’t over analyze reports. It quickly expanded beyond the tech team. Each
department created their own projects of their own accord and used them
heavily. It saved a ton of emailing and left a record we could refer back to.

OP shouldn’t have too much trouble mapping their current process to Jira
unless they aren’t organizing their work at all.

~~~
eksemplar
We use jira with around 10 different partners of ours. Where we buy software
development on open source projects, but take code-base ownership and handle
project management.

We use jira because it’s what the companies use internally, and being in
project management in the public sector with more than 500 it systems, well,
we’ve been around a lot of tools and know how to adapt to them.

I’ve only seen jira utilised in a way that wasn’t wasteful at one company
though, and they’d spent a lot of time streamlining the way they used jira as
well as how they wanted us to interact with them.

Every where else they would have done better with a white board and sticky
notes, even though that’s not something I’d really recommend either. The worst
example was a company that had to assign their own project manager to
everything because their developers didn’t know how to label, move or even
register things “correctly” in their own jira.

That’s why I think jira is terrible, because it’s designed to fail you
miserably unless you spent resources beating it into submission.

Once you’ve beaten it into submission, however, it’s a marvellous tool. I’m
just not into that process, I want my technology to work out the box without
customisation. That gives me less freedom, but I don’t really care about
freedom in “hour registration/planning” software, I simply want it to be as
anonymous and easy going as possible with minimal effort.

------
Waterluvian
I've been at a company that used jira 5 different bad ways as they constantly
churned through different ways of doing agile. I've also been at a company
that used jira as a simple issue organizer with a handful of labels and
literally nothing else.

It's just a tool that can be badly misused to make a bureaucratic mess, or can
be barely used to write things down as we collectively think of them.

------
gorbachev
We use Jira at work. We don't use it for everything.

This is how introducing Jira goes in a typical enterprise:

There's process, lots of it. There's training, scrum masters and Agile
trainers flood the office floors. You can't move a task from in progress to
done, because you didn't push the ticket through QA, QA Accepted, In Review,
UAT and Waiting to be Deployed phases.

6 months later the Agile trainers are gone and sanity prevails and all the
processes that don't make sense are quietly rolled back.

Thankfully you can configure Jira to do pretty much whatever you want, even
the absolute minimum required to keep the dashboards management sees pretty.

------
jamestimmins
I'd encourage you to consider what they're truly trying to accomplish by using
Jira. Are they simply trying to take existing agile processes and add new
tooling? If so, that doesn't sound too bad. Perhaps cumbersome, but if new
tooling allows you to keep existing processes then it's a win. But if using
Jira is shorthand for changing processes, then those are what you want to
focus on.

It sounds like you may want to talk with the product owner to really
understand what the long-term goal of this change is. Then, if you don't like
that, you'll be in a better position to argue why your current/alternative
process allows you to provide more value to the company.

------
peterwwillis
To answer your concerns: 1) What you've heard is probably accurate. 2) It
probably will add paper-filling work. 3) They will definitely enforce using
Jira in _some_ kind of way, but not necessarily a strict way.

How you should handle this: acknowledge that it's just a complex tool, and
like any complex tool, how you (and others) use it determines the experience.
Yes, there will be an up-front cost to onboarding. But it doesn't have to go
horribly.

As your team gets trained on it, you will probably quickly experience pain
points. Document them and constantly measure the effect of them on your team's
output. Implement workarounds as necessary and measure the effects. Provide
the results to management along with your recommended fixes. In theory you
should end up with 1) "We tried it your way, and this is how it went", 2)
"Then we tried it our way, and this is how we improved it."

This provides a method to work around problems, and a solid argument to upper
management to modify their use of the tool. Make sure the argument makes it
clear that your changes are in line with the business's objectives, or
probably nobody will care if it's painful for your team.

------
znpy
Not a developer here, but a Jira user anyway.

I don't have dislike Jira that much, and quite frankly I think it does it job
and doesn't get in the way that much.

I have to say that my team is larger than your, so maybe (maybe?) if you're
only five developers then Jira might introduce a bit of process overhead? Or
maybe once you have some process in place scaling to more developers will get
easier?

It seems to me that the problem here is how you look at things: who brought
your company clearly wants to scale you up. Imho you should see this Jira
introduction as an opportunity for better scaling rather than a threat.

One little side note: if your company has been acquired then all the games are
over (and I hope you made a shitload o money in the acquisition). Don't get
too much in the way o management, otherwise it'll be just easier to get rid of
you than to deal with you.

My two cents, I hope my options help.

------
bumelant
If the requirement is coming from accounting (qualification of spend as capex)
there’s no way to push back, but it also doesn’t mean you need to follow the
exact process of bigger company. You can negotiate minimum amount of
documentation that for legal reasons your team needs to track in JIRA and do
just that. Good luck!

~~~
burfog
Wouldn't that goal (qualification of spend as capex) be solved better by
timecards? I don't see how a bug tracker helps unless you abuse it to be a
timecard system.

Of course, timecard software can be awful too.

~~~
cimmanom
Jira has a field for time spent on a ticket, and can produce reports about it
pretty quickly. There are also plugins available to let developers use various
timers with it, or even integrate with timesheet tools like Harvest.

I’ve worked in a company that qualifies development time as capex. They can’t
just treat all developer butt-in-seat hours as capex. They have to allocate it
to specific projects.

Using the issue tracker for that can streamline the process and saves the
developer having to know which bucket to bill time against for each ticket,
because the project manager or whoever can take responsibility for tagging
each ticket with the appropriate accounting bucket.

And time spent on maintenance or meetings or peripheral tasks like
interviewing candidates or configuring Jira goes into its own buckets that
can’t be capitalized. Using the issue tracker to track capitalizable time
makes that delineation easy to enforce. If it’s not in the issue tracker, it’s
not capitalizable.

------
meowface
Jira can be pretty clunky and not great to use, but it gets the job done and
really isn't that bad. I think it gets too much flak. A future product from a
competitor will probably eat its lunch and eventually replace it someday, but
if you just want to track different kinds of work, it works fine.

------
jb0x168
My advice after working with Jira for the last several years: keep it light.
Process heavy Jira is/can be a nightmare. Jira as "digital stickies" works
well, and still provides plenty of metrics for outside stakeholders.

Based on my experience:

\- Use the "Jira Agile" (formerly greenhopper) add-on so that you have
sprint/kanban boards and reports to visualize planned and in-flight work.
Enable the "Backlog View" for your boards to separate planned from in-progress
work.

\- Keep required fields to an _absolute minimum_ (we only require Summary) so
that you can quickly capture cards and flesh them out later.

\- Avoid complex workflows - use the Software Simplified workflow if possible.
Don't complicate it further without a really strong business case.

\- Learn the keyboard shortcuts. C (create), E (edit), I (assign to self) "["
(hide sidebar) and "." (command palette) are your friends

\- Confluence and Slack both have great integrations to let you publish and
interact with your Jira issues

Those are just a few random thoughts on how we've kept Jira working for us and
not against us.

------
trelliscoded
I wouldn't be worried about Jira so much, I'd be worried that management is
going to implement New Processes to Keep an Eye on the developers.

Above a certain scale you kind of need an issue tracker, but when you're
serving it instead of it serving you, it's the implementor's fault, not yours.

One of the reasons Jira comes up so much is that it's so customizable that it
will merrily allow you to construct the most Byzantine nonsensical workflow
you can think of, and fairly quickly too. It's not Jira's fault that someone
told it to do so.

It really sounds like they couldn't find a manager capable of handling both
teams, so they're going to throw technology at the problem instead of
investing in their people to grow them into the position. It might work if
they are willing to pivot quickly based on user feedback instead of just
dropping New Process on you, but it's always slower to manage that way instead
of just hiring a competent manager.

------
twblalock
My advice is to view this as an opportunity to improve the company's Jira
workflow.

The status quo of issue tracking on your team is not scalable. And it's
entirely reasonable that management should have a way to track your work. You
are a small team in a big company and you're going to end up using whatever
issue tracker everyone else uses.

You say that your team works better than others in the company. Tell
management how your team's processes have resulted in high productivity and
suggest improvements that other teams can benefit from. If using Jira hurts
your team's productivity, find a way to quantify that -- ideally in terms of
how the capex is higher than it needs to be because developers are wasting
their time.

Recommend small, incremental changes rather than remodeling the entire system,
and get other engineering teams on board with your proposals -- if the
processes are bad, other teams are likely to want change too.

------
ilaksh
The one place that I had to use Jira, it was poorly managed. The manager
basically used it to create a list of every project and idea he could think of
and then assigned quite a lot of them to me simultaneously.

The result for me was that I was overloaded with work. And then the manager
became unavailable to discuss some important blocking items for about a week.

I am not saying that Jira or project management tools can't be helpful, but it
does seem to have a tendency to encourage micromanagement as well as
distracting from priority items with less important tasks and deemphasizing
direct communication channels.

But of course management needs some way to know what is happening or that
actual work is being done even, and a way to give direction about business
goals.

I believe though that if not handled correctly this change could very well
interfere with development. So you are right to be worried.

Personally I would do something like this:

1\. Very quitely make a backup plan for alternative employment. Just in case.

2\. Come up with an alternative to Jira that A) allows managers to to see that
some development is even being done and they aren't just paying people to hang
out and B) gives some details about what is being worked on. This could be
just email notifications when people push to GitHub.

2b. I would also set up a weekly meeting with management to discuss dev
progress and business priorities face to face. And as far as capex reporting
maybe you can use a Google Docs with employee hours together with a dump of
github commits, perhaps grouped by user.

3\. Explain that you want the dev team to focus on their work rather than
checking off boxes for a process, and they want to stay focused on core tasks
rather than a lot of small unimportant ones. And therefore since the current
process is working you believe adding Jira will only take away time from core
activities and make the team less productive in terms of actually meeting
business goals.

~~~
seanjregan
Spin up a simple one board kanban project, use the new roadmaps in Jira cloud
to show the epics to management and move things from backlog to in prog to
done. Add tempo for time tracking if you need to show the accountants how much
work has been done.

------
Stratoscope
> _We 've demonstrated times and times again that our development processes
> and our talent was order of magnitude superior to their existing dev teams._

That may be part of your problem right there. I'm sure your team is very good,
but do you really think you are _10X_ better? It seems unlikely.

~~~
topkai22
Order of magnitude (base 2)?

~~~
Stratoscope
Now that is funny, thank you! :-)

But seriously, even when I've only thought I was _twice_ as good as someone
else (and I'm afraid I have thought that too many times), it usually hasn't
ended well.

~~~
jaggederest
I've worked for few different companies where some development groups were
producing negative productivity, and others were producing positive
productivity. Consider that one "profitable product ruined", and one
"unprofitable product made profitable", or equivalent metrics.

What's the productivity ratio between -1 and +1? Is the first team "less
productive" than the second team? Certainly. Is the second team "twice as
productive" as the first team? I think the answer is "infinity", so "over
twice" is a good summary for people who intuitively distrust "10x" as a
number.

------
calyth2018
The majority of what I've heard at different workplaces about Jira has more to
do with a) people not knowing how to use it and b) people not knowing and
agreeing on how it was customized.

If the motivation is to track what the teams are doing, even if you win the
fight on not using Jira, something will be proposed. Maybe it's Rally, maybe
it's some POS that was sold because their sales guys and your CxO had a golf
game.

You're better off ensuring that you could do what you need to do with Jira
than anything else.

As an aside, I take issue with the term dev team - many people use Jira as
part of an "agile" process, but they only plan things around development, but
not test, only to find out later that their one liner change from dev could
cause the tester a week to setup the environment for an automated test....

------
blaisio
Objectively, JIRA is buggy, slow, complicated, and hard to use. Unfortunately,
it is also useful. Is it a good tool? No. Does it sometimes let you do things
that you couldn't do before? Yes.

I would not choose to use it under basically any circumstances, but I also
wouldn't be upset about being forced to use it - assuming I'm being paid well.

You should probably find out why they want to make the change. Is it just
because your team is sticking out as being different? Is it because they want
to try and do task efficiency calculations? Do they feel they don't have
enough visibility into what you're working on? There might be a communication
issue you need to fix (which JIRA probably will not address, even though they
might expect so).

------
riser9
It sounds like you haven't even looked at Jira, you are basing your view on HN
comments. We use Jira productively, and progress is made visible across the
entire broader team with it.

Of course, it can be used to implement inconvenient, useless processes as
well.

------
detro
Don't base your judgement on software on HN. Jira is old and not the latest
fancy tool: it's a battle hardened instrument that can be invaluable in the
long run. But it needs to be used properly to bring out all its value.

Given you are a tech lead, this is the time to take ownership, create a Jira
project and tailor its setup to your team needs.

Also, and this goes unsaid because Jira isn't new, the product has gone
through many iterations of evolution and it's now a very nice UX. We use it
for Kanban, Epics, Releases and the metrics help us visualize in an instant
how efficient our team is.

If you give Jira a fair chance, you won't be disappointed.

------
a-saleh
Disclaimer: I actually like jira.

If I were you, I would primarily fight to have enough privileges to be able to
have your own workflow. In that case, Jira can be maleable enough to make it
fit your current process, and if you can negotiate to be the one that
decides/implements the workflow, you should be able to shield your team from
any rashly imposed process from above.

------
TheGrumpyBrit
I use Jira at work, and also at home for my side projects. At home it's little
more than a self-hosted Trello instance. At work, it's more complex. Both do
their jobs well enough.

Your problem is that you don't currently have any tools to track what your
devs are doing. Your proof that you are "orders of magnitude superior" is
nothing if you don't have the metrics to back it up.

If you accept that the larger company is going to want metrics on what your
devs are doing (and that's an inevitability) then unless you have an
alternative in mind and a compelling reason to use it instead of Jira, your
best bet is to get on board, and do so with enthusiasm. If you're earnestly
trying to use it, people will listen to the problems you run into and workflow
changes you ask for. If you're complaining because you just don't want big
brother watching you, you'll be ignored.

------
jamescodesthing
What’s your alternative tracking mechanism? And what does it report?

Truth is you might be so good because you’re not at scale, they may be looking
to scale you up which is great... you just have to get them the numbers.

Jira as a tool sucks dicks for pennies (trust me i’ve seen it)

Jira is however customisable as fuck, so if you’re being forced into it then
get admin! Stick to a simple workflow, basic practices. Jira falls short with
the amount of munging people do to it, at the minute my team has a 9 column
board with 5+ projects on it... that’s not how it’s meant to be done and it
drags time out of my day.

So by all means if you’re tracking already, demonstrate that (as long as it’s
not a damn spreadsheet). If you can’t get them what they need then question
why Jira. If you have to use it then get admin and make the tool work for your
current process.

------
tokyodude
probably the wrong thread to ask but what should a 5-10 person company with
20-25 outside contractors and lots of costumers that may need to access the
issue use?

I'm currently consulting for a company who has no issue tracking system. they
use an excel sheet which makes it impossible to have conversation about
individual issue and nearly impossible to track updates.

I can't imagine getting them to spend $300+ a month for a managed system.
bugzilla or Trac seem progammer oriented whereas this is a game dev company
meaning copy/paste drag/drop image support is important (having to first
create a local image file and then navigate to it is right out)

any solutions out there they could install on an unused computer or remote
computer that might meet their needs or do they just have to be convinced to
pay $4k+ a year?

~~~
peterwwillis
The dumbest, cheapest, simplest option is e-mail. No matter who they are, if
they're an actual company, they have to have an e-mail provider for their
domain. This means (at the very least) they can create a single account that
will accept e-mailed issues, and forward to all relevant users. Track the
issue in e-mail thread replies, which always has the latest updates.

There may be provider-specific productivity features, such as G Suite's
Collaborative Inbox, or Exchange's Public Folders. The IMAP Protocol also
supports shared mailboxes, so any IMAP server that supports this will allow
you to collaborate on issues sorted into folders that multiple users can
access. Some open source mail servers definitely support it. Once they pick up
a real issue tracking system it will probably support issues created via
e-mail, so it can be seamlessly integrated later.

------
JackPoach
Bitrix24 is pretty good and free. They have a bunch of local domains,
depending on where you want to have your data hosted. Ex:

[https://bitrix24.com](https://bitrix24.com)
[https://bitrix24.eu](https://bitrix24.eu)
[https://bitrix24.com.br](https://bitrix24.com.br)
[https://bitrix24.in](https://bitrix24.in)
[https://bitrix24.de](https://bitrix24.de) etc.

There are a couple things that are really good about Bitrix24. It's kind of
like Jira+Confluence+Hipchat+Trello in one, but much easier use. Second, you
have an option to choose between cloud and on-premise, just like with Jira.

------
tmaly
I have converted my team to Jira and Confluence. There is some initial
learning curve, but if you select a subset of the features, and train /
document how you expect each tool to be used, they will provide a net benefit
to your team.

A friend of mine was at a company that was using JIRA, but they had no
processes in place and ended up going back to using paper.

I think you really have to establish some simple processes to really get the
benefit from these tools.

You can go overboard and try to require people to document every single detail
every single day, but I think this is counterproductive. You have to find a
balance.

------
indigochill
My team is in a somewhat similar position relative to our company. I like to
think of Jira as an interface for management (and in our case, internal
customers) to create and manage high-level requests and priorities. Then our
team internally creates Trello cards for the actual tasks that need to be done
because we find it significantly more efficient than Jira. On our current
project, the ratio of Trello cards to Jira tickets is ~15.

As long as we also keep Jira reasonably current with the status of the
project, Management's fine with however we want to track our work internally.
YMMV.

------
gargarplex
You can customize JIRA to fit your existing processes. Make sure you get the
company to pay for that.

Embrace JIRA, it's like giving management an API into your team's performance.

------
moondev
How do you manage projects now? Jira is fairly ubiquitous in agile development
and has been used everywhere I have been in the last 5 years or so.

------
actionowl
If it makes you feel any better JIRA is probably the least shitty of the
Atlassian suite products (not by a large factor). You might want to be more
concerned about Confluence, BitBucket, and Bamboo creeping into your workflow.
I'd suggest seeing if you can get away with using a more lightweight tool such
as Github issues, Redmine, or Gitlab.

------
nl
Jira is fine - it's a complex tool and maybe slower than would be ideal, but
they are really the only significant issues.

There are lots of positives, too - it is very flexible, and integrates with
anything you want.

To be honest, I don't think there is anything nearly as good if you want
beyond what Trello can do.

------
nwrk
Slightly offtopic: [https://www.neat.io/bee/](https://www.neat.io/bee/) Native
FAST client for Jira.

The point is - once you make it works for you, life is great again. As others
here said, be Jira master and climb the corporate ladder.

------
wingerlang

        We've got nothing similar to Jira in place and are dealing with things without any dedicated tools
    

Are you not tracking issues at all? I very frequently look up years old
tickets to know why something is the way it is, and I could not imagine
working without it.

~~~
sidlls
That's what comments in code and project/product and technical documentation
are for. Work tracking tickets should contain as little text as possible.
Ideally the contents would be a brief 1-3 sentence description of the work,
links to the relevant parts of the product/project and technical
documentation, and whatever the definition of done is (e.g. "success
measures", "acceptance criteria", and so on).

For normal work I simply don't allow my team to create tickets in JIRA unless
there is at least a technical design document which contains at minimum a
bullet-list describing the complete scope of work and some documentation or
links to documentation regarding the specific requirements. For bugs I require
the ticket created and put in our queue to be updated with the same material
once the cause of error and the fix are identified.

------
seanjregan
Some companies treat their software teams like factory labor focusing on
process and efficiency above all else.

I and most of us at Atlassian believe that epowering developers with more
autonomy will drive better outcomes, better products, and better teams.

To help resolve these conflict, aspects of Jira needed to change and team
culture needs to change.

To fix this we've been investing to democratize Jira's permissions model. We
have been focusing on autonomy and flexibility to let any team design the way
they want to work while giving administrators the power they need.

The SW biz is a very fast-growing space. When you combine massive growth,
speed, and impact it is easy to lose control.

Feeling like you need tighter control means people often try to grip tighter.
Sometimes that shows up in insanely complex and structured Jira instances.
Sometimes Agile has become more important than agility. Sometimes using Jira
has become more important to leaders than the outcomes the actual customer
wants. This shouldn't be the case.

It can become easy to over-index on process and control at the expense of
agility and software team autonomy. Don't do it!

This results in some over-designed Jira boards and workflows.

Leaders and managers in business and software development need to balance the
desire for control with the need for S/W team autonomy. This endless dance
between autonomy and control always shows up in every HN thread with
detractors saying Jira sucks and fans saying Jira is great but the people
setting it up must suck.

There is responsibility all around. Jira, for example, needed to improve the
permission model to better empower teams with project level controls. We've
needed to simplify the setup and clean up the issue views. These changes in
Jira Cloud help admins feel more comfortable delegating more control to teams
to design their own way of working.

We can't police how people use Jira in the wild but we can share our POV, our
playbooks and we can make changes to the product to make it less likely that
managers treat dev teams like factory labor focused on process and efficiency
above all else.

A well-running team in a well designed Jira instance should work more like a
lab than a factory.

Triads or squads should be able to chase a hypothesis, they should be better
able to adapt to new information and respond to change than a factory assembly
line. Leaders should be looking for more than process and efficiency out of
the team and out of Jira.

How should you handle this?

Make Jira work for you.

Play a role in designing the way you want your team to work. Take the lead in
changing the board design or the workflows when your work requires it.

The teams that make adapting to change their competitive advantage make the
biggest impact on their company, their customers and the world. But, it takes
trust and courage for leaders to create the conditions necessary for this. It
means giving software teams a degree of autonomy and flexibility. Mastering
this is the core competitive advantage for innovative companies today. These
companies retain great talent, they hire great talent, they get great results.

Over the years we've heard the wishlist from Jira users and administrators in
large companies and startups.

Make it easier to use and get started!

Give me flexibility and control when I need it!

Let my team design their own way of working!

To bring a new level of simplicity and power to Jira we needed to re-think the
basics of the product. We also decided to open up and share our practices to
go along with our tools (Team Playbooks [https://www.atlassian.com/team-
playbook](https://www.atlassian.com/team-playbook)). We needed to learn a few
things from the Trello team. We needed to think deeper than new features. The
good news is that we've been doing that in a big way and you should be seeing
that in the Jira Cloud product you can try today.

A couple examples

Project Level Permissions- Have you ever felt like the Jira you are using was
designed for some other team or project? Alert! It might have been. Jira SW
Cloud now makes it easy for next-gen project owners and team leads to design
their own Jira projects, boards, and custom issue types without creating
concerns that it will impact other projects.

Agile features can be turned on and off with the click of a button, so your
team can customize to best suit its own unique workflow depending on its
maturity level and the project at hand. For example, you can now flip between
scrum and kanban methodologies in seconds

You can create issues and columns in-line, without ever leaving the board

Out-of-the-box team filters on every board, such as epic, issue owner, or
labels make it easy for anyone to sort and filter in a click, no JQL needed.

You can define a rule to automatically update an issue's field or assignee
based on the column it is moved into

You can display issue attachments as card cover images on the board

You can create, edit and delete issue types in independent projects

You can create issue types and customize the fields to suit your team's needs

We've got a lot more coming. The good news is that you can customize, modify,
adapt and design Jira Cloud to do pretty much anything you want. The bad news
is that means someone who doesn't know what you mean might do it for you if
you don't participate.

Building software is complicated work. Jira's secret sauce is the way it
simplifies the complexities of software development into manageable units of
work that can be predictably shared and worked on by many different teams at
the same time. Well designed Jira boards and Jira issues enable collaboration
across increasingly diverse software teams that include design, marketing,
analytics etc.(via integrations to the Jira issue)

That's a lot of text for a really small text box in HN. I'm trying to stay
awake long enough to see the end of the Red Sox game. It's longer than that
the typical bit of snark about Jira sucking or your admin sucking or doing
work at work....sucking.

My advice:

You can have admin or project admin permissions, you can design the way your
teams wants to work, you can integrate the tools like GH, BB, INvision, New
Relic, Launch Darkly, etc that your team uses already. You can give the
managers the vis they want and need and you can do it without sacrificing the
sanity of your team day to day. And, you can use Jira to show whoever needs to
know what you've been doing and how it impacts the business.

Jira should feel like the center of gravity that helps all the work your teams
are doing hang together across different teams and tools.

------
slipwalker
> We've demonstrated times and times again that our development processes and
> our talent was order of magnitude superior to their existing dev teams.

i would love to read more about these "superior development processes" without
any issue tracking or activities log.

------
bra-ket
jira is customizable, just cut some layers of default crap and it can be
pretty simple and useful

------
sjg007
No need to worry about Jira. If you want to worry, worry about capex
accounting... and even then, this is your managers problem, not yours. Also
this is not a serious problem per se. It’s about justification, mostly to
financial auditors..

------
mynegation
So how do you track and manage issues now? You gotta use something. We can
discuss JIRA against some other issue tracking tools, but I cannot imagine
proper industrial software development without using any issue tracking at all

------
zwhatever
If you are working locally then, IMHO, there's nothing better than a physical
kanban board, our PM needs to 'manage upwards so they maintain a separate Jira
for epics only.

------
iandanforth
Jira is pretty cancerous. It will likely lead to hundreds of developer hours
wasted on buggy, complex UI, new processes which are put in place because the
features exist to support them, and eventually a slide into a multi-atlassian-
product cluster of almost-working cruft.

That said you're SOL because you don't have a solid set of tools in place
today. I know large, distributed teams who use github effectively for example
and they have the processes and cultural inertia to make it work, but it
doesn't sound like you've even got a solid home-grown alternative.

------
BobFromDown
JIRA gets a 5/10 from me. Interface is too much of the same colour for
different information. Gets confusing when trying to move around quickly.

------
mbrodersen
I have used JIRA for years. It isn't perfect. Nothing is. But I have little to
complain about.

------
lazylizard
they optimise their company , you optimise your job? 1\. its their company its
their money and how they want to spend it 2\. its your job you can try your
best to make it easier or you can switch employers ?

------
Meai
I dont think that there is anything wrong with Jira apart from the fact that
it's slow. Other than that it has a lot of great features. I looked for an
alternative for a long time, in my opinion nothing comes close to jira and it
has only gotten better.

------
trhway
I recommend try it - if you dont succumb you'll have immunity for the very
long after that.

------
gaius
_end goal being to be able to qualify this work as Capex_

This is a common piece of tax optimisation, basically if you say to the
government “we did X hours R&D this year and here is the proof” they give the
company some tax back. Of course it is pure coincidence that the word
“development” has been overloaded in this way and you can get cash back for
cranking out CRUD apps...

If that’s the goal, you will not win this one.

------
comesee
Theres nothing you can do. Just accept what management wants and do your job
as best as you can

