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

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.

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.

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

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.

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?

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Of course, timecard software can be awful too.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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?

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.

https://bitrix24.com https://bitrix24.eu https://bitrix24.com.br https://bitrix24.in 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.

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.

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.

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

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.

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.

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

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.

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

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

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.