Ask HN: Should I fight back management enforcing Jira?

2. Likely because the bigger company has a much more complex balance sheet so applies more complex accounting to manage it.

3. It's not the development so much as what's being developed. You're essentially creating an asset rather than a consumable so the cost of that asset can (sometimes) be considered a capital expense.

4. Probably because that's how they're managing this for the rest of the firm. If all the activity is done consistently in one tool, it makes it a lot cheaper to manage than having to chase up multiple groups, massage the data, reconcile etc etc.

5. Depends on the org. It's finance who want this directly as will whatever levels care about their P&L.

It's also not inconceivable that there are standardised processes across the org so that engineering cares for engineering's sake. Though that doesn't sound like the reason in this case.

At the level of an individual team this may seem like a bad idea but, in an org with a lot of dev teams, fungibility of tooling and process can both be a big cost save as well as a big training save.

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.

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.

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.

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.

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.

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.

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.