[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 :-(

[matt_the_bass]

> 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.

Perhaps you should embrace this. Spending time at the story level means you spend early effort to clarify the issue and specify the (possible) solution. In other words: planning.

I know this may seem like it sucks and is not really worth it, but it is often really valuable, especially as you grow and scale. Your company has been bought by a larger one. Obviously one value of this is to use the larger company’s resources to scale faster.

Maybe some of the story requirements are extraneous, but perhaps you should work with central management to improve the jira story requirements not fight against them.

[coffeemug]

> moving a lot of $$$ to capex is incredibly important for management

A few questions:

  1. Why is this the goal?
  2. Why does it depend on the company?
  3. How could you categorize development as capex? Isn't it obviously opex?
  4. Why do they need JIRA for that? Why not GitHub issues?
  5. Who's "management"? Engineering management? Executives? Someone else?

[lucozade]

1. Because they can depreciate capex over a multi-year period. This can help manage the P&L better.

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.